Everything you always wanted to know about Certificate Transparency (33c3)

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