D'autre part, ma réelle inquiétude est de savoir jusqu'où Google compte aller. Il n'y a qu'un pas à franchir entre afficher une alerte parce que le serveur du correspondant n'utilise pas du tout TLS, et parce qu'il utilise un certificat auto-signé
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CA
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
# Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 8. Dernière modification le 15 février 2016 à 00:03.
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.