OK AES128 n'est pas encore troué, mais quand même bizarre de ne pas prendre du AES256 alors qu'on sait faire.
La taille de la clef n’est pas tout. Oui, Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM. Donc, même si ton serveur propose du AES256-GCM et du AES256-CBC, Firefox lui doit choisir entre AES128-GCM et AES256-CBC — et il n’y a rien d’anormal à privilégier le premier :
128-GCM is far, far more desirable than 256-CBC.
Et indépendamment des questions de modes d’opération, il y a d’autres raisons qui peuvent faire qu’un algorithme utilisant des clefs de 256-bits ne soit pas forcément plus sûr qu’un algorithme à clef de 128-bits. Dans le cas d’AES par exemple, il existe des attaques qui ciblent spécifiquement les versions 192/256-bits et qui sont inopérantes contre la version 128-bits. Bon, ce sont des attaques purement théoriques, mais ça illustre le fait qu’il vaut mieux réfléchir un peu avant de foncer bille en tête vers les clefs les plus grosses…
(Au passage, une clef RSA de 4096-bits pour un certificat valable deux ans, je trouve ça complètement disproportionné.)
Les FAI fournissent des webmails parce que c'est utilisé.
Forcément vu que certains ne laissent pas le choix…
Ils fournissent aussi des accès POP3/IMAP/SMTP
Pas tous. Chez le mien, l’accès POP3/IMAP ne fonctionne inexplicablement pas depuis certains réseaux (celui d’OVH notamment) — le serveur coupe brutalement la connexion à peine celle-ci établie.
Ceux qui sont vraiment contre ton utilisation génial de ton MUA favoris ce sont GMail, hotmail, yahoo
J’ai déjà eu affaire à ces trois-là, et aucun ne m’a jamais posé de problèmes pour accéder aux messages ou en envoyer en passant par les protocoles standards indépendamment du webmail…
il y a un système plus ou moins centralisé sur chaque OS pour éviter exactement ce souci
Je pense que le problème réside dans le « plus ou moins ».
Il y a bien un magasin centralisé, system-wide et disponible pour toutes les applications sur Windows et Mac OS X, et sur ces systèmes Chrome en fait usage.
Debian a son paquet ca-certificates (qui reprend essentiellement les certificats de NSS d’ailleurs, en en rajoutant éventuellement quelques autres comme celui de CAcert à une époque) et ses certificats dans /etc/ssl/certs, mais d’autres distributions ont leur propre système. Il n’existe pas d’emplacement standardisé qui serait valable sur n’importe quelle distribution.
À noter en revanche le projet p11-kit qui va dans ce sens.
Je pense qu’au moins une partie du problème pourrait être lié à ce qui est apparemment un bug connu de Chrome (section ”Issue 2: Out-of-date NSS and cross-signed roots”) :
A bug in NSS caused Chrome on Linux to use cached cross-signed roots even when a shorter and newer chain existed.
Je pense que c’est ce qui explique la chaîne à six niveaux observé avec Chrome.
Le dernier certificat intermédiaire envoyé par LinuxFR.org (CN=USERTrust RSA Certification Authority, serial 13:EA:28:70:5B:F4:EC:ED:0C:36:63:09:80:61:43:36) est signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A.
Il existe (au moins) deux certificats utilisant cette clef :
CN=AddTrust External CA Root, serial 0x1, auto-signé;
CN=AddTrust External CA Root, serial 51:26:0A:93:1C:E2:7F:9C:C3:A5:5F:79:E0:72:AE:82, signé par la clef 53:32:D1:B3:CF:7F:FA:E0:F1:A0:5D:85:4E:92:D2:9E:45:1D:B4:4F.
Cette clef 53:32:D1.etc. est utilisée par (au moins) trois certificats :
CN=UTN - DATACorp SGC, serial 44:BE:0C:8B:50:00:21:B4:11:D3:2A:68:06:A9:AD:69, auto-signé
CN=UTN - DATACorp SGC, serial 46:EA:F0:96:05:4C:C5:E3:FA:65:EA:6E:9F:42:C6:64, signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A (celle des certificats AddTrust External CA Root ci-dessus, vous suivez ?), révoqué le 14 décembre
CN=UTN - DATACorp SGC, serial 53:7B:76:56:4F:29:7F:14:DC:69:43:E9:22:AD:2C:79, lui aussi signé par la clef AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A et lui aussi révoqué le 14 décembre.
On est donc bien dans le cas « racines cross-signées » entre AddTrust External CA Root et UTN - DATACorp SGC.
Dans les versions récentes de NSS, seul le certificat AddTrust External CA Root auto-signé est présent dans le magasin des Builtin Object Tokens (les certificats codés « en dur » dans le navigateur). Cela ne laisse donc qu’une racine possible pour rattacher le dernier certificat intermédiaire envoyé par LinuxFR.org, et il n’y a pas de problème.
Mais si le magasin des certificats cachés (les certificats que le navigateur accumule au gré de la navigation) vient à contenir à la fois la version cross-signée du certificat AddTrust External CA Rootet l’une des deux versions cross-signées du certificat UTN - DATACorp SGC, le navigateur peut construire la chaîne de certification suivante :
USERTrust RSA Certification Authority → AddTrust External CA Root (version cross-signée, en cache) → UTN - DATACorp SGC (version cross-signée, en cache) → AddTrust External CA Root (version auto-signée, dans le magasin en dur)
On est donc bien, me semble-t-il, dans le cas du bug évoqué plus haut (ou un bug similaire), où le navigateur construit une chaine de certification à rallonge en utilisant des certificats cachés alors qu’une chaîne plus courte est possible.
Il reste que je ne comprends toujours pas comment/pourquoi la construction de la chaine de certification varierait en fonction du FAI utilisé pour se connecter…
Apparemment, le certificat UTN - DATACorp SGC (numéro de série 53:7b:76:56:4f:29:7f:14:dc:69:43:e9:22:ad:2c:79) a bel et bien été révoqué par Comodo le 14 décembre (probablement parce qu’il était signé avec un hash SHA-1, que la plupart des navigateurs ont prévu de ne plus accepter) :
$ wget http://crl.comodo.net/AddTrustExternalCARoot.crl
$ openssl crl -noout -text -inform DER -in AddTrustExternalCARoot.crl
[…]
Revoked Certificates:
Serial Number: 537B76564F297F14DC6943E922AD2C79
Revocation Date: Dec 14 15:58:30 2015 GMT
[…]
Du coup, ça expliquerait le code d’erreur NET::ERR_CERT_REVOKED, qui concernerait alors non pas le certificat de linuxfr.org mais un des certificats parents.
Mais ce que je ne comprends toujours pas, c’est pourquoi le chemin de certification passe par ce certificat dans un cas et pas dans l’autre…
Au cas où, tu peux vérifier que la chaîne envoyée par le serveur de linuxfr.org est bien la même avec les deux adresses ?
Même commande que celle suggérée par Xavier Claude ci-dessus, avec en plus l’option -showcerts :
Déjà normalement le serveur doit fournir la chaîne de certification, c'est plus propre
Pas jusqu’à la racine. Le serveur est supposé fournir une chaîne incluant jusqu’au dernier certificat intermédiaire.
C’est ce que fait le serveur de LinuxFR.org, qui fournit les certificats suivants :
*.linuxfr.org (le certificat terminal, celui du serveur proprement dit)
Gandi Standard SSL CA 2 (le certificat de Gandi)
USERTrust RSA Certification (certificat intermédiaire de Comodo).
À partir de là, rattacher le dernier certificat de la chaîne fournie par le serveur à une racine présente dans le magasin est de la responsabilité du navigateur, qui va s’acquitter de cette tâche en fonction des racines qu’il a à sa disposition.
Même avec la même clé, vu que le CN n'est pas le même, ça ne devrait pas passer.
En réalité les Subject de l’ancien certificat intermédiaire de Comodo et celui de la nouvelle racine sont identiques (c’est C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root dans les deux cas). Le nom AddTrust External Root (sans le « CA ») qui apparaît dans la liste des certificats de Chrome n’est qu’un nom d’affichage. (J’ai utilisé ce nom-là dans mon post ci-dessus pour pouvoir distinguer entre le certificat intermédiaire et la nouvelle racine.)
soit le browser à en interne le certif de GANDI
À ma connaissance aucun navigateur n’intègre le certificat de Gandi directement.
Ce qui se passe apparemment est qu’il y a eu un changement de racine.
Comodo (signataire de Gandi, lui-même signataire de LinuxFR.org) utilisait comme racine le certificat UTN - DATACorp SGC, qui signait un certificat intermédiaire AddTrust External CA Root (lui-même signant un autre certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, qui est le dernier certificat envoyé par le serveur de LinuxFR.org).
Maintenant, la clef du premier certificat intermédiaire AddTrust External CA Root a été ré-utilisée pour (auto)signer une nouvelle racine, AddTrust External Root.
Comme AddTrust External CA Root (ancien certificat intermédiaire) et AddTrust External Root utilisent la même clef, il y a deux chaînes de certification possibles pour LinuxFR.org:
Comodo (nouvelle racine, même clef que intermédiaire 2 ci-dessus) (CN=AddTrust External Root)
Le choix d’une chaîne ou de l’autre dépend des racines présentes dans le magasin du navigateur. Dans ton cas, apparemment Chrome a intégré la nouvelle racine de Comodo et n’a donc plus besoin de remonter jusqu’à l’ancienne racine, contrairement à Firefox.
(Pour info, chez moi, Firefox 38.5 considère déjà le premier certificat intermédiaire de Comodo, USERTrust RSA Certification Authority, comme une racine, donc la chaîne s’arrête à ce certificat.)
L'idée que je développe est similaire au HTTPS actuel
C’est entre autres ce que je lui reproche. Le système PKIX est tout sauf un modèle à suivre, ce serait même plutôt l’exemple de ce qu’il ne faut pas faire. Dois-je expliquer encore une fois (j’ai l’impression de le faire au moins une fois par semaine sur LinuxFR) que les CA ne servent à rien ? Que payer 99 dollars par an pour un joli certificat « à validation étendue » n’empêchera pas un attaquant de présenter à sa victime un certificat signé par l’une quelconque des what mille autres autorités de certification auquel les navigateurs font confiance ?
À moins d'avoir un anti-spam je ne vois pas très bien comment faire.
Où ai-je dit que je n’avais pas d’anti-spam ?
J’ai dit que je ne voulais pas d’un anti-spam basé sur un principe du genre « seuls ceux que je connais, ou ceux qui ont été avalisés par une entité à laquelle je fais confiance, peuvent m’envoyer des mails — les autres vont se faire voir ».
Dans le même ordre d’idée, je peste également contre les anti-spams du genre « l’adresse IP de l’émetteur est dans un bloc chinois ou russe, je jette » (j’ai déjà eu le cas où un chercheur moscovite a eu du mal à me contacter à cause de ça) ou « l’adresse est dans une blacklist établie sur des critères que je connais à peine, je jette » (là c’est moi qui a eu du mal à contacter quelqu’un, parce que son opérateur rejettait tous les mails provenant du /24 où avait le malheur de se trouver mon serveur).
Mais je n’ai rien contre des techniques anti-spam qui laissent moins de place à l’arbitraire. Je n’ai aucun scrupule à rejetter des mails qui ne passent pas la validation SPF par exemple (si l’enregistrement SPF du domaine émetteur m’y autorise, évidemment), ou à fermer la porte à des clients qui ne respectent pas le protocole SMTP.
Nul n’a besoin d’autorisation pour m’envoyer un mail. OK, mais ça ne veut pas forcément dire que je vais accepter tout ce qu’on m’envoie.
je propose simplement une idée, qui mérite d'être creusée
Et moi je te dis simplement ce que j’en pense. C’est pour ça qu’on propose des idées, en général — et non uniquement pour s’entendre dire que c’est une idée géniale…
sans même chercher le potentiel derrière
Donc tu es déjà convaincu qu’il y a du potentiel, et que c’est juste nous qui sommes trop bornés pour le chercher. Bon, ben pas la peine de discuter dans ce cas.
Typiquement je parle d'un « état », mais il est évident que le système serait le même avec « plusieurs états »
Ce n’est pas du tout évident pour moi, tu peux expliquer ?
Ensuite, vous semblez considérer que toute idée que l'état soit maître d'une certaine régulation est foncièrement une mauvaise chose. Alors perso je préfère très nettement que la régulation soit faite par un service public français plutôt qu'un tas de sociétés américaines, dont le but est de faire un max d'argent.
Dans le cas qui nous intéresse (le mail), je ne veux ni d’une régulation par un ou des états, ni d’une régulation par des sociétés privés.
Je veux que n’importe qui puisse m’envoyer un mail, d’où qu’il soit, sans avoir à solliciter une quelconque autorisation ou à montrer patte blanche devant une quelconque autorité, qu’elle soit étatique ou privée.
Et si le spam est le prix à payer pour ça, je l’accepte.
On pourrait tout à fait imaginer un service de l'état, dont le rôle est de signer les clef GPG de tout serveur non spammeur
Pêle-mêle :
Quel état ? La France ? Quid du reste du monde ? Soit on accepte que les mails venant de serveur avalisés par cet hypothétique service, et alors on se coupe du reste du monde (je ne doute pas que ça plairait à certains), soit on n’exige pas de signatures pour les mails venant de l’étranger, et le « service de l’état » n’est qu’une coquille vide totalement inutile. Ou alors tu envisageais que ce service pourrait aussi signer les clefs d’opérateurs non-français ? Mais pourquoi lesdits opérateurs se plieraient-ils à ça ?
Déjà que l’État n’a même d’autorité de certification qui lui soit propre (les certificats des sites gouvernementaux français sont signés par des CA privées, souvent américaines), je doute fort de la volonté de mettre en place un tel service.
Non seulement il n’y aurait qu’une seule entité qui déciderait de qui est ou non un spammeur, mais en plus ce serait une entité gouvernementale ? Non merci. Confier un tel pouvoir à une seule entité ne peut que conduire à des abus.
on pourrait avoir plusieurs entité qui signent les clés, plus ou moins stricte, avec des but différents, etc. bref, exactement comme pour les certificats SSL à l'heure actuelle.
Et comme pour les certificats SSL à l’heure actuelle, ça ne servirait à rien du tout.
S’il y a plusieurs entités, il y en aura forcément qui signeront des spammeurs que d’autres entités auront refusé de signer (tu le dis toi-même : des entités plus ou moins strictes). Qui décidera alors de la liste des entités auxquelles on fait confiance ? Les utilisateurs ? L’exemple des certificats X.509 montre clairement que c’est totalement irréaliste (qui a déjà fait le ménage dans la liste des CA racines de son navigateur pour ne garder que celles en lesquelles il a confiance ?). Dans les faits, ce sont les éditeurs de systèmes/logiciels (Microsoft, Apple, Mozilla, etc.) qui décident — et le résultat, c’est que tout le monde fait par défaut confiance à plusieurs centaines d’autorités à l’intégrité ou à la fiabilité douteuse (certaines ont déjà prouvé qu’elles n’étaient pas dignes de confiance).
Je suis bluffé par le filtre d’inpainting. Bluffé, et un peu inquiet aussi.
J’ai eu beau essayer tous les « trucs » que j’utilise habituellement pour vérifier si une image a été trafiquée (comme, pousser le contraste et/ou la luminosité à fond, jouer avec les courbes ou les gradient maps — cela fait presque toujours apparaître des « anomalies » qui révèlent que Photoshop ou Gimp sont passés par là…), je n’ai pas réussi à détecter quoi que ce soit d’anormal sur l’image de la figure 3.1.
Du coup, je me demande : est-ce que vous vous intéressez aussi à des méthodes de détection de ce genre de modifications ?
La possibilité de modifier une photo sans que rien ne vienne trahir la manipulation m’effraie un peu…
et je n’ai pas l’impression, à voir la documentation de Twisted, que cette fonction loadPEM prenne en compte les éventuels certificats intermédiaires contenu dans le fichier.
Une possibilité semble être de passer par un ContextFactory personnalisé :
from twisted.internet.ssl import DefaultOpenSSLContextFactory
from OpenSSL import SSL
class CustomSSLContextFactory(DefaultOpenSSLContextFactory):
def __init__(self, private_key_file, chain_file):
self._context = SSL.Context(SSL.TLSv1_METHOD)
self._context.use_certificate_chain_file(chain_file)
self._context.use_privatekey_file(private_key_file)
et de l’utiliser à la place de cert.options() dans l’appel à listenSSL :
Du moins, c’est le principe. Je n’ai pas d’installation fonctionnelle de SàT/Libervia pour tester, sinon j’aurais envoyé un patch en bonne et due forme.
Let's Encrypt il faut reconnaître que la facilité c'est un truc qu'ils ont bien fait : en moins d'1/2 heure lecture de doc incluse j'ai pu changer les certificats.
Non. Lis le commentaire que je viens de poster un peu plus haut, la configuration de libervia.org est incorrecte.
Ce n’est pas un problème de version de Firefox (ou de n’importe quel navigateur).
Le problème est que le serveur libervia.org ne fournit au client que son certificat au lieu d’envoyer la chaîne de certification complète comme il devrait le faire. Du coup, le client (Firefox ici) n’a aucun moyen de remonter la chaîne jusqu’à une racine qu’il connaît.
Si ça fonctionne pour certains et pas pour d’autres, c’est parce que Firefox garge en mémoire les certificats intermédiaires qu’il rencontre au fil du temps, et peut les utiliser pour reconstituer une chaîne complète lorsqu’un serveur ne fournit pas la sienne (j’ai expliqué ici pourquoi il ne fallait pas compter sur ce mécanisme).
Ici, la configuration de libervia.org doit être mise à jour pour fournir au moins le certificat intermédiaire de Let’s Encrypt (celui dont le Subject doit être C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1).
Avec Apache < 2.4.8, ça se fait avec la directive SSLCertificateChainFile ; avec Apache >= 2.4.8, ça se fait en ajoutant le certificat intermédiaire directement à la suite du certificat terminal, dans le fichier pointé par SSLCertificateFile.
(Mais je croyais que Let’s Encrypt devait automatiser ce genre de choses, justement pour éviter les erreurs de configuration de ce genre…)
C'est comique, quoi qu'on fasse, on se fait critiquer :
Ce n’était pas tant une critique qu’un amer constat des dégâts occasionnés par la politique des navigateurs et des autorités de certification.
Ici, cette politique conduit à rejetter une CA que tu considérais pourtant comme « plus digne de confiance que les autres », uniquement parce que l’autre (pas forcément plus fiable ou moins fiable) apporte le précieux sésame de la reconnaissance par les navigateurs.
D’où ma remarque : c’est bien la reconnaissance par les navigateurs qui est le principal atout des autorités de certification, et non pas la pseudo-sécurité qu’elles fournissent.
Pour rappel : utiliser CAcert ou Let’s Encrypt ne change rien au fait que Mallory peut obtenir auprès de n’importe quelle autre CA un certificat pour ton domaine, que les navigateurs accepteront sans broncher.
Nous venons de passer à let's encrypt, plus d'avertissements dans le navigateur
Eh oui, parce que c’est bien à ça et seulement à ça que sert une CA « reconnue » aujourd’hui : offrir autant de sécurité qu’un certificat auto-signé (c’est-à-dire, aucune sécurité contre un attaquant actif), mais avec la garantie qu’il n’y aura pas d’avertissements du navigateur.
Et ce besoin de complaire aux navigateurs vient à bout de toutes les belles phrases du genre « CAcert est encore plus digne de confiance que n’importe quel autre organisme de certification » ou « nous préférons soutenir un service communautaire et transparent comme CAcert plutôt que de passer par des compagnies offrant des certificats gratuits »…
Si l’on parle du vrai chiffrement de bout en bout (PGP ou S/MIME (dé)chiffré par l’utilisateur final), alors oui, complètement.
Pour le spam, je doute que ce soit un gros problème, ça m’étonnerait que les spammeurs s’amusent à chiffrer leurs messages quand leur but est d’en envoyer le plus possible au plus de monde possible (déjà qu’ils ne prennent pas la peine de respecter le protocole SMTP correctement — c’est ce qui rend possible le greylisting par exemple).
En revanche, le chiffrement de bout en bout pourrait permettre à un attaquant de contourner des protections anti-spear-phishing, où l’attaquant envoie à une cible bien précise un message chiffré contenant, par exemple, un fichier PDF vérolé (que l’antivirus sur le serveur de réception ne détectera évidemment pas).
Si le fournisseur fournit un client qui parle OpenPGP, ça peut très bien être du bout en bout.
C’est un cas différent.
Je faisais référence aux fournisseurs qui proposent de générer, stocker, utiliser la clef (prétendument) privée de l’utilisateur sur leurs serveurs.
C’est une idée très en vogue depuis les révélations de Snowden, elle est souvent présentée comme la solution ultime (forcément, ça utilise PGP, « le programme dont s’est servi Snowden, que même la NSA elle n’a rien pu faire »).
Exemple dans cette discussion sur la liste de discussion de GnuPG :
I think you'll find this has been solved for years. The solution is PGP/etc. between mail servers, and TLS/SSL to the user.
L’emphase est de moi : « PGP pour la communication entre serveurs ». Meh.
Pour information, Viktor Dukhovni, co-auteur du RFC 7672 sur DANE pour SMTP et développeur de l’implémentation correspondante dans Postfix, a publié quelques stats sur la liste dane-users@sys4.de. Les archives de la liste ne sont malheureusement pas accessibles aux non-inscrits, mais en gros :
9389 domaines signés avec des enregistrements TLSA pour SMTP
dont plus de la moitié étant gérés par l’hébergeur UD Media ;
dont un des plus gros FAI américains, Comcast ;
dont 28 domaines considérés comme suffisamment « gros » pour figurer dans les rapports de Google, parmi lesquels :
Et je pense que les équipe SMTP et HTTPS sont distinctes chez Google, la première peut vouloir changer des choses.
Traite-moi de pessimiste, mais j’en doute, considérant que dans le papier dont on parle :
DNSSEC n’est mentionné que pour dire qu’on ne peut pas trop compter dessus (“DNSSEC has not been widely deployed — ben forcément, tout le monde attend que vous le fassiez d’abord, hé patate ! — and so operators cannot rely on this protection” — au cas où quelqu’un aurait un doute, l’incise est de moi) ;
DANE n’est mentionné qu’en passant (“Without additional security add-ons (e.g., DANE), this attack remains a real threat.”) ;
les deux seules approches évoquées dans les solutions possibles sont un mécanisme de type HPKP (épinglage des clefs publiques pendant le dialogue SMTP, protégeant les connexions futures) ou… Certificate Transparency.
Je maintiens : il n’y a probablement rien à attendre de Google pour tout ce qui touche à DNSSEC et DANE, ce n’est simplement pas dans leur agenda.
Aucune chance. Google se moque éperdument de DANE.
Aucune zone dépendant de Google (google.com, gmail.com, youtube.com, etc.) n’est signée. Pour Google, DNSSEC (dont DANE dépend : un enregistrement TLSA ne sert à rien s’il n’est pas signé) n’existe pas. Raison avancée : il y a trop de RSA 1024-bits dans DNSSEC, et ce n’est pas assez fort à leur goût.
Google promeut à la place son propre Certificate Transparency (qui ne résoud aucun problème), qui s’oppose explicitement à la possibilité offerte par DANE d’utiliser des certificats qui ne soient pas émis par des CA reconnues. Le site de CT peut bien prétendre que DANE could also be used with CT, ce n’est vrai que si DANE est utilisé pour publier un certificat émis par une CA participant à CT (donc les mêmes CA que celles acceptées par les navigateurs). Les logs CT refusent d’enregistrer les certificats émis de façon indépendante.
Google n’hésite pas à faire preuve de mauvaise foi quand il s’agit de promouvoir Certificate Transparency par rapport à DANE, par exemple lorsqu’ils affirment que « DANE nécessite de modifier les serveurs » parce qu’il faut bien « servir les enregistrements DNS nécessaires » — faisant semblant d’oublier que ① n’importe quel service web a déjà besoin d’un serveur DNS pour distribuer son adresse, ② n’importe quel serveur DNS est déjà capable de servir des enregistrements TLSA, ③ Certificate Transparency de son côté nécessite rien de moins que de modifier le format X.509 (ajout d’une extension représentant le jeton CT), le protocole TLS (ajout d’une extension pour fournir le jeton CT), le protocole OCSP (idem), et les clients qui doivent supporter toutes ces extensions…
Bref, si tu veux du DANE, tu auras plus vite fait de le mettre en place toi-même que d’attendre que GMail le fasse. Je l’ai fait, ce n’est pas trivial mais ça ne demande pas non plus d’être ingénieur chez Google.
le support de PGP doit être fait coté serveur également malheureusement.
Non, parce que ça ne sert à rien.
Le but de PGP (ou S/MIME, ou du chiffrement de bout en bout de façon générale) est de protéger le corps du message contre tout le monde, y compris les fournisseurs, jusqu’au destinataire.
Si le message est (dé)chiffré via PGP sur les serveurs des fournisseurs, cela n’apporte rien de plus par rapport à TLS (qui protège déjà l’ensemble du message — en-têtes + corps — contre tout le monde sauf les fournisseurs).
PGP côté serveur ne peut servir qu’à attirer des utilisateurs naïfs en leur disant « nous on chiffre avec PGP, confiez-nous vos mails ».
[^] # Re: Et c'est joli au moins?
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 9.
La taille de la clef n’est pas tout. Oui, Firefox sait faire du AES-256, mais seulement en mode CBC, pas en mode GCM. Donc, même si ton serveur propose du AES256-GCM et du AES256-CBC, Firefox lui doit choisir entre AES128-GCM et AES256-CBC — et il n’y a rien d’anormal à privilégier le premier :
Et indépendamment des questions de modes d’opération, il y a d’autres raisons qui peuvent faire qu’un algorithme utilisant des clefs de 256-bits ne soit pas forcément plus sûr qu’un algorithme à clef de 128-bits. Dans le cas d’AES par exemple, il existe des attaques qui ciblent spécifiquement les versions 192/256-bits et qui sont inopérantes contre la version 128-bits. Bon, ce sont des attaques purement théoriques, mais ça illustre le fait qu’il vaut mieux réfléchir un peu avant de foncer bille en tête vers les clefs les plus grosses…
(Au passage, une clef RSA de 4096-bits pour un certificat valable deux ans, je trouve ça complètement disproportionné.)
[^] # Re: Pendant ce temps là
Posté par gouttegd . En réponse à la dépêche Parution de Firefox 43. Évalué à 6.
Forcément vu que certains ne laissent pas le choix…
Pas tous. Chez le mien, l’accès POP3/IMAP ne fonctionne inexplicablement pas depuis certains réseaux (celui d’OVH notamment) — le serveur coupe brutalement la connexion à peine celle-ci établie.
Et quand on demande des explications au support, on se voit répondre que l’utilisation de POP3/IMAP « n’est pas conforme aux CGUs et ne peut donc être garantie ».
J’ai déjà eu affaire à ces trois-là, et aucun ne m’a jamais posé de problèmes pour accéder aux messages ou en envoyer en passant par les protocoles standards indépendamment du webmail…
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 3.
Je pense que le problème réside dans le « plus ou moins ».
Il y a bien un magasin centralisé, system-wide et disponible pour toutes les applications sur Windows et Mac OS X, et sur ces systèmes Chrome en fait usage.
Mais sur les distributions GNU/Linux, comme tu dis c’est « plus ou moins centralisé ».
Debian a son paquet
ca-certificates(qui reprend essentiellement les certificats de NSS d’ailleurs, en en rajoutant éventuellement quelques autres comme celui de CAcert à une époque) et ses certificats dans/etc/ssl/certs, mais d’autres distributions ont leur propre système. Il n’existe pas d’emplacement standardisé qui serait valable sur n’importe quelle distribution.À noter en revanche le projet p11-kit qui va dans ce sens.
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 10.
Je pense qu’au moins une partie du problème pourrait être lié à ce qui est apparemment un bug connu de Chrome (section ”Issue 2: Out-of-date NSS and cross-signed roots”) :
Je pense que c’est ce qui explique la chaîne à six niveaux observé avec Chrome.
Le dernier certificat intermédiaire envoyé par LinuxFR.org (
CN=USERTrust RSA Certification Authority, serial13:EA:28:70:5B:F4:EC:ED:0C:36:63:09:80:61:43:36) est signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A.Il existe (au moins) deux certificats utilisant cette clef :
CN=AddTrust External CA Root, serial0x1, auto-signé;CN=AddTrust External CA Root, serial51:26:0A:93:1C:E2:7F:9C:C3:A5:5F:79:E0:72:AE:82, signé par la clef53:32:D1:B3:CF:7F:FA:E0:F1:A0:5D:85:4E:92:D2:9E:45:1D:B4:4F.Cette clef
53:32:D1.etc.est utilisée par (au moins) trois certificats :CN=UTN - DATACorp SGC, serial44:BE:0C:8B:50:00:21:B4:11:D3:2A:68:06:A9:AD:69, auto-signéCN=UTN - DATACorp SGC, serial46:EA:F0:96:05:4C:C5:E3:FA:65:EA:6E:9F:42:C6:64, signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A(celle des certificatsAddTrust External CA Rootci-dessus, vous suivez ?), révoqué le 14 décembreCN=UTN - DATACorp SGC, serial53:7B:76:56:4F:29:7F:14:DC:69:43:E9:22:AD:2C:79, lui aussi signé par la clefAD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1Aet lui aussi révoqué le 14 décembre.On est donc bien dans le cas « racines cross-signées » entre
AddTrust External CA RootetUTN - DATACorp SGC.Dans les versions récentes de NSS, seul le certificat
AddTrust External CA Rootauto-signé est présent dans le magasin des Builtin Object Tokens (les certificats codés « en dur » dans le navigateur). Cela ne laisse donc qu’une racine possible pour rattacher le dernier certificat intermédiaire envoyé par LinuxFR.org, et il n’y a pas de problème.Mais si le magasin des certificats cachés (les certificats que le navigateur accumule au gré de la navigation) vient à contenir à la fois la version cross-signée du certificat
AddTrust External CA Rootet l’une des deux versions cross-signées du certificatUTN - DATACorp SGC, le navigateur peut construire la chaîne de certification suivante :USERTrust RSA Certification Authority→AddTrust External CA Root(version cross-signée, en cache) →UTN - DATACorp SGC(version cross-signée, en cache) →AddTrust External CA Root(version auto-signée, dans le magasin en dur)On est donc bien, me semble-t-il, dans le cas du bug évoqué plus haut (ou un bug similaire), où le navigateur construit une chaine de certification à rallonge en utilisant des certificats cachés alors qu’une chaîne plus courte est possible.
Il reste que je ne comprends toujours pas comment/pourquoi la construction de la chaine de certification varierait en fonction du FAI utilisé pour se connecter…
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 2. Dernière modification le 21 décembre 2015 à 11:33.
Tu pourrais aussi exporter au format PEM les certificats de la chaîne incorrecte et les poster quelque part (ici ou sur un pastebin) ?
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 4.
Apparemment, le certificat
UTN - DATACorp SGC(numéro de série53:7b:76:56:4f:29:7f:14:dc:69:43:e9:22:ad:2c:79) a bel et bien été révoqué par Comodo le 14 décembre (probablement parce qu’il était signé avec un hash SHA-1, que la plupart des navigateurs ont prévu de ne plus accepter) :Du coup, ça expliquerait le code d’erreur
NET::ERR_CERT_REVOKED, qui concernerait alors non pas le certificat de linuxfr.org mais un des certificats parents.Mais ce que je ne comprends toujours pas, c’est pourquoi le chemin de certification passe par ce certificat dans un cas et pas dans l’autre…
Au cas où, tu peux vérifier que la chaîne envoyée par le serveur de linuxfr.org est bien la même avec les deux adresses ?
Même commande que celle suggérée par Xavier Claude ci-dessus, avec en plus l’option
-showcerts:[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 7.
Pas jusqu’à la racine. Le serveur est supposé fournir une chaîne incluant jusqu’au dernier certificat intermédiaire.
C’est ce que fait le serveur de LinuxFR.org, qui fournit les certificats suivants :
*.linuxfr.org(le certificat terminal, celui du serveur proprement dit)Gandi Standard SSL CA 2(le certificat de Gandi)USERTrust RSA Certification(certificat intermédiaire de Comodo).À partir de là, rattacher le dernier certificat de la chaîne fournie par le serveur à une racine présente dans le magasin est de la responsabilité du navigateur, qui va s’acquitter de cette tâche en fonction des racines qu’il a à sa disposition.
En réalité les
Subjectde l’ancien certificat intermédiaire de Comodo et celui de la nouvelle racine sont identiques (c’estC=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Rootdans les deux cas). Le nom AddTrust External Root (sans le « CA ») qui apparaît dans la liste des certificats de Chrome n’est qu’un nom d’affichage. (J’ai utilisé ce nom-là dans mon post ci-dessus pour pouvoir distinguer entre le certificat intermédiaire et la nouvelle racine.)À ma connaissance aucun navigateur n’intègre le certificat de Gandi directement.
[^] # Re: Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 2.
Ça par contre ce n’est pas normal — et je ne vois pas ce que le changement de racine pourrait avoir à faire avec ça…
# Changement de racine chez Comodo
Posté par gouttegd . En réponse au journal Paranoïa, certificat SSL et tracasseries.. Évalué à 10.
Ce qui se passe apparemment est qu’il y a eu un changement de racine.
Comodo (signataire de Gandi, lui-même signataire de LinuxFR.org) utilisait comme racine le certificat
UTN - DATACorp SGC, qui signait un certificat intermédiaireAddTrust External CA Root(lui-même signant un autre certificat intermédiaire de Comodo,USERTrust RSA Certification Authority, qui est le dernier certificat envoyé par le serveur de LinuxFR.org).Maintenant, la clef du premier certificat intermédiaire
AddTrust External CA Roota été ré-utilisée pour (auto)signer une nouvelle racine,AddTrust External Root.Comme
AddTrust External CA Root(ancien certificat intermédiaire) etAddTrust External Rootutilisent la même clef, il y a deux chaînes de certification possibles pour LinuxFR.org:celle remontant jusqu’à l’ancienne racine:
CN=*.linuxfr.org)CN=Gandi Standard SSL CA 2)CN=USERTrust RSA Certification Authority)CN=AddTrust External CA Root)CN=UTN - DATACorp SGC)celle remontant jusqu’à la nouvelle:
CN=*.linuxfr.org)CN=Gandi Standard SSL CA 2)CN=USERTrust RSA Certification Authority)CN=AddTrust External Root)Le choix d’une chaîne ou de l’autre dépend des racines présentes dans le magasin du navigateur. Dans ton cas, apparemment Chrome a intégré la nouvelle racine de Comodo et n’a donc plus besoin de remonter jusqu’à l’ancienne racine, contrairement à Firefox.
(Pour info, chez moi, Firefox 38.5 considère déjà le premier certificat intermédiaire de Comodo,
USERTrust RSA Certification Authority, comme une racine, donc la chaîne s’arrête à ce certificat.)[^] # Re: spam et signature
Posté par gouttegd . En réponse au journal Antispam, une solution. Évalué à 4.
C’est entre autres ce que je lui reproche. Le système PKIX est tout sauf un modèle à suivre, ce serait même plutôt l’exemple de ce qu’il ne faut pas faire. Dois-je expliquer encore une fois (j’ai l’impression de le faire au moins une fois par semaine sur LinuxFR) que les CA ne servent à rien ? Que payer 99 dollars par an pour un joli certificat « à validation étendue » n’empêchera pas un attaquant de présenter à sa victime un certificat signé par l’une quelconque des what mille autres autorités de certification auquel les navigateurs font confiance ?
Où ai-je dit que je n’avais pas d’anti-spam ?
J’ai dit que je ne voulais pas d’un anti-spam basé sur un principe du genre « seuls ceux que je connais, ou ceux qui ont été avalisés par une entité à laquelle je fais confiance, peuvent m’envoyer des mails — les autres vont se faire voir ».
Dans le même ordre d’idée, je peste également contre les anti-spams du genre « l’adresse IP de l’émetteur est dans un bloc chinois ou russe, je jette » (j’ai déjà eu le cas où un chercheur moscovite a eu du mal à me contacter à cause de ça) ou « l’adresse est dans une blacklist établie sur des critères que je connais à peine, je jette » (là c’est moi qui a eu du mal à contacter quelqu’un, parce que son opérateur rejettait tous les mails provenant du /24 où avait le malheur de se trouver mon serveur).
Mais je n’ai rien contre des techniques anti-spam qui laissent moins de place à l’arbitraire. Je n’ai aucun scrupule à rejetter des mails qui ne passent pas la validation SPF par exemple (si l’enregistrement SPF du domaine émetteur m’y autorise, évidemment), ou à fermer la porte à des clients qui ne respectent pas le protocole SMTP.
Nul n’a besoin d’autorisation pour m’envoyer un mail. OK, mais ça ne veut pas forcément dire que je vais accepter tout ce qu’on m’envoie.
[^] # Re: spam et signature
Posté par gouttegd . En réponse au journal Antispam, une solution. Évalué à 8.
Et moi je te dis simplement ce que j’en pense. C’est pour ça qu’on propose des idées, en général — et non uniquement pour s’entendre dire que c’est une idée géniale…
Donc tu es déjà convaincu qu’il y a du potentiel, et que c’est juste nous qui sommes trop bornés pour le chercher. Bon, ben pas la peine de discuter dans ce cas.
Ce n’est pas du tout évident pour moi, tu peux expliquer ?
Dans le cas qui nous intéresse (le mail), je ne veux ni d’une régulation par un ou des états, ni d’une régulation par des sociétés privés.
Je veux que n’importe qui puisse m’envoyer un mail, d’où qu’il soit, sans avoir à solliciter une quelconque autorisation ou à montrer patte blanche devant une quelconque autorité, qu’elle soit étatique ou privée.
Et si le spam est le prix à payer pour ça, je l’accepte.
[^] # Re: spam et signature
Posté par gouttegd . En réponse au journal Antispam, une solution. Évalué à 4.
Pêle-mêle :
Quel état ? La France ? Quid du reste du monde ? Soit on accepte que les mails venant de serveur avalisés par cet hypothétique service, et alors on se coupe du reste du monde (je ne doute pas que ça plairait à certains), soit on n’exige pas de signatures pour les mails venant de l’étranger, et le « service de l’état » n’est qu’une coquille vide totalement inutile. Ou alors tu envisageais que ce service pourrait aussi signer les clefs d’opérateurs non-français ? Mais pourquoi lesdits opérateurs se plieraient-ils à ça ?
Déjà que l’État n’a même d’autorité de certification qui lui soit propre (les certificats des sites gouvernementaux français sont signés par des CA privées, souvent américaines), je doute fort de la volonté de mettre en place un tel service.
Non seulement il n’y aurait qu’une seule entité qui déciderait de qui est ou non un spammeur, mais en plus ce serait une entité gouvernementale ? Non merci. Confier un tel pouvoir à une seule entité ne peut que conduire à des abus.
Et comme pour les certificats SSL à l’heure actuelle, ça ne servirait à rien du tout.
S’il y a plusieurs entités, il y en aura forcément qui signeront des spammeurs que d’autres entités auront refusé de signer (tu le dis toi-même : des entités plus ou moins strictes). Qui décidera alors de la liste des entités auxquelles on fait confiance ? Les utilisateurs ? L’exemple des certificats X.509 montre clairement que c’est totalement irréaliste (qui a déjà fait le ménage dans la liste des CA racines de son navigateur pour ne garder que celles en lesquelles il a confiance ?). Dans les faits, ce sont les éditeurs de systèmes/logiciels (Microsoft, Apple, Mozilla, etc.) qui décident — et le résultat, c’est que tout le monde fait par défaut confiance à plusieurs centaines d’autorités à l’intégrité ou à la fiabilité douteuse (certaines ont déjà prouvé qu’elles n’étaient pas dignes de confiance).
# Détecter l’inpainting
Posté par gouttegd . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 10.
Je suis bluffé par le filtre d’inpainting. Bluffé, et un peu inquiet aussi.
J’ai eu beau essayer tous les « trucs » que j’utilise habituellement pour vérifier si une image a été trafiquée (comme, pousser le contraste et/ou la luminosité à fond, jouer avec les courbes ou les gradient maps — cela fait presque toujours apparaître des « anomalies » qui révèlent que Photoshop ou Gimp sont passés par là…), je n’ai pas réussi à détecter quoi que ce soit d’anormal sur l’image de la figure 3.1.
Du coup, je me demande : est-ce que vous vous intéressez aussi à des méthodes de détection de ce genre de modifications ?
La possibilité de modifier une photo sans que rien ne vienne trahir la manipulation m’effraie un peu…
[^] # Re: let's encrypt !
Posté par gouttegd . En réponse à la dépêche Libervia/Salut à Toi 0.6.0 : nouvelle vague. Évalué à 3.
Je ne suis pas familier de Twisted, mais ça ressemble plus à un problème de code qu’à une simple question d’arguments.
Le code qui charge le certificat est la ligne suivante (fichier
src/server/server.py) :et je n’ai pas l’impression, à voir la documentation de Twisted, que cette fonction
loadPEMprenne en compte les éventuels certificats intermédiaires contenu dans le fichier.Une possibilité semble être de passer par un
ContextFactorypersonnalisé :et de l’utiliser à la place de
cert.options()dans l’appel àlistenSSL:Du moins, c’est le principe. Je n’ai pas d’installation fonctionnelle de SàT/Libervia pour tester, sinon j’aurais envoyé un patch en bonne et due forme.
[^] # Re: let's encrypt !
Posté par gouttegd . En réponse à la dépêche Libervia/Salut à Toi 0.6.0 : nouvelle vague. Évalué à 3.
Non. Lis le commentaire que je viens de poster un peu plus haut, la configuration de libervia.org est incorrecte.
[^] # Re: let's encrypt !
Posté par gouttegd . En réponse à la dépêche Libervia/Salut à Toi 0.6.0 : nouvelle vague. Évalué à 5.
Ce n’est pas un problème de version de Firefox (ou de n’importe quel navigateur).
Le problème est que le serveur libervia.org ne fournit au client que son certificat au lieu d’envoyer la chaîne de certification complète comme il devrait le faire. Du coup, le client (Firefox ici) n’a aucun moyen de remonter la chaîne jusqu’à une racine qu’il connaît.
Si ça fonctionne pour certains et pas pour d’autres, c’est parce que Firefox garge en mémoire les certificats intermédiaires qu’il rencontre au fil du temps, et peut les utiliser pour reconstituer une chaîne complète lorsqu’un serveur ne fournit pas la sienne (j’ai expliqué ici pourquoi il ne fallait pas compter sur ce mécanisme).
Ici, la configuration de libervia.org doit être mise à jour pour fournir au moins le certificat intermédiaire de Let’s Encrypt (celui dont le Subject doit être
C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1).Avec Apache < 2.4.8, ça se fait avec la directive
SSLCertificateChainFile; avec Apache >= 2.4.8, ça se fait en ajoutant le certificat intermédiaire directement à la suite du certificat terminal, dans le fichier pointé parSSLCertificateFile.(Mais je croyais que Let’s Encrypt devait automatiser ce genre de choses, justement pour éviter les erreurs de configuration de ce genre…)
[^] # Re: let's encrypt !
Posté par gouttegd . En réponse à la dépêche Libervia/Salut à Toi 0.6.0 : nouvelle vague. Évalué à 4.
Ce n’était pas tant une critique qu’un amer constat des dégâts occasionnés par la politique des navigateurs et des autorités de certification.
Ici, cette politique conduit à rejetter une CA que tu considérais pourtant comme « plus digne de confiance que les autres », uniquement parce que l’autre (pas forcément plus fiable ou moins fiable) apporte le précieux sésame de la reconnaissance par les navigateurs.
D’où ma remarque : c’est bien la reconnaissance par les navigateurs qui est le principal atout des autorités de certification, et non pas la pseudo-sécurité qu’elles fournissent.
Pour rappel : utiliser CAcert ou Let’s Encrypt ne change rien au fait que Mallory peut obtenir auprès de n’importe quelle autre CA un certificat pour ton domaine, que les navigateurs accepteront sans broncher.
[^] # Re: let's encrypt !
Posté par gouttegd . En réponse à la dépêche Libervia/Salut à Toi 0.6.0 : nouvelle vague. Évalué à 2.
Eh oui, parce que c’est bien à ça et seulement à ça que sert une CA « reconnue » aujourd’hui : offrir autant de sécurité qu’un certificat auto-signé (c’est-à-dire, aucune sécurité contre un attaquant actif), mais avec la garantie qu’il n’y aura pas d’avertissements du navigateur.
Et ce besoin de complaire aux navigateurs vient à bout de toutes les belles phrases du genre « CAcert est encore plus digne de confiance que n’importe quel autre organisme de certification » ou « nous préférons soutenir un service communautaire et transparent comme CAcert plutôt que de passer par des compagnies offrant des certificats gratuits »…
[^] # Re: PGP
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 3.
Si l’on parle du vrai chiffrement de bout en bout (PGP ou S/MIME (dé)chiffré par l’utilisateur final), alors oui, complètement.
Pour le spam, je doute que ce soit un gros problème, ça m’étonnerait que les spammeurs s’amusent à chiffrer leurs messages quand leur but est d’en envoyer le plus possible au plus de monde possible (déjà qu’ils ne prennent pas la peine de respecter le protocole SMTP correctement — c’est ce qui rend possible le greylisting par exemple).
En revanche, le chiffrement de bout en bout pourrait permettre à un attaquant de contourner des protections anti-spear-phishing, où l’attaquant envoie à une cible bien précise un message chiffré contenant, par exemple, un fichier PDF vérolé (que l’antivirus sur le serveur de réception ne détectera évidemment pas).
[^] # Re: PGP
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 3.
C’est un cas différent.
Je faisais référence aux fournisseurs qui proposent de générer, stocker, utiliser la clef (prétendument) privée de l’utilisateur sur leurs serveurs.
C’est une idée très en vogue depuis les révélations de Snowden, elle est souvent présentée comme la solution ultime (forcément, ça utilise PGP, « le programme dont s’est servi Snowden, que même la NSA elle n’a rien pu faire »).
Exemple dans cette discussion sur la liste de discussion de GnuPG :
L’emphase est de moi : « PGP pour la communication entre serveurs ». Meh.
[^] # Re: DANE
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 4.
Pour information, Viktor Dukhovni, co-auteur du RFC 7672 sur DANE pour SMTP et développeur de l’implémentation correspondante dans Postfix, a publié quelques stats sur la liste dane-users@sys4.de. Les archives de la liste ne sont malheureusement pas accessibles aux non-inscrits, mais en gros :
[^] # Re: worm
Posté par gouttegd . En réponse à la dépêche OpenBSD 5.8. Évalué à 6.
Dans Debian, il est dans le paquet bsdgames.
[^] # Re: DANE
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 5.
Traite-moi de pessimiste, mais j’en doute, considérant que dans le papier dont on parle :
DNSSEC n’est mentionné que pour dire qu’on ne peut pas trop compter dessus (“DNSSEC has not been widely deployed — ben forcément, tout le monde attend que vous le fassiez d’abord, hé patate ! — and so operators cannot rely on this protection” — au cas où quelqu’un aurait un doute, l’incise est de moi) ;
DANE n’est mentionné qu’en passant (“Without additional security add-ons (e.g., DANE), this attack remains a real threat.”) ;
les deux seules approches évoquées dans les solutions possibles sont un mécanisme de type HPKP (épinglage des clefs publiques pendant le dialogue SMTP, protégeant les connexions futures) ou… Certificate Transparency.
Je maintiens : il n’y a probablement rien à attendre de Google pour tout ce qui touche à DNSSEC et DANE, ce n’est simplement pas dans leur agenda.
[^] # Re: DANE
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 4.
Aucune chance. Google se moque éperdument de DANE.
Aucune zone dépendant de Google (google.com, gmail.com, youtube.com, etc.) n’est signée. Pour Google, DNSSEC (dont DANE dépend : un enregistrement TLSA ne sert à rien s’il n’est pas signé) n’existe pas. Raison avancée : il y a trop de RSA 1024-bits dans DNSSEC, et ce n’est pas assez fort à leur goût.
Google promeut à la place son propre Certificate Transparency (qui ne résoud aucun problème), qui s’oppose explicitement à la possibilité offerte par DANE d’utiliser des certificats qui ne soient pas émis par des CA reconnues. Le site de CT peut bien prétendre que DANE could also be used with CT, ce n’est vrai que si DANE est utilisé pour publier un certificat émis par une CA participant à CT (donc les mêmes CA que celles acceptées par les navigateurs). Les logs CT refusent d’enregistrer les certificats émis de façon indépendante.
Google n’hésite pas à faire preuve de mauvaise foi quand il s’agit de promouvoir Certificate Transparency par rapport à DANE, par exemple lorsqu’ils affirment que « DANE nécessite de modifier les serveurs » parce qu’il faut bien « servir les enregistrements DNS nécessaires » — faisant semblant d’oublier que ① n’importe quel service web a déjà besoin d’un serveur DNS pour distribuer son adresse, ② n’importe quel serveur DNS est déjà capable de servir des enregistrements TLSA, ③ Certificate Transparency de son côté nécessite rien de moins que de modifier le format X.509 (ajout d’une extension représentant le jeton CT), le protocole TLS (ajout d’une extension pour fournir le jeton CT), le protocole OCSP (idem), et les clients qui doivent supporter toutes ces extensions…
Bref, si tu veux du DANE, tu auras plus vite fait de le mettre en place toi-même que d’attendre que GMail le fasse. Je l’ai fait, ce n’est pas trivial mais ça ne demande pas non plus d’être ingénieur chez Google.
[^] # Re: PGP
Posté par gouttegd . En réponse au journal Gmail cherche à pousser les autres fournisseurs de courriel à envoyer/recevoir de manière chiffrée. Évalué à 10.
Non, parce que ça ne sert à rien.
Le but de PGP (ou S/MIME, ou du chiffrement de bout en bout de façon générale) est de protéger le corps du message contre tout le monde, y compris les fournisseurs, jusqu’au destinataire.
Si le message est (dé)chiffré via PGP sur les serveurs des fournisseurs, cela n’apporte rien de plus par rapport à TLS (qui protège déjà l’ensemble du message — en-têtes + corps — contre tout le monde sauf les fournisseurs).
PGP côté serveur ne peut servir qu’à attirer des utilisateurs naïfs en leur disant « nous on chiffre avec PGP, confiez-nous vos mails ».