Il y a une comparaison proposée par les auteurs de Certificate Transparency eux-mêmes. À prendre pour ce que ça vaut.
Personnellement, je note que contrairement à ce qu’ils prétendent, la cohabitation de DANE et de Certificate Transparency n’est pas sans problème.
Some consider DANE to be an alternative to CT, which we disagree with and document here. But DANE could also be used with CT, which seems much more reasonable.
Seuls les profils PKIX-TA et PKIX-EE de DANE (où le certificat validé par DANE doit en plus être validé par le système PKIX) sont utilisables conjointement avec Certificate Transparency. Les profils DANE-TA et DANE-EE (où DANE remplace complètement le système PKIX, et permet notamment l’utilisation de certificats auto-signés ou signés par une AC inconnue des navigateurs) ne sont pas admis.
En effet, avec CT un certificat DOIT avoir un « SCT » (sorte de jeton, émis par un « log » CT, qui prouve que le certificat a bien été ajouté au log) pour que le client l’accepte. Or un log ne doit accepter un nouveau certificat (et donc lui donner le SCT qui lui permettra de montrer patte blanche) que si celui-ci est émis par une AC de confiance. La recommandation ne dit pas comment chaque log choisit les « AC de confiance », mais en pratique (les auteurs du RFC le suggèrent), ce seraient les mêmes que celles reconnues par les navigateurs.
Exit donc les CA peu connues et les certificats auto-signés, même s’ils sont publiés dans le DNS, et un des principaux intérêts de DANE vole en éclat...
Les auteurs justifient ça par le besoin de limiter le risque de spam : « This effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found. » Je ne suis de comprendre de quoi ils parlent (je suppose qu’ils craignent que les logs ne soient surchargés de requêtes si tous ceux qui ont un certificat auto-signé et/ou publié dans le DNS veulent l’ajouter aux logs), mais ça me paraît fallacieux.
Une façon de résoudre ça serait de considérer que Certificate Transparency fait en réalité partie du système PKIX (ce qui est à mon sens complètement vrai si les logs n’acceptent rien d’autres que des certificats venant des AC de confiance publiquement reconnues). Dans ce cas, en présence d’un enregistrement TLSA avec un profil d’utilisation réglé sur DANE-TA ou DANE-EE, le navigateur devrait être autorisé à accepter le certificat même en absence de jeton SCT (puisque ces profils servent précisément à bypasser le système PKIX).
Je note par ailleurs un tout petit peu de mauvaise foi dans l’élément « Unmodified Servers » de leur comparaison. D’après eux, un avantage de Certificate Transparency sur DANE est que le premier ne nécessite pas de modifications côté serveur. Sauf que :
– CT peut s’utiliser sans modification côté serveur, seulement dans un mode d’opération, celui où le SCT est directement intégré au certificat ; s’il ne l’est pas, le serveur doit être capable de transmettre lui-même le SCT au client. Le premier mode semble être le favori des auteurs, mais il requière la coopération des CA (qui doivent envoyer le certificat au log avant de le signer).
– Dire que DANE requière des modifications côté serveur parce qu’il faut « servir des enregistrements DNS », c’est du foutage de gueule. N’importe quel site a déjà besoin pour être joignable qu’un serveur DNS serve des enregistrements pour lui...
– Les serveurs DNS doivent supporter DNSSEC. Oui, et ça tombe bien la plupart des serveurs DNS le supportent.
– Les enregistrements TLSA doivent être modifiés chaque fois qu’un certificat est changé. Oui, et chaque nouveau certificat doit être ajouté à un log Certificate Transparency.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 4.
Il y a une comparaison proposée par les auteurs de Certificate Transparency eux-mêmes. À prendre pour ce que ça vaut.
Personnellement, je note que contrairement à ce qu’ils prétendent, la cohabitation de DANE et de Certificate Transparency n’est pas sans problème.
Seuls les profils PKIX-TA et PKIX-EE de DANE (où le certificat validé par DANE doit en plus être validé par le système PKIX) sont utilisables conjointement avec Certificate Transparency. Les profils DANE-TA et DANE-EE (où DANE remplace complètement le système PKIX, et permet notamment l’utilisation de certificats auto-signés ou signés par une AC inconnue des navigateurs) ne sont pas admis.
En effet, avec CT un certificat DOIT avoir un « SCT » (sorte de jeton, émis par un « log » CT, qui prouve que le certificat a bien été ajouté au log) pour que le client l’accepte. Or un log ne doit accepter un nouveau certificat (et donc lui donner le SCT qui lui permettra de montrer patte blanche) que si celui-ci est émis par une AC de confiance. La recommandation ne dit pas comment chaque log choisit les « AC de confiance », mais en pratique (les auteurs du RFC le suggèrent), ce seraient les mêmes que celles reconnues par les navigateurs.
Exit donc les CA peu connues et les certificats auto-signés, même s’ils sont publiés dans le DNS, et un des principaux intérêts de DANE vole en éclat...
Les auteurs justifient ça par le besoin de limiter le risque de spam : « This effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found. » Je ne suis de comprendre de quoi ils parlent (je suppose qu’ils craignent que les logs ne soient surchargés de requêtes si tous ceux qui ont un certificat auto-signé et/ou publié dans le DNS veulent l’ajouter aux logs), mais ça me paraît fallacieux.
Une façon de résoudre ça serait de considérer que Certificate Transparency fait en réalité partie du système PKIX (ce qui est à mon sens complètement vrai si les logs n’acceptent rien d’autres que des certificats venant des AC de confiance publiquement reconnues). Dans ce cas, en présence d’un enregistrement TLSA avec un profil d’utilisation réglé sur DANE-TA ou DANE-EE, le navigateur devrait être autorisé à accepter le certificat même en absence de jeton SCT (puisque ces profils servent précisément à bypasser le système PKIX).
Je note par ailleurs un tout petit peu de mauvaise foi dans l’élément « Unmodified Servers » de leur comparaison. D’après eux, un avantage de Certificate Transparency sur DANE est que le premier ne nécessite pas de modifications côté serveur. Sauf que :
– CT peut s’utiliser sans modification côté serveur, seulement dans un mode d’opération, celui où le SCT est directement intégré au certificat ; s’il ne l’est pas, le serveur doit être capable de transmettre lui-même le SCT au client. Le premier mode semble être le favori des auteurs, mais il requière la coopération des CA (qui doivent envoyer le certificat au log avant de le signer).
– Dire que DANE requière des modifications côté serveur parce qu’il faut « servir des enregistrements DNS », c’est du foutage de gueule. N’importe quel site a déjà besoin pour être joignable qu’un serveur DNS serve des enregistrements pour lui...
– Les serveurs DNS doivent supporter DNSSEC. Oui, et ça tombe bien la plupart des serveurs DNS le supportent.
– Les enregistrements TLSA doivent être modifiés chaque fois qu’un certificat est changé. Oui, et chaque nouveau certificat doit être ajouté à un log Certificate Transparency.