GuiGui's Show

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).

« 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).

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.

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.

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

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

« Ouais donc en gros, il tourne par numéro de cœurs, un proc physique après l'autre, puis recommence tout pareil une deuxième fois quand il y a l'hyperthreading. »

Vidéos et Torrents PSES 2014

(via http://shaarli.cafai.fr/?0GJqrQ)

ÉDIT du 06/07/2014 à 22h15 : mirroir avec plus de vidéos : http://docs.volcanis.me/PSES/

Des boîtiers tuner TNT + VoD. Ok, je ne savais pas que ça existait.

C'est mignon. :')

« limiter l'accès non autorisé de la NSA dans son infrastructure » -> sans commentaire :')

« Il a ainsi été question d'un déplacement des serveurs de stockage à l'étranger, pour limiter l'accès des autorités américaines à certaines données » -> la localisation de la société qui possède les serveurs doit compter pas mal. Mais de toutes façon, depuis quand les USA se soucient de territorialité quand il s'agit d'agir pour leurs intérêts ? ÉDIT du 17/07/2014 à 19h21 : lors de PSES 2014, Oliver Iteanu a rappelé que l'on a déjà un cas pour se faire une idée même si ce n'est pas encore définitivement tranché selon Microsoft : http://www.ictjournal.ch/fr-CH/News/2014/05/06/Somme-de-livrer-des-donnees-Microsoft-va-se-battre-devant-la-justice.aspx FIN DE L'ÉDIT.

« Outlook.com est maintenant protégé par le protocole TLS  » -> rappel : TLS ne fait pas tout ! Surtout si l'une des extrémité est pwned/vendue à la NSA !

Bref : ne vous laissez pas avoir par ce type de discours !