Mise à jour conséquente de ce billet puisque pas mal de choses ont changé depuis la sortie, en mars 2014 (mais je teste que maintenant :P ), de la nouvelle image Debian + Linux 3.4 fournie par Olimex.

:')

Ok, je n'avais pas encore shaarlié mon dernier billet de blog ...

« Je me suis sérieusement mis à OpenPGP. C'était dans ma TODO depuis trop longtemps. Ce billet regroupe juste mes réflexions, ma manière de faire et les différentes lignes de commandes extraites du man qui pourront m'être utiles un jour. Rien d'innovant en soi. »

Mouais ... Le déférencement n'empêche pas l'info de circuler que ça soit en utilisant des moteurs de recherche acentrés (non, je ne parle pas de DDG ou des meta-moteurs) ou via les réseaux sociaux (je parle au sens large, pas FB/Twitter mais aussi XMPP, IRC, mail, ... bref, circulation P2P entre les gens). Mais ça met clairement en évidence les prochaines dérives et les prochains combats pour trouver un juste milieu législatif.

:')

Un exemple de plus d'altération du contenu... Adieu, neutralité des réseaux.

Je note aussi qu'il n'y a pas de juge dans l'affaire. Donc des parties prenantes (ayants-droits) constatent, ce qui est pour eux une infraction, la signale à la police qui décide de sanctions (priver de revenus est une sanction) sans juge (après un avertissement aux préjugé coupables, notons). D'acc d'acc d'acc... Joli joli toussa.

Intéressant, je ne savais pas.

Utiliser le DNS pour vérifier la clé publique de ses serveurs SSH, ça fait longtemps que je connais mais que je n'ai pas déployé. Et pour cause : sans DNSSEC, ce n'est pas une superbe avancée. Mais maintenant que ça m'est revenu à l'esprit et que mes zones DNS sont signées, j'ai voulu retenter.

Pour générer les enregistrements DNS de type SSHFP, on peut utiliser « ssh-keygen -r » mais je lui préfère cette méthode manuelle : https://confluence.clazzes.org/display/KH/SSHFP+records%3A+DNS+providing+public+ssh+host+keys car elle permet, entre autres, de générer toutes les empreintes correspondantes à chacune des clés du serveur, quel que soit son algo (rsa,dsa,ecdsa), en un seul coup.

Regardons le rdata d'un enregistrement de type SSHFP pour notre culture : « x y condensat ». x = type de clé (1 = RSA, 2 = DSA, 3 = ECDSA). y = fonction de hachage utilisée pour générer le condensat (1 = SHA1 ; 2 = SHA256). Cf : http://tools.ietf.org/html/rfc4255 et http://tools.ietf.org/html/rfc6594

Publier les enregistrements générés plus haut dans votre zone, forcer un resign de votre zone, vérifier que le RRset SSHFP est publié (dig +dnssec SSHFP machine.example.com), tester avec un ssh -o VerifyHostKeyDNS=yes -v <serveur> et ... ça ne fonctionne pas :
debug1: Server host key: ECDSA [fingerprint blabla]
debug1: found 1 secure fingerprints in DNS
Error calculating host key fingerprint.

Par défaut, le serveur envoie sa clé ecdsa. Le RFC 6594, publié mi 2012, ajoute le support des clés ecdsa (et de l'algo de hachage SHA256 pour le rdata) au rtype SSHFP. OpenSSH supporte cela depuis sa version 6.1 (http://www.openssh.com/txt/release-6.1 - « Add support for RFC6594 SSHFP DNS records for ECDSA key types. bz#1978 ») ... mais dans Debian Stable, nous avons uniquement la version 6.0 ... Ce qui explique cette erreur ainsi que l'erreur « export_dns_rr: unsupported algorithm » quand on tente un ssh-keygen -r sur la clé ecdsa.

Avec la version 6.6 présente dans les backports (apt-get install -t wheezy-backports openssh-client), tout fonctionne comme attendu :
debug1: Server host key: ECDSA [fingerprint blabla]
debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_ecdsa_verify: signature correct

On peut donc ajouter ceci à notre ssh_config :
Host *
        VerifyHostKeyDNS=yes

Évidemment, si vous n'avez pas un récursif-cache validant sur votre machine ou sur votre réseau local de confiance, vous subissez le problème du dernier kilomètre (DNSSEC toussa) et cette publication de RR de type SSHFP ne vous avance pas vraiment niveau sécurité.

Pour ceux qui ne veulent pas utiliser les backports (je vous comprends) ni attendre la prochaine Debian Stable ni changer de système (Debian > *, je vous comprends), il existe la directive de config' « HostKeyAlgorithms » que l'on peut préciser dans le ssh_config. Par défaut, elle vaut (cf le man) :
ecdsa-sha2-nistp256-cert-v01@openssh.com,
ecdsa-sha2-nistp384-cert-v01@openssh.com,
ecdsa-sha2-nistp521-cert-v01@openssh.com,
ssh-ed25519-cert-v01@openssh.com,
ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,
ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
ssh-ed25519,ssh-rsa,ssh-dss

On voit bien qu'ecdsa passe avant tout. On peut la forcer à une valeur sans ecdsa :
« Host *
        HostKeyAlgorithms=ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
        VerifyHostKeyDNS=yes »

Personnellement, je ne le ferai pas. J'ai encore confiance en les dev' d'OpenSSH et en les mainteneurs Debian. Si ecdsa passe en priorité, je laisse et j'attends le support des SSHFP ecdsa+sha256 (même si ecdsa n'est pas mieux que rsa/dsa mais juste moins gourmand à sécurité équivalente et que, du coup, l'impact en sécurité de forcer rsa doit être négligeable).

Cela fait un an que j'auto-héberge mes services importants sur un RPi (toi aussi lecteur admire cet oxymore), cf : http://www.guiguishow.info/2013/08/08/auto-hebergement-sur-raspberry-pi/

Je voulais faire un petit feedback sur les problèmes que j'ai rencontrés. Non, contrairement à beaucoup, je n'ai pas eu de problèmes avec une usure de la carte mémoire (alors que j'ai pourtant acheté une carte SD bas de gamme presque premier prix).

J'ai rencontré deux problèmes :
  - Erreurs de lecture subites sur le système de fichiers ... Aucune manip' ni physique (genre je n'ai pas déplacé mon RPi, je ne me suis pas pris les pieds dans un câble, ...) ni logicielle en cours. Je reboot hard (enlever l'alim, la remettre) mais le RPi ne boot plus (seule la LED rouge « power » s'allume, pas la LED verte d'accès à la carte SD). Je retire la carte SD et la teste sur mon ordinateur : aucun problème en lecture et en écriture. En manque d'idées, je lis sur le web qu'il faut vraiment qu'elle soit bien enclenchée dans le slot du RPi, genre ya un loquet et tout qui acte la présence de la carte et donc le fait qu'elle sera vue. Je remets la carte SD fermement dans le RPi et ... ça fonctionne ... Ce problème n'est jamais réapparu.

  - L'adaptateur secteur<->USB a subitement lâché sans raison apparente (pas d'orage ni une quelconque surtension a priori). Symptômes : le RPI s'éteint et la LED rouge « power » est allumée mais très très faiblement. J'ai testé l'adaptateur avec autre chose (le bête ventilo d'une table refroidissante pour ordinateur portable) : le ventilo ne tourne pas. Pour info, j'ai acheté cet adaptateur chez Kubii, en même temps que mon RPi mais bon, pour 7,43€ HT aussi ... J'ai alors utilisé un autre adaptateur que j'avais sous la main : le RPi s'allume mais le port RJ45 ne fonctionne plus (aucun signal signalé par le switch à l'autre bout) et dans les logs, on peut lire : « smsc95xx 1-1.1:1.0: (unregistered net_device): MII is busy in smsc95xx_mdio_read smsc95xx 1-1.1:1.0: (unregistered net_device): Failed to read register index 0x00000114 ». Le RPi est connu pour être très sensible sur son alimentation électrique. Un nouvel adaptateur secteur<->USB, supportant jusqu'à 1A, pas premier prix, acheté au pied levé et ça repart.

À part la première erreur décrite ci-dessous, j'ai plutôt l'impression que le RPI est fiable et que c'est les composants externes (carte SD, alimentation) qui font sa faiblesse.

« Je viens de tomber sur cet article qui explique qu’en ayant réduit la limite de vitesse sur le périf parisien de 90 km/h à 70 km/h, la nombre de bouchons a diminué de 40%, et qu’au final la circulation est plus fluide. Ils comptent laisser cette limitation de façon définitive à partir de janvier 2015.

Ceci est un exemple du paradoxe de Braess appliquée au réseau routier, qui dit en gros que pour accélérer le trafic d’un réseau il faut en retirer les portions les plus rapides.

[...]

À l’origine, ce paradoxe a été établit pour la congestion des nœuds du réseau pour Internet : si on met un gros câble en fibre optique très rapide entre deux points, toutes les données voudront l’emprunter et ça se fera sans problèmes pour le gros câble… mais avec des problèmes pour les petits câbles tout autour, et au final c’est tout le trafic qui est perturbé. La solution est donc de ne pas construire de « voie rapide », mais plutôt de faire plein de voies « normales » en parallèle.

C’est également pour ça que le partage de gros fichiers via la technologie P2P est si rapide par rapport à des solutions comme Mega ou 4Shared : si un fichier est très demande, les sites Mega ou 4Shared seront saturés, mais avec le P2P, le fichier étant partagé directement d’un internaute à un autre sans passer par un point central, c’est tout le réseau qui est utilisé pour partager le fichier, pas seulement le réseau de Mega ou 4Shared. »

Je précise juste un point : l'important avec Internet ce n'est pas d'avoir des voies « normales » versus rapides mais d'avoir des voies égales, une symétrie des capacités et une montée en capacité « uniforme » (tendre vers cet objectif).

« Une licence globale ? C'est impossible ! » :')

Mignon :')

Pourquoi s'arrêter à la vente de périphériques ? Pourquoi ne pas plutôt faire de l'incitation sur les marchés public où, pour le coup, l'État a une vraie légitimité à agir ? SI les professionnel veulent remporter l'appel d'offres, ils devront se plier aux exigences et une fois la prestation produite, elle pourra être proposée à tous (autres professionnels, particuliers, ...).

Qu'est ce qu'un périphérique (une box est-elle un périphérique) ? Ne vaut-il mieux pas parler de produit ou service pour rester général ? Qu'est ce qu'un accès v6 (natif ou encapsulation over v4) ?

Qu'est ce qu'une adaptation à la norme IPv6 ? Le noyau doit supporter même si ce n'est pas utilisé derrière ? Tous les programmes de votre ordinateur de poche doivent être v6 compliant ?

Aucune sanction prévue par le texte ... On sent tout de suite qu'il va être respecté.

Et quid du côté des fournisseurs de services ? Même question pour les opérateurs ...

Bref, proposition de loi sans intérêt àmha. Ne défini rien et utilise un angle d'attaque incorrect. Ce texte ne peut produire un quelconque résultat.

Ok, Netflix utilise BIRD, FreeBSD et nginx, entre autres ... au moins pour leur CDN. \o/

J'avais déjà lu que plusieurs collectifs se bougent pour avoir la fibre en DIY en Angleterre mais à ce point c'est réellement impressionnant. C'est à Lancaster et alentours sous forme de ce qui ressemble à nos statuts juridiques SCIC/SCOOP en France.

« ifupdown2 a new implementation of debian ifupdown package written in python. ifupdown2 strives to maintain backward compatibility with ifupdown and comes with newer features like interface dependency relationships, json support, better query support and more. »

Voir aussi : https://support.cumulusnetworks.com/hc/en-us/articles/202933638-Comparing-ifupdown2-Commands-with-ifupdown-Commands

Aujourd'hui, dans mes apt-listchanges :
« apache2 (2.2.22-13+deb7u2) stable; urgency=medium

  * This release adds support for SSL/TLS ECC keys and ECDH ciphers.

    If this change causes problems with some older clients, see
    /usr/share/doc/apache2/README.Debian.gz for a work-around.

 -- Stefan Fritsch <sf@debian.org>  Sun, 25 May 2014 13:05:40 +0200 »

Cela rend donc possible l'utilisation de la confidentialité persistante avec des navigateurs web qui ne supportent pas les algos DHE-* mais supportent les algos ECDHE-*, ce qui est le cas d'IE8-11 à partir de winwin 7.

De plus, les algos ECDHE-* sont moins gourmands en CPU que les algos DHE-* (mais toujours plus que les algos sans PFS, tout se paye :) ).

Pour les petits malins : non, ça ne rapporte pas des points en plus sur ssllabs. :P

DANE :
  - Théorie : https://tools.ietf.org/html/rfc6698
  - Théorie/pratique : http://www.bortzmeyer.org/6698.html

Je trouve DANE très intéressant et prometteur donc je suis ça de loin depuis environ 1 an et demi. Pour l'instant, le plus gros problème, c'est l'absence de support de la part des navigateurs web, des serveurs de mails, des clients mails, des serveurs XMPP, ... bref, de tout ce qui manipule du TLS. Ensuite, le plus gros problème sera l'encore faible déploiement de DNSSEC (pré-requis de DANE).

Il y a 1 an environ, j'ai réalisé une maquette. Il y avait beaucoup d'outils disponibles pour créer des enregistrements, les valider plus ou moins partiellement et surtout, beaucoup d'outils (notamment des extensions Firefox) qui ne fonctionnaient pas. Difficile de créer une maquette réaliste, ce qui m'a conduit à lâcher l'affaire (je veux produire une maquette réaliste en vu d'un déploiement futur, voir comment se compte les vrais logiciels, toussa).

Il y a 6 mois environ, j'apprenais que la version 2.11.0 de Postfix apporte le support de DANE. Et je prévoyais un test grandeur nature dans ma TODO.

C'est aujourd'hui fait. Un bête postfix installé depuis les backports tentera d'envoyer un mail à un serveur mail situé dans un domaine signé qui a un enregistrement TLSA pour le certificat x509 utilisé par le serveur de mail de ce domaine.

L'installation d'un serveur mail à l'arrache ne pose pas problème, le bypass de la politique de sécurité réseau (pas de port 25 en sortie) se fait avec un VPN ARN, la création d'un enregistrement de type TLSA en utilisant openssl (voir l'article de Stéphane Bortzmeyer) pour générer le rdata ne pose pas problème, ...

Ce qui pose problème, c'est OpenDNSSEC qui refuse de re-signer la zone : « error parsing RR at line 27 (Syntax error, could not parse the RR's rdata) ». Solution : http://lists.opendnssec.org/pipermail/opendnssec-user/2012-December/002310.html -> « OpenDNSSEC depends on LDNS for supported RRtypes. You should link against ldns 1.6.16 if you want to do TLSA. ». Or, dans Debian Stable, c'est la version 1.6.13 so game over. Non, hors de question que je mette à jour mon OpenDNSSEC à partir des backports, j'ai déjà donné. :)

Utiliser un type inconnu (« TYPE52 ») ne permet pas de tromper OpenDNSSEC. ÉDIT DU 14/11/2016 À 12H15 : Parce qu'il ne suffit pas de changer le type, il faut aussi encoder le RDATA dans un format bien défini. Voir la section 5 du RFC 3597 (https://www.rfc-editor.org/rfc/rfc3597.txt ). FIN DE L'ÉDIT.

Mettre à jour seulement libdns1 casse une dépendance entre le signer (composant d'OpenDNSSEC) et cette librairie et le signer ne peut plus être lancé : « /usr/sbin/ods-signerd: symbol lookup error: /usr/sbin/ods-signerd: undefined symbol: strlcpy ».

Impossible de signer "ailleurs" avec le signer de BIND, par exemple puisque les parties privées des clés sont enfermées dans le SoftHSM. Alors oui, j'aurais pu installer un OpenDNSSEC récent "ailleurs" et exporter le contenu du SoftHSM ... mais non merci. :)

Je remets donc le test de DANE en conditions réelles dans ma TODO. :)

Bref : DANE en production, ce n'est pas encore pour tout de suite : manque de support dans les versions stables et packagées des logiciels + manque de support dans OpenDNSSEC.

Ça marche aussi pour downgrade un soft, j'avais oublié.

C'est comme https://www.ssllabs.com/ mais pour tester le support TLS d'un serveur Jabber (c2s et s2s). C'est lent et limité à deux tests (un c2s, un s2s) par heure mais ça fait le job.

Sur mon serveur perso, les seuls problèmes remontés sont : absence d'enregistrement TLSA (en même temps il n'y a aucun serveur ni client jabber qui supporte DANE ...), certificat auto-signé, ssl v3 autorisé et des ciphers faibles autorisés.

Parlons de la config ejabberd. Pour le détails des directives de configuration, c'est par ici : http://www.process-one.net/docs/ejabberd/guide_en.html#listened-module
  - Pour activer/désactiver le support de certains protocoles (ssl v2/v3 TLS v1/1.1/1.2), c'est la directive globale « s2s_protocol_options » et la directive locale au bloc « ejabberd_c2s » nommée « protocol_options ». Ça arrive dans la version 14.05 donc ce n'est pas encore dans Debian Stable. Source : http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2014/05/24.html. Apparemment, le séparateur si plusieurs options devrait être « | ». Actuellement, ssl v2 est désactivé, tout le reste est activé.

  - Pour changer la liste des ciphers utilisés, c'est la directive globale « s2s_ciphers » et la directive locale au bloc « ejabberd_c2s » nommée « ciphers ». Ça arrive dans la version 13.12 donc ce n'est pas encore dans Debian Stable. Source : http://www.ejabberd.im/ejabberd-13.12 et http://chatlogs.jabber.ru/ejabberd@conference.jabber.ru/2014/05/24.html. La valeur est un classique commun à ce type de réglage dans les autres softs : openssl ciphers.

  - Pour info, il y a eu un renommage donc la version 14.05 (Ubuntu style) c'est bien après 2.1.X :)