Ça va, c'est la fête ? Tout le monde met sa machine à jour tous les deux jours, donc on fait ce qu'on veut ?
Bon, sinon, encore une question un peu… orientée : si j'ai bien compris, la présence de Expect-CT demande au navigateur d'aller faire une requête à des journaux publics de Certificate Transparency. Alors, OK, on n'est pas obligé de prendre ceux de Google, mais ça veut dire qu'ils auront des statistiques sur tous les sites web visités en HTTPS, ou bien je me trompe ?
la présence de Expect-CT demande au navigateur d'aller faire une requête à des journaux publics de Certificate Transparency.
C’est un peu (beaucoup, en fait, parce que quand Google décide de monter une usine à gaz pour donner l’impression qu’ils solutionnent un problème, ils ne font pas les choses à moitié) plus compliqué que ça.
Le navigateur n’a pas à aller chercher lui-même les jetons SCT. C’est au serveur de les lui fournir, par trois moyens possibles :
embarquer les jetons directement dans le certificat, sous la forme d’une extension X.509 (c’est à la CA émettrice du certificat de le faire, évidemment, le serveur ne peut pas faire ça de lui-même) ;
servir les jetons SCT « à côté » du certificat lors de la poignée de main TLS, via une extension du protocole TLS ;
servir les jetons SCT dans une réponse OCSP « épinglée », via une extension du protocole OCSP.
(Oui, le bon fonctionnement de Certificate Transparence nécessite de modifier toute la chaine HTTPS, depuis les CA jusqu’au navigateur final. À côté de ça DANE et HPKP ne nécessitent qu’une prise en charge par le navigateur indépendamment de tous les autres acteurs, mais ça n’a pas empêché Google de faire preuve d’une phénoménale mauvaise foi en promouvant CT comme « plus simple ».)
Après, une fois que le navigateur a en mains les jetons SCT, il doit aller vérifier auprès d’un « auditeur CT » que les jetons sont valides, c’est-à-dire que les certificats correspondants ont bel et bien été publiés dans des journaux CT. Cette vérification doit normalement être faite par lots et « de temps en temps » (et non pas à chaque connexion), de sorte que l’auditeur n’a pas une vision en temps réel de toutes les connexions HTTPS d’un client. Mais oui, l’auditeur CT pourra quand même connaître tous les jetons dont le client demande la validation, et donc tous les serveurs visités.
Une idée de pourquoi DANE n’est pas davantage répandu/implémenté ? Je crois qu’il y avait même un début d’implémentation dans Chrome, mais ils l’ont retiré.
Du côté de chez Google ? De mémoire les deux principales raisons officiellement avancées sont :
DNSSEC (dont DANE dépend) se repose trop sur RSA 1024, alors que tout le monde veut se débarasser de RSA 1024 ;
DANE augmente les risques de fishing, puisque n’importe qui peut obtenir un nom de domaine pour, par exemple, paypa1.com, et publier dans cette zone un certificat qui serait accepté par le navigateur (si les navigateurs supportaient DANE).
Le premier argument était déjà de mauvaise foi à l’époque : les clefs DNSSEC de 1024 étaient déjà en train d’être progressivement remplacées par des clefs de 2048 bits, et DNSSEC permet aussi l’utilisation de clefs ECDSA pour ceux qui trouvent que des clefs RSA de 2048 bits sont trop volumineuses pour le DNS.
Pour ce qui est du deuxième… mort de rire, comme si les autorités de certification faisaient quoi que ce soit contre le phishing… (Il est vrai que certaines prennent le temps de vérifier, avant de délivrer un certificat, que le nom demandé n’est pas « trop proche » d’un nom bien connu comme paypal et assimilés. Mais : ① toutes ne le font pas — elles n’ont aucune obligation de le faire — et la magie du système des CA est que la fiabilité du système est celle de la moins fiable des CA ; ② cette protection anti-fishing, quand elle est mise en œuvre que pour protéger les « gros » sites bien connus, les autres peuvent aller se faire voir.)
La véritable raison est que pour Google, toute technique qui permettrait de se passer des CA (comme DANE ou HPKP quand on les utilise pour épingler un certificat auto-signé ou signé par une autorité « non-reconnue ») est à banir. Pour des raisons qui m’échappent, Google considère que les CA sont une pierre angulaire d’Internet et il est hors de question de s’en passer. Certificate Transparency sert précisément à rendre les CA encore plus indispensables qu’elles ne le sont déjà. À cela s’ajoute une certaine défiance envers tout ce qui passe par le DNS.
Pour ceux qui trouveraient que j’exagère sur les intentions de Google : regardez par exemple ce qu’ils ont fait avec leur proposition SMTP-STS (SMTP Strict Transport Security, en gros la transposition de HTTP STS pour les serveurs mails). La première version du brouillon était prévue pour interagir sans heurts avec DANE : il y était dit que SMTP-STS pouvait être utilisé aussi bien seul que conjointement avec DANE, et qu’il y avait des avantages spécifiques à utiliser les deux ; l’utilisation d’un certification auto-signé (ou signé par une CA « non-reconnue ») était aussi explicitement autorisée si ledit certificat était publié dans le DNS. Un mois plus tard, le brouillon suivant fait machine arrière toute : la cohabitation entre DANE et SMTP-STS (renommé MTA-STS) n’est plus envisagée, DANE est désormais décrit comme un mécanisme concurrent ; la politique STS, qui pouvait auparavant être publié dans le DNS, doit désormais être récupéré via HTTPS ; et la possibilité d’utiliser un certificat auto-signé a complètement disparu, désormais le certificat doit être signé par une CA « reconnue ». Voyez-y ce que ce vous voulez, mais pour moi entre le premier et le deuxième brouillon quelqu’un chez Google (la plupart des auteurs des deux brouillons sont chez Google) s’est rappelé que tout ce qui pouvait permettre de réduire l’emprise des CA était à proscrire.
Au-delà de chez Google, pourquoi DANE n’est pas davantage répandu de manière générale ? Probablement un problème d’œuf et de poule, je suppose : les navigateurs ne l’implémentent pas (en tout cas pas nativement), donc côté serveur on ne le déploie pas (note : côté serveur, il n’y a plus rien à implémenter, tout ce dont on a besoin est d’un serveur DNS supportant DNSSEC, ce qui est le cas de n’importe quel serveur DNS digne de ce nom), donc on ne l’implémente pas côté client, donc on ne le déploie pas côté serveur, et ainsi de suite… Sans un « gros » pour pousser les choses (comme Google qui pousse Certificate Transparency), ça ne va pas bien loin…
(Je pense personnellement qu’on franchirait déjà un grand pas si les systèmes d’exploitation pouvait être fourni avec un résolveur DNS validant par défaut, ce qui à ma connaissance n’est aujourd’hui le cas d’aucun OS. Ce n’est pas normal qu’il faille être un « geek » pour pouvoir bénéficier d’une résolution DNSSEC sur sa machine…)
Et allez, je vais donner un argument pour Google : DANE, d'un point de vue du navigateur, c'est lent. C'est lent de l'ordre de la demi-seconde, mais c'est lent pour un fournisseur de services qui compte les millisecondes. Avec DANE, il faut faire plusieurs requêtes, parfois avec un nouvel essai en TCP, avant même de se connecter au site. Les deux pourraient être fait en parallèle, mais bon.
Personnellement, mon résolveur local (unbound) fait la validation DNSSEC (ce qui n'est pas tout à fait pareil), et euh… ça va plutôt pas mal en fait :) Mais ça serait plus rapide sans ça.
# Google, roi du pétrole
Posté par Glandos . Évalué à 3.
'Tain mais Google quoi :
Ça va, c'est la fête ? Tout le monde met sa machine à jour tous les deux jours, donc on fait ce qu'on veut ?
Bon, sinon, encore une question un peu… orientée : si j'ai bien compris, la présence de
Expect-CTdemande au navigateur d'aller faire une requête à des journaux publics de Certificate Transparency. Alors, OK, on n'est pas obligé de prendre ceux de Google, mais ça veut dire qu'ils auront des statistiques sur tous les sites web visités en HTTPS, ou bien je me trompe ?[^] # Re: Google, roi du pétrole
Posté par gouttegd . Évalué à 7.
C’est un peu (beaucoup, en fait, parce que quand Google décide de monter une usine à gaz pour donner l’impression qu’ils solutionnent un problème, ils ne font pas les choses à moitié) plus compliqué que ça.
Le navigateur n’a pas à aller chercher lui-même les jetons SCT. C’est au serveur de les lui fournir, par trois moyens possibles :
(Oui, le bon fonctionnement de Certificate Transparence nécessite de modifier toute la chaine HTTPS, depuis les CA jusqu’au navigateur final. À côté de ça DANE et HPKP ne nécessitent qu’une prise en charge par le navigateur indépendamment de tous les autres acteurs, mais ça n’a pas empêché Google de faire preuve d’une phénoménale mauvaise foi en promouvant CT comme « plus simple ».)
Après, une fois que le navigateur a en mains les jetons SCT, il doit aller vérifier auprès d’un « auditeur CT » que les jetons sont valides, c’est-à-dire que les certificats correspondants ont bel et bien été publiés dans des journaux CT. Cette vérification doit normalement être faite par lots et « de temps en temps » (et non pas à chaque connexion), de sorte que l’auditeur n’a pas une vision en temps réel de toutes les connexions HTTPS d’un client. Mais oui, l’auditeur CT pourra quand même connaître tous les jetons dont le client demande la validation, et donc tous les serveurs visités.
[^] # Re: Google, roi du pétrole
Posté par NiKaro (site web personnel) . Évalué à 2.
Une idée de pourquoi DANE n’est pas davantage répandu/implémenté ? Je crois qu’il y avait même un début d’implémentation dans Chrome, mais ils l’ont retiré.
[^] # Re: Google, roi du pétrole
Posté par gouttegd . Évalué à 7.
Du côté de chez Google ? De mémoire les deux principales raisons officiellement avancées sont :
Le premier argument était déjà de mauvaise foi à l’époque : les clefs DNSSEC de 1024 étaient déjà en train d’être progressivement remplacées par des clefs de 2048 bits, et DNSSEC permet aussi l’utilisation de clefs ECDSA pour ceux qui trouvent que des clefs RSA de 2048 bits sont trop volumineuses pour le DNS.
Pour ce qui est du deuxième… mort de rire, comme si les autorités de certification faisaient quoi que ce soit contre le phishing… (Il est vrai que certaines prennent le temps de vérifier, avant de délivrer un certificat, que le nom demandé n’est pas « trop proche » d’un nom bien connu comme paypal et assimilés. Mais : ① toutes ne le font pas — elles n’ont aucune obligation de le faire — et la magie du système des CA est que la fiabilité du système est celle de la moins fiable des CA ; ② cette protection anti-fishing, quand elle est mise en œuvre que pour protéger les « gros » sites bien connus, les autres peuvent aller se faire voir.)
La véritable raison est que pour Google, toute technique qui permettrait de se passer des CA (comme DANE ou HPKP quand on les utilise pour épingler un certificat auto-signé ou signé par une autorité « non-reconnue ») est à banir. Pour des raisons qui m’échappent, Google considère que les CA sont une pierre angulaire d’Internet et il est hors de question de s’en passer. Certificate Transparency sert précisément à rendre les CA encore plus indispensables qu’elles ne le sont déjà. À cela s’ajoute une certaine défiance envers tout ce qui passe par le DNS.
Pour ceux qui trouveraient que j’exagère sur les intentions de Google : regardez par exemple ce qu’ils ont fait avec leur proposition SMTP-STS (SMTP Strict Transport Security, en gros la transposition de HTTP STS pour les serveurs mails). La première version du brouillon était prévue pour interagir sans heurts avec DANE : il y était dit que SMTP-STS pouvait être utilisé aussi bien seul que conjointement avec DANE, et qu’il y avait des avantages spécifiques à utiliser les deux ; l’utilisation d’un certification auto-signé (ou signé par une CA « non-reconnue ») était aussi explicitement autorisée si ledit certificat était publié dans le DNS. Un mois plus tard, le brouillon suivant fait machine arrière toute : la cohabitation entre DANE et SMTP-STS (renommé MTA-STS) n’est plus envisagée, DANE est désormais décrit comme un mécanisme concurrent ; la politique STS, qui pouvait auparavant être publié dans le DNS, doit désormais être récupéré via HTTPS ; et la possibilité d’utiliser un certificat auto-signé a complètement disparu, désormais le certificat doit être signé par une CA « reconnue ». Voyez-y ce que ce vous voulez, mais pour moi entre le premier et le deuxième brouillon quelqu’un chez Google (la plupart des auteurs des deux brouillons sont chez Google) s’est rappelé que tout ce qui pouvait permettre de réduire l’emprise des CA était à proscrire.
Au-delà de chez Google, pourquoi DANE n’est pas davantage répandu de manière générale ? Probablement un problème d’œuf et de poule, je suppose : les navigateurs ne l’implémentent pas (en tout cas pas nativement), donc côté serveur on ne le déploie pas (note : côté serveur, il n’y a plus rien à implémenter, tout ce dont on a besoin est d’un serveur DNS supportant DNSSEC, ce qui est le cas de n’importe quel serveur DNS digne de ce nom), donc on ne l’implémente pas côté client, donc on ne le déploie pas côté serveur, et ainsi de suite… Sans un « gros » pour pousser les choses (comme Google qui pousse Certificate Transparency), ça ne va pas bien loin…
(Je pense personnellement qu’on franchirait déjà un grand pas si les systèmes d’exploitation pouvait être fourni avec un résolveur DNS validant par défaut, ce qui à ma connaissance n’est aujourd’hui le cas d’aucun OS. Ce n’est pas normal qu’il faille être un « geek » pour pouvoir bénéficier d’une résolution DNSSEC sur sa machine…)
[^] # Re: Google, roi du pétrole
Posté par Glandos . Évalué à 3.
Incroyablement merci de ce rapport détaillé.
Et allez, je vais donner un argument pour Google : DANE, d'un point de vue du navigateur, c'est lent. C'est lent de l'ordre de la demi-seconde, mais c'est lent pour un fournisseur de services qui compte les millisecondes. Avec DANE, il faut faire plusieurs requêtes, parfois avec un nouvel essai en TCP, avant même de se connecter au site. Les deux pourraient être fait en parallèle, mais bon.
Personnellement, mon résolveur local (unbound) fait la validation DNSSEC (ce qui n'est pas tout à fait pareil), et euh… ça va plutôt pas mal en fait :) Mais ça serait plus rapide sans ça.
[^] # Re: Google, roi du pétrole
Posté par cosmocat . Évalué à 4.
Attends:
c'est peut-être pas la même chose que "deprecating"?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.