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.
[^] # Re: Google, roi du pétrole
Posté par gouttegd . En réponse au lien HPKP est (bientôt) mort. É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.