C'est intéressant ce genre de retour d'expérience. Bortzmeyer a passé son blog sur Let's Encrypt, avec deux difficultés techniques :
- il y a trois machines pour le servir, donc il faut obtenir le même certificat partout, sans accès au root des deux machines esclaves ;
- il faut que DANE fonctionne (DANE-EE) donc la clé privée ne doit pas changer dans le temps.
Il y a aussi la possibilité de mettre à jour le DNS pour la clé DANE mais cela obligerait à scripter d'avantage. La solution ici est assez élégante, faute de mieux.
Doh: Firefox & Chrome peuvent enregistrer les premaster-keys des sessions TLS directement dans un fichier.
Pratique pour déchiffrer à la volée du trafic TLS vers un serveur.
Bon, c'est pas rassurant niveau sécurité, parce qu'il faut simplement mettre une variable utilisateur dans l'environnement (utilisateur, même pas système !!)
Il est aussi possible, si on a la main sur le serveur, de demander au démon SSL d'exporter ces secrets, mais côté client ça devient plus difficile : il faudra un canal SSH pour lire les secrets dans Wireshark.
Explications claires du nouveau champ DNS CAA, sa mise en place et son utilité.
En même temps, ça vient de Bortzmeyer.
Très intéressant : le minimum de sécurité sur un système Linux avec éventuellement de l'hébergement). J'aime bien ce genre de liste, même si c'est parfois grossier, discutable ou limité. Ça fait au moins une sorte de checklist utile.
EDIT : le son est ici, si on veut écouter.
via : https://mastodon.social/users/maliciarogue/updates/2537747
Le RFC des bonnes pratiques TLS.
Indispensable & pratique !
Wow, Let's Encrypt est un véritable succès. Il est actuellement sur une croissance quadratique avec un fort taux de pénétration.
Résultat : d'après Firefox, on passe de 38% environ de pages chiffrées en Novembre 2015, à 51.5% actuellement. Ça ne suit pas exactement l'ampleur du mouvement, mais je suppose que les gros sites de GAFA représentent une part importante des pages chargées.
Trop bien. Pensez à faire un don.
Intéressant : suite aux nombreux problèmes des DNS chez les FAI français (je soupçonne des mesures de censure en cours de déploiement) beaucoup on recommandé de passer sur des résolveurs publics. Comme OpenDNS (arf), GoogleDNS (arf) ou ceux de FDN…
Mais tout cela a de nombreux inconvénients listés ici par Bortzmeyer (a.k.a. môssieur DNS).
Il recommande donc d'utiliser son propre résolveurs puis de rebondir en récursif sur des DNS non-menteurs mais avec une connexion chiffrée (DNS over TLS).
Il y a par exemple ceux de Lorraine Data Network.
Envisagez-donc un petit don à Let's Encrypt, pour lui permettre de vivre et d'être indépendant, mais surtout parce qu'au delà des discours, il est une vrai solution au problème d'espionnage massif aujourd'hui. Du concret cette fois.
via : https://twitter.com/MaliciaRogue/status/799561497424830464
Le guide des bonnes pratiques TLS par l'ANSSI. Pour quelqu'un qui s'intéresse au sujet, il y a beaucoup de redites, mais également quelques perles, comme le "aller plus loin" de la R27.
Pour une même terminaison, il est recommandé d’utiliser autant de certificats
que de versions et de méthodes d’échange de clés acceptées.
(relou ce truc)
via : https://twitter.com/ANSSI_FR/status/794572049364766720
Une thèse intéressante sur la pile TLS. Je conseille la version de synthèse.
Bon, je suis un peu circonspect sur l'utilité de l'énorme travail qui a consisté à fouiller tout l'espace IPv4 à la recherche de HTTPS (puis de parser les échanges pour découvrir le comportement de chaque pile).
Mais la dernière partie est vraiment bien, sur ce qui concerne l'implémentation, la mitigation, etc.
via : https://twitter.com/ANSSI_FR/status/794481666676981760
Ahah, ouais. Effectivement, les CA ont les chtouilles.
D'ailleurs, j'ai reçu un mail assez intéressant de la CA que j'utilisais (encore un peu en fait) : StartSSL / StartCom. À qui je ne reproche rien d'ailleurs, sauf peut-être de flipper de voir tous les clients partir. Ils vont implémenter l'outil Let's Encrypt pour faire leur propre autorité automatisée. Seul problème : ils souhaitent appliquer le protocole à l'Extended Validation (EV-3). Je ne suis pas sûr du tout que ce soit une bonne idée…
Youpi, Let's Encrypt, ça me fait vraiment plaisir.
D'abord, parce que c'est gratuit, et automatisé. Ensuite, parce qu'ils implémentent le protocole Certificate Transparency qui permet d'être sûr qu'ils ne se sont pas fait pirater.
Mais surtout parce qu'ils sont en train de réussir le challenge énorme qui se posait, et en très peu de temps. En manageant quelques sites et blogs, j'utilise des outils pour vérifier les liens cassés dans les pages. Et en ce moment, c'est une pluie de liens qui sont marqués "redirection" parce que l'ancien lien http://domain.tld/path devient https://domain.tld/path !
Et après quelques vérifications au hasard, il s'agit toujours de certificats signés par Let's Encrypt.
Et bientôt, DANE s'imposera et les CA disparaitront en majorité, comme il se doit (mais pas totalement, heureusement) : http://www.commitstrip.com/fr/2016/06/13/the-end-of-an-expensive-era/
Merci aux sponsors (parmi lesquels Mozilla, Akamai, Cisco, Chrome, Gemalto, OVH, Free, Gandi, HP)
(ça fait plaisir en ce moment de voir qu'on peut œuvrer pour quelque chose de bien à plusieurs)
Ce putain de site met dans un iFrame la page de billeterie. Du coup, impossible de savoir si c'est bien en HTTPS (sauf à bricoler avec des clics droits) et si le certificat est bien valide.
Re-lou.
Je découvre qu'avec DNSSEC, le champ TLSA permet de vérifier le certificat émis par le serveur, à la place de, ou en complément du / des CA.
C'est aussi utile par exemple, pour vérifier le CA signataire (à la place du certificat du serveur) afin de limiter le risque qu'une CA piratée ou malveillante forge un fake-certificat.
EDIT : on peut aussi utiliser ce champ pour accorder sa confiance à une autorité qui ne serait pas "de confiance" dans le root du logiciel client. Encore faut-il que ce dernier requête en DNSSEC et implémente ces méthodes (assez récentes)
Une grande avancée je trouve, et un bon compromis CA / non-CA.
Pratique !
Hmmmm, moi qui doit renouveler mes certificats très prochainement, je vais me pencher sur Let's Encrypt. Mais à l'heure actuelle, je ne sais pas si c'est supporté par tous les navigateurs (enfin, les plus gros quoi). Let's see ;)
Excellent article sur la sécurité de TLS (via OpenSSL).
Ça m'a permis de changer le chiffrement d'un outil que je développe (non critique, bien heureusement) et qui utilisait du AES-CBC (soumis à la faille POODLE, mais pas dans ce cas ; donc juste pour une best-practice)