Cher journal,
En ces temps ou un certain nombre d'entre vous n'ont pas l'air d'avoir envie de tout partager avec leur gouvernement. Voici une annonce qui améliore un peu la sécurité du HTTPS. Tu n'es pas sans ignorer que le modèle actuel de TLS souffre un gros problème. N'importe quelle autorité de confiance peut signer un certificat pour n'importe quel domaine, même si le propriétaire actuel du nom de domaine a déjà demandé à une autre autorité de le faire. Tu me dirais que c'est très gentil de la part d'une autorité de signer gratos un certificat signé par une autre autorité. En fait, c'est souvent fait pour faire du Man In the Middle ou de l'usurpation d'identité.
Le problème, c'est qu'il faut des autorités de confiance et qu'on se rend souvent compte qu'une telle autorité de l'était pas quand il est trop tard. La solution, c'est que le site annonce par qui il est signé (tu me diras que c'est déjà le cas, vu que c'est comme ça que fonctionne TLS), sauf qu'au lieu de l'annoncer à chaque requête, on peut se permettre de l'annoncer une fois pour toute. Le seul problème, c'est la première fois qu'on se connecte au site, il faut être sûr de ne pas avoir quelqu'un sur la ligne qui modifie le trafic qui passe.
La technique actuelle pour associer une CA à un domaine (qui s'appelle le pinning) est faite manuellement par développeur de web browser. C'est déjà en place dans Chromium et Firefox mais seulement pour les sites connus (Google, Twitter, Facebook…). Mais ça ne passe pas à l'échelle. J'ai envoyé ma CA pour mon site web via la RFC 6214 et j'attends toujours la réponse.
En résumé, comment ça se passe pour cette nouvelle technique: la RFC définit un nouveau header HTTP qui permet de spécifier la fingerprint de la CA ainsi qu'un TTL (pour pouvoir quand même changer de CA à un moment). À la connexion l'user agent (donc, le navigateur web dans la plupart des cas) récupère ce header (vérifie que ça correspond bien à l'actuel déjà) et stocker l'association domain → CA, à la prochaine connexion, il ne regardera pas le header, seulement si la CA est bien là.
Par contre, pour l'analyse détaillée, il faudra attendre Monsieur Bortzmeyer, moi, j'écris des journaux sur dlfp, je n'ai pas le temps de lire les RFC.
Bien sûr, ce n'est pas parfait. Le risque à la première connexion (ou à l'expiration du TTL) est bien réel. Mais pour tous les gens en déplacement dans des environnements peu sûrs, c'est un plus.
# L'analyse détaillée
Posté par tetraf . Évalué à 10.
Depuis 15h, aujourd'hui : https://www.bortzmeyer.org/7469.html
[^] # Re: L'analyse détaillée
Posté par claudex . Évalué à 5.
Merci pour le lien. Je constate du coup que j'ai des mails de seenthis dans les spam.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Politique de confiance client
Posté par ealprr . Évalué à 1. Dernière modification le 18 avril 2015 à 23:16.
En même temps, le navigateur pourrait tout aussi bien épingler par défaut les certificats serveur et alerter l'utilisateur dans le cas où le certificat a changé et qu'il n'a pas été révoqué.
La directive includeSubDomains me semble être un brin doublon avec le champ SubjectAltName des certificats.
Quant à la directive report-uri, elle me fait l'effet d'une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top
inviolablequi doit toujours être fermée.[^] # Re: Politique de confiance client
Posté par claudex . Évalué à 4.
Ce ne serait pas user-friendly, la plupart des sites changes avant la date d'expiration du certificat. Et des sites à haut trafic ont des certificats différents en fonction de la ferme de serveur sur laquelle tu tappe. Au final, ça ferrait beaucoup de faux positif pour rien.
Je ne vois pas pourquoi. Typiquement, tu peux avoir un certificat wildcard mais cnd.example.com qui utilise un tout autre certificat.
Je ne comprend pas non plus. Typiquement, c'est ce genre de mécanisme qui a permis de détecter les dernière usurpations de Google. En plus, pour du debug c'est très bien.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Politique de confiance client
Posté par ealprr . Évalué à 1.
En fait, cela n'impacterait pas, dans la mesure où je parlai de révocation et non pas d'expiration.
Ceci étant dit, ta remarque sur les certificats différents pour chaque instance d'un même service met, effectivement, le point sur un problème. Même si je ne suis pas, a priori, convaincu de l'intérêt de ce genre de configuration.
Tout comme je ne le suis pas d'avoir un certificat wildcard doublé d'un certificat nominatif et de manière générale : d'avoir plusieurs certificats matchant les mêmes cibles.
Effectivement, cela mérite précision : j'imagine un MITM qui souhaite s'interposer, sans report-uri il n'a aucun moyen de connaitre la situation du client et il a le choix de tenter d'imposer ses certificats (quitte à les annoncer avant dans un PKP) et donc de, potentiellement, lever une alerte ou d'abandonner.
Par contre, avec la directive et l'en-tête PKP-RO, il peut demander, sans lever d'alerte, le moment précis pour lancer une attaque qui réussira.
[^] # Re: Politique de confiance client
Posté par claudex . Évalué à 4.
Et donc, pendant la période de transition vers le nouveau certif, il y a un changement de certif sans révocation, avec ta technique, une alerte sera levé pour rien. (on ne révoque pas un certif dans la seconde du changement, et on change bien avant la date)
S'il arrive à ajouter une entête ou voir le trafic qui part sur une URL donnée, c'est qu'il fait déjà du MitM qui fonctionne. Donc, je ne comprends toujours pas le problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Politique de confiance client
Posté par ealprr . Évalué à 0.
Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.
Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.
Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.
[^] # Re: Politique de confiance client
Posté par claudex . Évalué à 3.
Justement, ce n'est pas comme ça que ça se passe. Pendant la période de transition, on contacte des serveurs avec l'un ou l'autre des certificats, mais pas les deux. On peut pas utiliser l'ancien.
Le client n'a pas suffisamment d'information pour pouvoir faire ça. Notamment, il ne connaît pas la fréquence du renouvellement des certificats.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Politique de confiance client
Posté par ealprr . Évalué à 0. Dernière modification le 19 avril 2015 à 17:12.
En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.
Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.
Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.
[1]: rfc5246 section-7.4.1.1 The HelloRequest message MAY be sent by the server at any time.
# TACK
Posté par rakoo (site web personnel) . Évalué à 6.
Le pinnage c'est très bien, ça permet de repérer assez rapidement quand quelque chose de louche se passe sur le réseau, mais c'est dommage de limiter ça à HTTP; il y a une proposition "concurrente" sous la forme de TACK, qui cette fois fournit la possibilité de pinner mais directement au niveau TLS, du coup:
Malheureusement c'est pas tout rose:
nginx.conf."Malheureusement" au rythme où vont les choses c'est HPKP qui gagnera, et tout ce qui n'est pas HTTP se retrouvera, une fois de plus, relégué au second rang.
[1] Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain. Le système actuel d'autorités de certifications est mauvais parce que les acteurs en haut de la chaine sont mauvais, mais le reste de l'infrastructure reste quand même solide; typiquement ici, ça aurait totalement du sens de ne gérer la confiance qu'au niveau du domaine, pas au niveau de chacun des serveurs, et ça c'est déjà fourni par le système de CAs.
[^] # Re: TACK
Posté par claudex . Évalué à 7.
Oui, comme très souvent, ce sont les changements les moins radicaux qui réussissent le mieux.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: TACK
Posté par Firwen (site web personnel) . Évalué à 1. Dernière modification le 20 avril 2015 à 12:14.
Sauf erreur de ma part, TACK n'interdit pas l'usage des CAs et surtout pas X509.
Il stipule simplement que tu peux te passer des CAs si tu acceptes une protection "TOFU" contre les attaques man in the middle.
HPKP est comme souvent avec Google, une solution simple(iste) mais efficace aux problèmes qui les touche plutôt qu'une tentative de résoudre le problème dans son ensemble.
[^] # Re: TACK
Posté par rakoo (site web personnel) . Évalué à 2.
C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde ? (et ne me dit pas que les serveurs devraient partager leur cles TLS…). Ça resterait quand même plus simple de ne pin qu'un seul truc au niveau de Google.
[^] # Re: TACK
Posté par Firwen (site web personnel) . Évalué à 1.
Il y a aucun souci à ça.
Tu peux utiliser une même TACK key pour signer plusieurs certificats X509.
Etant donné que les certificats de Google/facebook sont déja signé par un CA à leur génération, rajouter une signature devrait être un jeu d'enfant.
Le gros problème de TACK est qu'il rend l'architecture X509/CA/TLS encore plus monstrueuse, confuse et bordélique qu'elle ne l'est déja.
# Et DANE simplement
Posté par briaeros007 . Évalué à 9.
Il y a déjà une norme qui marche très bien, n'utilise pas les CA, est pensé pour s'assurer qu'il n'y a pas de MITM facilement :
DANE
On met les signatures (soit des CA, soit du certificat) correspondant au nom de domaine et protocole et port dans le DNS.
La sécurité/confiance de la chaine est assuré par DNSSEC.
ET voila : facile a gérer, à mettre à jour , et sur tous les protocoles.
Cette norme comment tranquillement sa vie entre autre sur les serveurs SMTP, ou avec l'extension TLSA/DANE de firefox, qui check à la fois le DNSSEC, et les records DANE.
Que demande le peuple ?
[^] # Re: Et DANE simplement
Posté par Ph Husson (site web personnel) . Évalué à 1.
Je me suis déjà demandé comment se déploie DNSSEC, cette fois je me suis motivé à sortir mon wikipedia adoré:
et
J'en déduis que pour chaque site que je visite il faut que je le whitelist ?
Ça parait trop aberrant, donc ça doit être autre chose. Il a une notion de CA ?
Et du coup il y a même problème de pining au niveau de DNSSEC, soit c'est piné par le client, soit ça utilise un CA ?
Et comment est géré le MITM qui supprime les enregistrements DNSSEC ?
On fait confiance au cache des DNS, donc il faut systématiquement un serveur DNS local à la machine ?
[^] # Re: Et DANE simplement
Posté par gouttegd . Évalué à 4.
Pas forcément « systématiquement », mais c’est recommandé, en effet. Au minimum, il faut que le résolveur DNS validant soit sur le réseau local, et que celui-ci soit de confiance. C’est le problème dit de la « sécurité du dernier kilomètre », qui sort du cadre de DNSSEC. Si le résolveur validant est distant, il faut un mécanisme de protection supplémentaire, comme TSIG par exemple.
Dans le cas idéal, le résolveur validant n’a besoin d’épingler que la clef de la racine. La plupart des logiciels résolveurs la connaissent déjà (tout comme ils connaissent les adresses des serveurs de noms de la racine).
Seulement si on ne peut pas remonter jusqu’à la racine, c’est-à-dire dans le cas (non idéal) où une des zones parentes n’est pas signée.
Par exemple, si la zone
fille.example.com.est signée mais que sa zone parenteexample.com.ne l’est pas, il est impossible de remonter jusqu’au TLDcom.(signé) et a fortiori jusqu’à la racine (dont le résolveur connaît la clef). Jusqu’à ce que le gérant deexample.com.signe sa zone (et communique sa clef au gérant decom.), la seule solution pour le résolveur souhaitant valider les données defille.example.com.est d’ajouter directement la clef de cette zone dans la liste des clefs de confiance.[^] # Re: Et DANE simplement
Posté par Ph Husson (site web personnel) . Évalué à 2.
Du coup on transfert le problème de CA à .com en fait ?
[^] # Re: Et DANE simplement
Posté par claudex . Évalué à 6.
Seulement en partie, parce que Verisign (gestionnaire du .com) ne peut pas signer un certif pour un .be avec DANE alors qu'il le peut avec le modèle actuelle de TLS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et DANE simplement
Posté par rakoo (site web personnel) . Évalué à 3.
Plus haut encore: on transfère le problème de CA à l'ICANN, donc au gouvernement américain.
Tiens, voici un article bien biaisé par un expert en crypto qui soulève quelques problèmes avec DNSSEC. J'ai tendance à être d'accord avec lui, même si ça ne résout toujours pas le problème.
[^] # Re: Et DANE simplement
Posté par claudex . Évalué à 9.
Je ne suis pas d'accord. Bien sûr, un gouvernement peut signer n'importe quoi pour son TLD mais, c'est limité à son TLD. Avec DANE, la Chine ne peut pas signer un certif pour google.com alors qu'elle le peut (et le fait) avec l'implémentation actuelle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et DANE simplement
Posté par briaeros007 . Évalué à 9.
Je ne suis pas d'accord non plus avec l'article.
Il semble confondre beaucoup de choses et surtout se baser sur des "on dit".
dnssec existe depuis longtemps… Son déployement à grande échelle reste récent (après les failles kaminski) et est mis à jour (dernière RFC sur des allocations d'algorithm : 2010).
N'est pas sécurisé … Ben autant que TLS , il se basent sur les même algo. Et les clés sont modifié beaucoup beaucoup plus souvent que celles de TLS (une zsk est modifié entre 2 semaines et 1 mois, à comparer à 2 ans avec un certificat).
Est compliqué à mettre en place… un script, un répertoire spécifique , et une clé à poussé à son registrar tous les 2 ans, c'est pas plus compliqué que la PKI/TLS.
Est cher … à 200-400€ le certificat simple pour une pki standard, vs 0€ en dnssec le calcul est vite fait.
Ne protège pas le "last mile" … pas plus que le TLS. Cf le besoin de clé pinning.
DNSSEC est controlé par les gouvernements… Ni plus, ni moins que les CA, voir même plutot moins.
Il dit que Kadhafi aurait pu utiliser son controle sur le DNSSEC… Si je ne m'abuse les certificats COMODO etc… ont été utilisé par ce même gouvernement, et on parle pas des certificats CA de l'ANSSI pour faire du MITM dans un ministère.
(pour la petite histoire, l'ANSSI ne met pas de tls ni de dnssec sur ses sites ce qui fait qu'il est impossible d'être sur des référentiels de sécurité du gouvernement XD).
Je ne parle pas du patriot act ou de FISA et de ses gag order(NSA inside)
bref, pas convaincu par son argumentaire, d'autant plus qu'il oublit un problème fondamental : c'est la seule solution actuellement contre le cache poisonning qui sera de plus en plus possible avec l'augmentation des débits.
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . Évalué à 0. Dernière modification le 20 avril 2015 à 15:53.
Donc la Chine pourra signer uniquement le .cn et les USA pourront signer la moitié du monde car ils contrôlent le .us et le 3/4 des domaines non-nationaux ( .com, .org, etc..)
Mais comme les USA sont une nation exemplaire qui jamais, au non, jamais n'autoriseront leur agence de renseignement, la NSA, à intercepter les communications privées des gens: Tout va bien, vous pouvez dormir tranquille braves gens…
Nan, nan je déconne: c'est la même merde.
DANE remplace un schéma cassé par un autre. Il ne règle pas absolument pas le problème des attaques MitM en cas d'authorité corrompues.
Il transforme juste un schéma cassé de certification à deux niveaux, en un schéma cassé de certifications à X niveaux.
[^] # Re: Et DANE simplement
Posté par claudex . Évalué à 6.
Sauf les USA contrôlent déjà pleins d'autorités de certification. Donc, ils peuvent déjà signer pour le monde entier. Là, on limite à ¾. C'est un progrès. Il ne reste plus qu'à avoir un script qui permet de vérifier que .com, le .be, le .br, le .ru et le .cn sont bien les mêmes et tu as beaucoup de chance que le contenu n'ait pas été modifié ☺.
Après, tu oublie un point important aussi. Cibler une machine en DNS est bien plus difficile qu'en HTTPS à cause des nombreux caches (bien sûr, si tu as la main sur l'infrastructure du FAI, c'est plus facile1). Tu risque donc que le propriétaire de la clef modifiée s'en rende compte et donc d'être bien moins discret.
si tu as la main en local, tu ajoute ton autorité ou désactive DNSSEC en fonction du cas. ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . Évalué à -1. Dernière modification le 20 avril 2015 à 16:35.
En pratique, tous les noms de domaines des sites à gros trafic sont en .com sous leur control, tu changes uniquement 100% par 99%. Sans parler du fait que la "racine" elle-même a besoin d'être signée
Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com et tu n'y verras que du feu. Tout comme avec le système de CA actuel.
La seul solution à ça est de ré implémenter encore une fois le pinning, mais cette fois avec DANE, comme mentionné dans l'article originel.
J'ai par ailleurs de gros problème avec l'association 1-1 entre DNS et autorité de certification de DANE.
Je veux choisir à qui je fais confiance.
Avec le système actuel, je peux: je l’enlève simplement de la liste des CA de confiance de mon application.
Avec DNSSEC, je ne peux pas : cette autorité est liée d'office à mon nom de domaine.
A mon sens, les hypothétiques avantages de DNSSEC/DANE ne justifient pas sa complexité de déploiement ni les problèmes annexes qu'il génerent :
Des solutions comme TACKs, certificate transparency, ou convergence sont bien plus prometteuse que DANE à mon humble avis.
[^] # Re: Et DANE simplement
Posté par claudex . Évalué à 5.
Et pour la majorité des utilisateurs. On fait quoi ? Parce que pour eux, il en suffit d'une pour foutre la merde partout.
Sans que ça ce voit, c'est bien plus dur, vu que dans la plupart des cas, tu auras plusieurs personnes impactées. D'ailleurs, ce n'est pas que la résolution de google.com, c'est aussi la clef publique.
Ils posent déjà problème avec le HTTPS (accentué par HSTS), l'utilisateur voit un gros warning quand il essaye de se connecté à ses sites préférés.
Des trucs comme certificate transparency seraient bien, malheureusement les CA n'ont pas l'air de se bouger. Peut-être que si leur business se voit menacé par DANE, elles s'y mettront.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . Évalué à 1. Dernière modification le 20 avril 2015 à 21:23.
On implémente le pinning proprement au niveau de TLS ? Et on mets en place le certificate transparency sur le long terme ?
Tu es très optimiste.
Admettons que IE, Opera, Chrome, Safari et Firefox se décident d'implémenter DANE et de l'activer par défaut disons….la semaine prochaine.
Admettons que les infrastructures DNS de TOUS les FAI (même ceux du boudjikistan), les réseaux d'entreprises et TOUS les opérateurs mobiles se décident à forwarder correctement DNSSEC et DANE (ce qui est déjà hautement improbable, ça prendrait des années).
Tout comme IE6 ont pourrit la vie des devs Web pendant 10 ans, tu vas forcément continuer à avoir des utilisateurs sous IE9 ou Android 2.3 qui ne géreront pas correctement DANE pendant des années et des années. Donc rien que pour ceux là, tu devras aussi faire signer ton certificat par une autorité de certification et rentrer dans le business juteux des CAs qui continueroent de vivre paisiblement.
DANE/DNSSEC n'est pas en soit un mauvais standard. Mais c'est un standard qui arrive bien trop tard, quand le système de CA est déja le centre du monde et presque impossible à déloger.
[^] # Re: Et DANE simplement
Posté par gouttegd . Évalué à 5.
Pourquoi pas ? Implémenter DNSSEC/DANE n’interdit pas les autres méthodes. Personne n’a jamais dit que DANE devait être le seul moyen d’authentifier un serveur TLS.
Avec cet argument là, autant ne rien faire du tout…
Encore une fois, DANE n’a pas la prétention de remplacer d’un coup tout le reste. Au contraire, DANE prévoit explicitement la possibilité d’être utilisé en complément du système PKIX. Ceux qui le souhaitent peuvent utiliser DANE exclusivement (sélecteur TLSA sur DANE-TA ou DANE-EE), mais ce n’est pas une obligation.
Au passage, Certificate Transparency est beaucoup moins flexible sur ce plan, puisqu’il interdit explicitement tout certificat qui n’aurait pas été émis par le cartel des CA.
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . Évalué à 1.
Bien, comme ça au lieu d'avoir une surface d'attaque pour faire du MitM, on en aura deux.
Non, on fait simplement des choses avec des étapes de transitions raisonnables.
Il n'a jamais été designé pour les remplacer, uniquement corriger leur problèmes: ce qui est le plus urgent à faire.
Je n'aime pas plus les certificate authority que vous: elles coûtent cher, ont un monopole honteux, une éthiques douteuses pour certaines d'entre elles. Je les verrai avec joie disparaitre.
Mais deployer DANE est juste remplacer un monstre par un autre qui ne corrige pas les problèmes du précédents et qui apporte son propre lot d'emmerdes. Le seul avantage de DANE est la réduction des couts pour les particuliers: plus besoin de payer le CA.
Un internet sans CA viendra bien plus probablement de choses comme :
- convergence, qui introduit le concept de notaries
- monkey-sphere, qui veut authoriser les signatures multiples et donc le création d'un Web-of-trust avec SSL
- namecoin, qui autorise la publication irrévocable via blockchain du fingerprint de tout certificat.
- TACKs, qui permet de faire du Trust-On-First-Use avec TLS/SSL.
Maintenant vous pouvez moinsé.
[^] # Re: Et DANE simplement
Posté par gouttegd . Évalué à 5.
Tu as ton certificat traditionnel émis par une CA reconnue qui autorise les visiteurs à consulter ton site sans avertissements (mais sans sécurité non plus, merci le modèle PKIX…), en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ? Tu ne perturbes en rien le fonctionnement des navigateurs qui ne connaissent pas DANE.
Certificate Transparency corrige quoi au juste ?
Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».
L’objectif de Certificate Transparency est de pouvoir détecter quand une « rogue CA » émet un certificat illégitime. Quand tous les navigateurs exigeront que les certificats soient affublés d’un ou plusieurs SCT pour être acceptés, une CA ne pourra pas émettre de certificats sans l’enregistrer dans les logs de Certificate Transparency (nécessaire pour obtenir le SCT), ce qui permettra à tout le monde de découvrir ce certificat illégitime.
Et après ? Ben rien. Certificate Transparency ne dit absolument rien quand à ce qui doit se passer ensuite. La vision bisounours est que les éditeurs de navigateurs, en constatant que la CA a émis des certificats frauduleux, prendront immédiatement la décision qui s’impose, à savoir virer la CA indélicate de leurs magasins d’autorité de confiance.
C’est tellement naïf que je ne peux pas imaginer une seule seconde que les promoteurs de Certificate Transparency y croient réellement.
On n’a jamais viré sans ménagements une CA des magasins des navigateurs. Quand une CA indélicate est prise la main dans le sac, on s’indigne, on crie (surtout si la CA est chinoise, beaucoup moins si elle est américaine…), mais on tergiverse beaucoup et au final on ne fait pas grand’chose.
(De toute façon une action en suppression immédiate et inconditionnelle au moindre certificat émis en doublon ne serait pas mieux : il peut y avoir des raisons légitimes pour qu’une CA émette un certificat pour un domaine qui en a déjà un ailleurs… par exemple pour fournir le backup pin requis par HPKP.)
La seule raison d’être de Certificate Transparency est d’asseoir un peu plus le cartel des CA, en exigeant :
de la part des navigateurs, qu’un certificat possède un ou plusieurs SCT pour être accepté ;
de la part des journaux Certificate Transparency, qu’un certificat soit émis par une CA reconnue pour l’enregistrer et lui donner son SCT (en particulier, les certificats auto-signés sont explicitement exclus).
Et je ne parle pas du bordel que représente l’implémentation de Certificate Transparency, qui demande des modifications à peu près à tous les niveaux.
Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.
Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.
[^] # Re: Et DANE simplement
Posté par Firwen (site web personnel) . Évalué à 1.
Merci pour ta réponse, j'aime particulièrement ton point de vue sur CA transparency.
Juste quelques points :
Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
TLSA tout seul sans DNSSEC est inutile.
Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.
Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.
L'idée derrière Certificate Transparency est de créer une base publique de tous les certificats émis existants.
Si l'utiliser pour détecter les conneries des CA peut être un premier cas d'utilisation évident.
L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.
Ça l'est. Et je n'ai jamais dit que j'aimais particulièrement cette solution. cf mon commentaires précédents sur les alternatives.
C'est DANE/DNSSEC que je n'aime pas pour tout un tas de raisons evidentes expliquées plus haut.
Nous sommes d'accord.
```
[^] # Re: Et DANE simplement
Posté par briaeros007 . Évalué à 3.
Euh… tu parles en connaissance de cause ou juste ce que tu crois?
En connaissance de cause, parce que j'ai mon domaine perso avec dnssec.
C'est tellement compliqué à déployer que j'ai mis plus de temps à configurer exim et dovecot au petit oignons comme je le voulais que dnssec.
Tellement compliqué à administrer que cela me demande 1 à 2j tous les 2ans (la KSK rollover), et est absolument transparent pour tous les workflow existant.
Aucun serveur ni client ne le supporte … Juste bind, qui est le serveur dns de référence.
Bind supporte même maintenant la gestion automatique des clés. Mais ca doit être parce que c'est trop compliqué …
Bon si un admin esseulé peut le faire tranquillement dans son coin sur sa machine perso, je doute qu'on puisse expliquer que c'est une usine à gaz (comme un MS exchange par ex…)
Euh dans très peu d'organisation pro on filtre les dns.
On gère les résolveurs suivant les zones. Mais on ne filtre (comprendre autoriser certains records et pas d'autres) pas les DNS.
C'est une mauvaise pratique.
Si on veut jouer à celui qui a la plus grosse. Certaines organisations bien plus grosses (d'un ou deux ordres de magnitudes) commencent à utiliser dnssec sur une partie de leur infrastructure. Je présume que c'est parce qu'elles n'y connaissent rien ?
[^] # Re: Et DANE simplement
Posté par gouttegd . Évalué à 4.
DANE est une des méthodes les moins intrusives (beaucoup moins que CT). Tout est déjà en place pour la supporter. Tous les serveurs et résolveurs DNS dignes de ce nom supportent déjà DNSSEC (et DANE n’a pas besoin d’être explicitement pris en charge, les enregistrements TLSA ne sont que des enregistrements DNS comme les autres). Aucun protocole n’a besoin d’être modifié. Tout ce qu’il manque est le support des navigateurs.
Ça c’est complètement faux. Côté serveurs, je le répète, tous les serveurs DNS dignes de ce nom gèrent DNSSEC. Côté client, ce n’est pas parce que les navigateurs regardent ailleurs que personne d’autre n’est intéressé. DNSSEC a bien d’autres intérêts au-delà du seul web.
Les serveurs de courrier électronique y ont un intérêt pour chiffrer les communications SMTP de serveur à serveur (en utilisant DANE pour authentifier le pair d’en face, et donc faire un peu mieux que du chiffrement à l’aveugle sans savoir à qui on parle). Les clients SSH y ont un intérêt pour authentifier les serveurs SSH (enregistrements SSHFP, seulement fiables si on est sûr que l’enregistrement n’est pas frauduleux).
Je ne dis pas que DNSSEC n’est pas monstrueux. Personne ne peut lire le RFC décrivant NSEC3 et ne pas penser que c’est une monstrueuse usine à gaz. Mais d’une part, ce n’est pas plus une usine à gaz que bien d’autres protocoles que l’on utilise sans même y penser (dont, au passage, X.509 et TLS, dont la complexité effare bien des experts en sécurité), et d’autre part, c’est complètement déployable et même déployé.
C’est du même niveau que les magouilles consistant à fabriquer des faux certificats à la volée. Que DNSSEC contrarie ce genre d’agissements est une feature, pas un bug. Les responsables « d’environnements pro » qui veulent contrôler le moindre traffic de leurs utilisateurs devront le faire de manière ouverte et assumée, pas dans le dos des utilisateurs.
Lesquels, et comment ? Par ailleurs, rien dans la description de CT ne laisse transparaître une telle « idée sur le long terme ».
[^] # Re: Et DANE simplement
Posté par rakoo (site web personnel) . Évalué à 4.
Ah bah si justement: CNNIC a été supprimé du magasin Chrome et du magasin Firefox, a peine 1 semaine après les faits. Après je suis a peu près sur qu'une racine américaine n'aurait jamais été enlevé aussi vite.
[^] # Re: Et DANE simplement
Posté par gouttegd . Évalué à 2.
Je corrige mon propos, Certificate Transparency pourrait être utile dans un cas : celui des magouilles du genre Superfish, où un logiciel malveillant ajoute son propre certificat au magasin du système et s’en sert pour forger des faux certificats à la volée. Les faux certificats ne pourraient pas obtenir de SCT et seraient donc refusés.
Cette technique étant assez répandue (outre le cas emblématique de Lenovo, elle est semble-t-il courante en entreprise, pour déchiffrer le traffic des employés), c’est un cas d’utilisation non-négligeable.
Néanmoins :
D’une part, CT n’est pas la seule technique potentiellement efficace contre cette attaque (DANE, Convergence, Monkeysphere, éventuellement le pinning si la première connexion au site se fait avant l’installation du malware, …).
D’autre part, en fait aucune technique ne peut être réellement efficace contre cette attaque (CT pas plus que les autres), puisque qu’elle part du principe que l’attaquant a la main-mise sur la machine du client (via un malware, ou si l’attaquant est l’administrateur de l’entreprise). C’est une conclusion établie en matière de sécurité qu’il n’y a pas de sécurité qui tienne la route si la machine terminale est compromise. Les nouveaux Superfish en puissance pourront toujours s’adapter pour contourner n’importe laquelle des méthodes envisagées ici (CT ? On désactive la vérification des jetons SCT. DANE ? On falsifie les réponses DNS — rappelez-vous que DNSSEC ne sécurise pas le dernier kilomètre et suppose que le résolveur validant est de confiance. Convergence ? Je n’ai pas assez étudié le principe, mais je ne doute aucunement qu’un contournement soit possible, peut-être en manipulant la liste des notaries. Etc, etc).
[^] # Re: Et DANE simplement
Posté par Moonz . Évalué à 2. Dernière modification le 20 avril 2015 à 09:18.
Être implémenté quelque part ?
[^] # Re: Et DANE simplement
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
On parle du Web, là, qui est quelque chose de complètement fossilisé. Les éditeurs de navigateurs Web ne sont pas assez aventureux et réactifs pour implémenter un truc pareil avant vingt ans, je dirais.
[^] # Re: Et DANE simplement
Posté par groumly . Évalué à 4.
Web? T'es sur? On parlerais pas d'internet des fois?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Et DANE simplement
Posté par oinkoink_daotter . Évalué à 2.
C'est triste ton avis sur ipvquat'.
# Configuration du serveur web et anticipation du changement d'autorité
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Des exemples de configuration Lighttpd, Apache httpd et Nginx sur https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
À voir ces exemples, j'en déduis que le max-age n'est pas géré dynamiquement à l'approche de l'expiration du certificat : si on a pris par exemple la valeur suggérée par la RFC de 60 jours pour le max-age, pendant les deux mois précédant l'expiration du certificat, on continue à annoncer un épinglage sur 60 jours. Le jour de l'expiration :
Bref ça nécessite d'anticiper un peu les changements d'autorité.
[^] # Re: Configuration du serveur web et anticipation du changement d'autorité
Posté par Ph Husson (site web personnel) . Évalué à 2.
C'est pour ça que tu peux (en fait sur https://www.bortzmeyer.org/7469.html c'est marqué DOIT) mettre plusieurs certificats.
Un mois avant l'expiration, tu rajoute ton nouveau certificat, que t'utilise pas encore, et le jour de l'expiration tu changes de certificat, et c'est bon.
[^] # Re: Configuration du serveur web et anticipation du changement d'autorité
Posté par claudex . Évalué à 4.
Tu peux tout à fait avoir un script qui calcul le temps restant avant l'expiration de ton certificat et qui met à jour ta conf en fonction. Ça ne ne semble pas compliquer à faire.
Ça c'est sûr que ça risque de poser des problèmes. Et le mode "report only" me semble bien penser pour tester en vrai sans tout casser.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Configuration du serveur web et anticipation du changement d'autorité
Posté par Thomas Douillard . Évalué à 4.
Tu veux dire que c'est un mode qui active une IA cool ?
Ça pique les yeux /o\
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.