[Musique d'ouverture]
Herald: Je suis heureux d'être ici, J'imagine que vous aussi. Nous allons commencer
avec notre premier speaker du jour. Il est chercheur en sécurité pour SBA Research, et également
membre du CCC de Vienne. La présentation d'aujourd'hui est: "Tout ce que vous
voulez savoir sur la transparence des certificats". Sur ce, je lui passe la main.
Donnez un accueil chalereux à Martin Schmiedecker!
[Applaudissements]
Martin: Merci beaucoup pour ces mots, et cette sympathique introduction.
Comme le disait Ari, Je suis membre du CCC Vienne. Je suis aussi sur twitter, donc si
vou avez des commentaires, voulez me ping, si vous trouvez une typo dans les slides
ou autre... Juste, venez me voir sur twitter!
Donc, de quoi s'agit il, de quoi allons nous parler?
La transparence des certificats est quelque chose de relativement nouveau dans l'écosystème TLS
donc peu de gens sont familiers avec sa présence. Je vais donc donner un aperçu de ce que c'est
ce que ça fait, et j'irais également regarder plus en détails ce qu'il fait réellement,
comment cela fonctionne, et comment jouer avec. Ah, et un détail sur moi
Je suis un fan des memes internet... Donc même si vous voyez des images drôles
Personnellement, je trouve de nombreuses images en ligne... Gardez en tête
que HTTPS est un sujet sérieux. Que vous payiez en ligne, utilisiez
Google, ou n'importe quoi d'autre, HTTPS protège votre vie privée
et votre sécurité. Et dans certains états, on l'a vu dans l'histoire, ce n'est pas
le cas, et il existe des dispositifs d'introspection nationaux voués à ouvrir TLS
pour regarder le contenu échangé. Et les gens recevront une visite de
la police ou autre, qui frapperont chez eux et les arrêterons. Comme cette semaine
en Turquie, ou des gens ont été arrêtés pour avoir posté des choses sur Facebook.
Donc malgré les images marrantes dans ce talk, n'oubliez pas qu'il ne s'agit
que d'une façon de présenter. Je considère que HTTPS est
un suject très sérieux, et j'espère vous en convaincre. Et la transparence des certificats
est fascinante. D'ailleurs pourquoi cela existe? Le nom répond à cela:
Si vous êtes une autorité de certification, vous allez rendre publics les certificats
vendus, ou créés. Et comme toute bonne histoire ou outil, tout cela a commencé
par un hack. En 2011, il y avahit cette autorité de certification néerlandaise
DigiNotar, et ils se sont fait défoncer, et vraiment bien bien profond...
[rires]
ils ont tout perdu. Ils ont perdu toutes leurs richesses.. Et dans ce hack,
Il y a eu 500 et quelques certificats illégitimes générés. Et pas
n'importe quels certificats, pas juste comme Let's encrypt, ou vous obtenez un certificat gratuit pour
vos systèmes internes ou autre...Non
Il s'agissait de gros domaines, et donc des certificats de grande valeur. Comme google.com, très
dangereux pour la vie privée: Si vous pouvez lire ce que recherche quelqu'un, ou ce
qu'il envoie par email.. windowsupdate.com, qui est comme le contrôle d'une partie
de l'univers windows... mozilla.com, ou l'attaquant est en mesure de manipuler
les téléchargements, effectuer des signatures frauduleuses et les envoyer
vers un site en apparence sécurisé. torproject, etc... C'était en 2011, et ce n'était pas
qu'un petit incident. Ce n'était pas une petite AC, mais une AC classique, avec un business
classique. De plus sur ce hack,: Ces certificats ont été utilisés
pour intercepter les communications des clients. Les gens navigant sur Internet, lisant
leurs emails. La société qui a procédé à l'investigation post incident a trouvé
qu'au moins 300 000 adresses IP se connectaient à google et
voyaient ce certificat frauduleux. 99% en provenance de l'Iran. C'était donc un genre
d’attaque d'un Etat, contre des clients, en fonction de leur FAI ou de leur localisation géographique
alors que les gens pensaient naviguer en toute sécurité grâce à HTTPS..alors que non.
Voici une belle image de la vidéo. Les gens de Fox-IT qui
ont procédé à l'investigation.. ils ont utilisé des requêtes OCSP. Chaque fois que
vous obtenez un certificat, votre navigateur va chercher à savoir si il est valide ou non
Si il a été révoqué, il est mieux de ne plus l'utiliser. Et
l'unde des approches utilisées est appelée OCSP. Donc le client demandera à son AC
"hey, est il encore valide?" Et ce sera loggué. Chacune
de ces requêtes est l'une des clients ayant été confrontés à ces certificats frauduleux et
demandant à DigiNotar "Hey, ce certificat est il valide?" Et comme vous le voyez, la plupart de ces
connexions - c'est une vidéo, alors vous pouvez voir les lumières aller et venir
au fur et a mesures que le gens dorment et se réveillent. Et la plupart
de ces gens venaient d'Iran. Donc comment ont il hacké DigiNotar? Ils se
sont fait salement hacker car ils avaient des vulnérabilités partout. Ils avaient
un système incroyablement vulnérable pour une autorité de certification.
Les gens pensent que si vous faites tourner une autorité de certification, vous construisez
les fondations pour la sécurité des échanges en ligne
Et si vous faites fonctionner ce genre d'entité, les gens pensent que vous connaissez la sécurité.
En fait...
[rires]
en fait, DigiNotar non. Ils avaient de nombreux logiciels non patchés, directement sur Internet
Ca arrive. Ils n'avaient pas d'antivirus sur les machines attribuant
les certificats. Ils n'avaient pas de mots de passe forts pour leurs comptes d'administration...Du style
"password" ou "admin" .. Vous pouvez lire le rapport en ligne, et les
recommandations de l'ENISA, le corps européen de sécurité. Ils ont listé tout
ce qui a été trouvé et identifié. De plus, tous ces serveurs d'attribution étaient
membres d'un unique domaine. De plus, à charge pour DigiNotar, ils ont caché cet incident
Bien sur ils n'allaient pas dire sur Internet "Hey, on s'est fait
hacker, et on a un mauvais niveau de sécurité". Ils l'ont caché ainsi
pendant plus de deux mois
Après 2 mois, quand cela a été rendu public, et qu'Internet l'a découvert
ca c'est très mal passé. Ca a été découvert, et
DigiNotar a fait faillite. C'est la triste fin de l'histoire. Mais ce n'est pas l'unique
problème auquel font face les autorités de certification. Si vous en faites fonctionner une,
Vous attribuez des certificats en vous basant sur l'identité de vos clients
Vous pouvez créer des certificats secondaires, pour pouvoir dire "Hey, Martin, il a l'air de quelqu'un de
bien, on dirait qu'il s'y connait en sécurité. Créons lui une AC, et faisons lui vérifier
les identités... Probablement une mauvaise idée, mais c'est cela le modèle de HTTPS
et des autorités de certification. Ils attribuent les certificats, et donnent la permission
d'en attribuer également. Leur but final étant
d'être accepté dans les autorités de confiance. Chaque navigateur, chaque OS, chaque
chose qui se connecte via TLS utilise ces autorités de confiance, contenant
les entités autorisées à distribuer des certificats. Et le problème c'est qu'ils
ne sont pas audités formellement. Ils ont leurs propres exigences à remplir
Ils doivent montrer qu'il présentent une certaine sécurité, mais après tout,
une fois certifiés et dans la liste de confiance, ils n'y a plus ce besoin
d'audit. Ils sont dans les autorités de confiance, et
ont leurs propres audits, etc. Ceci peut apporter de nombreux problèmes. Une autre AC,
Trustwave, en 2011, attribuait des certificats secondaires (sub-CA). Chaque personne utilisant ces certificats
est en mesure de générer un certificat TLS pour n'mporte quel domaine. Ils l'utilisaient pour
examiner le trafix. Donc, je ne sais pas, il vendaient ca à des sociétés,qui construisaient
des appliances, capables d'ouvrir les connexions aux banques
aux sociétés ou à tout un FAI. Ils pouvaient regarder le contenu du trafix des utilisateurs. Aussi,
Il y a eu Lenovo Superfish...brillante idée. Superfish était une
autorité de certification locale, en position de man in the middle. Le but étant de déchiffrer le trafic HTTS
afin d'injecter des publicités.
[rires]
Même si vous utilisez gmail, avec une jolie interface sans publicités,
Superfish pouvait casser la connexion, gagner la confiance du navigateur
et ainsi pouvoir mettre d'énormes publicités en overlay. Lenovo a stoppé sa collaboration avec Superfish.
C'était de plus préinstallé sur les PC portables. Ils avaient leur AC locale sur le système
Et pouvaient ainsi directement inspecter le trafic, et adapter la publicité. Ce qui est d'autant plus
intéressant était que toutes ces AC avaient la même clé, et que la clé privée était en RAM.
Donc n'importe qui pouvait extraire cette clé privée, l'utiliser pour signer n'importe quel certificat
et obtenir une couche supplémentaire pour l'injection HTTPS... Ou vous pouviez non seulement faire
apparaitre des publicités, mais aussi lire les emails, ou faire ce que vous vouliez. Sale. Ils ne le font plus
maintenant. Puis il y a eu, en Chine, le CCNIC. Ils ont attribué des sous-certificats
pour une société d'introspection. Ici aussi, la société voulait vendre des produits
capable de déchiffrer les flux HTTPS, et consulter le trafic des utilisateurs.
Et il y a encore eu un incident cette année. Symantec a attribué des certificats de test
à une société ou n'importe, genre opera.com, google.com...
Des choses que vous n'aimeriez pas tester si vous veniez à vous faire prendre. Et le truc sympa dans cet incident
C'est qu'ils avaient déja installé la transparence des certificats... Et
on va y revenir dans une minute. L'introspection dans le trafic reste justifiable
Imaginons que vous ayez une flotte d'avions, utilisant des connexions satellites coûteuses
Et que vous payiez réellement une fortune pour une bande passante que vous voudriez bloquer,
par exemple Netflix, ou tout ce qui crée un fort trafic... L'une des approches
utilisée par Gogo, c'était qu'ils surveillaient le trafic dans leurs avions en
utilisant des certificats invalides pour examiner les flux. Dommage pour eux,
Adrienne Porter Felt, travaillant pour Google, s'en est aperçue, et Gogo ne fait plus
ca désormais. Et bien que l'introspection dans le trafix puisse sembler mauvaise,
Je persiste à penser que dans certains cas elle soit légitime. Si vous avez une société,
une banque, et voulez protéger les personnes des fuites de données, cela peut être OK, mais doit être
transparent. Les gens doivent savoir que cela se passe, et que leurs données
soient inspectées. Et ceci ne protègera pas les gens si ils se promènent avec une clé USB
contenant toutes leurs données. C'est pour cela que nous avons besoin de la transparence des certificats.
Nous voulons voir quel certificat a été attribué par telle AC.
Quelques problèmes mineurs, pas si mineurs, qui rentrent aussi en jeu
sont que TLS possède ses propres failles, peu importe la validité du certificat.
La révocation des certificats est compliquée. Ce n'est pas aussi simple
que de dire "Ce certificat n'est plus valide". Une fois attribué,
Il est valide, jusqu'à la date indiquée. Ce qui peut aller jusqu'à trois ans.
Parfois, dès le premier jour, les gens réalisent
"ugh, on devrait le révoquer"...et les clients qui n'ont pas eu cette information utiliseront ce certificat pour les
deux années à venir, voire plus. Une autre limitation est que les AC
peuvent fournir des certificats pour tous les sites. N'importe lequel de ces 1800 certificats et certificats secondaires,
qui étaient de confiance en 2013, ils peuvent tous en générer un pour google.com
ou facebook.com. Ce n'est pas protégeable, à part par le biais de contrats, ou de morale
qui attesteront que la requête doit être légitime. Ca a été publié
en 2013. Il y a plus de 1800 AC qui peuvent signer des
certificats pour tout domaine, sur un appareil classique. Un autre papier, en 2014
décrit qu'un tiers de ces 1800 AC
n'a jamais délivré le moindre certificat HTTPS.. On se demande alors: pourquoi sont ils
dans les autorités de confiance? Vous pouvez dire qu'une partie génère
des certificats privés, pour les réseaux internes. Cependant, un tiers
n'a jamais délivré de certificat HTTP public. Puis évidemment, il y a les
erreurs d'implémentation. TLS a une longue histoire la dessus. Pas uniquement
cryptographique... Entre le logjam, FREAK, POODLE et consorts... Ceci reste un problème
indépendant, mais ces erreurs d'implémentation mettent à mal constamment la sécurité de l'appareil.
Le meilleur exemple est "goto fail", d'iOS, ou ils avaient un 'goto fail' additionnel
auquel il manquait un élément de syntaxe, et la validité du certificat n'était pas vérifiée.