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.
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)
Ahah, moi qui avait peur des limitations de Let's Encrypt…
En fait, on peut générer une quantité phénoménale de certificats.
Franchement, je viens d'essayer avec mon domaine et l'agent Let's, c'est juste AWESOME. Intégration immédiate et sans action manuelle.
Je prédis la mort des petites CA payantes, et probablement la fin du business basé sur les certificats gratuits (StartSSL & others)
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 !
Mandieu. Facepalm terrible en matière de sécurité : non, le "logo Verisign" n'est pas une preuve de sécurité. Surtout en l'absence de SSL sur la connexion.
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)
Tiens tiens…
Étrange comportement de notre ami Firefox : j'ai une page ouverte, en SSL, et qui fait tourner de l'AJAX. Je change le certificat du serveur et le redémarre. La page toujours ouverte, et qui continue de recevoir du contenu m'indique toujours l'ancien certificat. Tant que je ne recharge pas la page elle ne le fait pas.
Mais alors, que se passe-t-il si dans ce type d'échange, un "advanced firewall" quelconque s'amuse à changer de certificat ? Hmm… Question con sans doute.
M'enfin, j'suis pas super rassuré par ce comportement.
Oh, d'ailleurs je n'avais pas vu que CAcert se lançait pour être accréditer par les navigateurs, notamment Firefox !!
Ce serait génial : non seulement ça ferait des certificats SSL gratuits (allez donc voir le prix pour le moindre certif ailleurs : hors de prix) mais en plus leurs confiances seraient validées par un système de WOT, donc communautaire.
Voulait qui résoudrait en très grande partie le problème actuel des autorités de certification. JE DIS OUI !!!
C'est bizarre : de temps en temps j'ai besoin de réinstaller le root de CAcert (autorité de certification indépendante et en WOT, qui certifie notamment LinuxFR)
Peut-être les mises-à-jour Firefox ?
Désagréable en tout cas…
Comme beaucoup, je réponds : normal que cette erreur. Le HTTPS n'est utilisé que côté administration, et bien qu'il fasse une erreur, il est reconnu par mon navigateur (j'ai du l'accepter une première fois).
Ça permet d'avoir une connexion chiffrée pour la transmission du mot de passe, mais pas authentifiée. Pour les lecteurs, pas vraiment besoin de SSL (en tout cas, pas vu le prix que c'est vendu chez OVH pour leurs mutualisés).
Je parlais hier de StartSSL qui fournit des certificats gratuits.
Il existe aussi CAcert que j'apprécie beaucoup : il fournit des certificats x509 classiques, authentifiés par le CA. Mais son réel avantage, outre sa gratuité, c'est qu'il calque le principe PGP (un web of trust) pour l'authentification des personnes (physiques ou morales) Donc, c'est complètement communautaire : il faut donner des preuves à un maximum de participants pour obtenir des points de confiance (je fais court)
Seul inconvénient : l'autorité racine n'est pas reconnue dans la plupart des navigateurs, y compris Firefox. Du coup, j'l'add à chaque nouvelle install
Malheureusement, il n'est pas reconnu en natif
Merci à cette boîte israélienne d'automatiser la vérification des propriétaires d'hébergement. Ça leur permet de filer des certificats SSL très limités mais suffisant pour le commun des mortels.
Normalement, ça coûte au moins 100 € l'année.
À noter que tout ceci se fait au détriment d'un peu de sécurité*. Mais de toute façon, le modèle hiérarchique des CA est mort (coucou la Chine, coucou les autres)
- (globale, ie, pour l'ensemble du réseau. Pour moi pas de problème, j'ai généré moi-même ma clé privé, et j'ai soumis une requête de signature sans connaissance de la clé privée. Du coup, personne ne la connaît, sauf moi)