D’une part, tout nouveau protocole (ou modification d’un protocole pré-existant comme TLS/X.509) nécessitant de modifier le code des serveurs et des clients a très peu de chance d’être mis en place, et s’il l’est ce ne sera pas avant plusieurs années. Il y a une inertie énorme, il suffit de voir le temps qu’il a fallu pour déployer TLS 1.2 — on trouvait encore il y a quelques mois beaucoup de serveurs ne supportant rien de mieux que SSL 3.0, obsolète depuis plus de quinze ans (il a fallu l’attaque POODLE pour donner un coup de pied dans la fourmillière).
D’autre part, des alternatives aux « bêtes certificats actuels », ou des méthodes pour combler leurs déficiences, il y en a déjà plusieurs. Au moins deux sont particulièrement dignes d’intérêt :
les certificats OpenPGP (RFC 6091), beaucoup plus flexibles que les certificats X.509 (ils peuvent notamment porter un nombre arbitraire de signatures, et la confiance en chaque signature n’est pas binaire) ;
l’épinglage des certificats (ou des clefs brutes, RFC 7250) dans le DNS (DANE, RFC 6698).
Ni l’un ni l’autre ne sont largement supportés. À ma connaissance, seule la bibliothèque GnuTLS implémente le RFC 6091, et aucun navigateur ne supporte nativement DANE (un plugin existe pour ceux qui le veulent).
Toute proposition de solution aura besoin de l’appui d’un poids lourd du web pour s’imposer, indépendamment de ses mérites. C‘est comme ça que seul Certificate Transparency, qui est activement poussé par Google, a une chance d’aller loin (et c’est malheureux, car c’est une fausse solution qui ne résoud aucun des problèmes de X.509).
[^] # Re: Automatisme ?!?
Posté par gouttegd . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 3.
Non mais là tu rêves éveillé...
D’une part, tout nouveau protocole (ou modification d’un protocole pré-existant comme TLS/X.509) nécessitant de modifier le code des serveurs et des clients a très peu de chance d’être mis en place, et s’il l’est ce ne sera pas avant plusieurs années. Il y a une inertie énorme, il suffit de voir le temps qu’il a fallu pour déployer TLS 1.2 — on trouvait encore il y a quelques mois beaucoup de serveurs ne supportant rien de mieux que SSL 3.0, obsolète depuis plus de quinze ans (il a fallu l’attaque POODLE pour donner un coup de pied dans la fourmillière).
D’autre part, des alternatives aux « bêtes certificats actuels », ou des méthodes pour combler leurs déficiences, il y en a déjà plusieurs. Au moins deux sont particulièrement dignes d’intérêt :
les certificats OpenPGP (RFC 6091), beaucoup plus flexibles que les certificats X.509 (ils peuvent notamment porter un nombre arbitraire de signatures, et la confiance en chaque signature n’est pas binaire) ;
l’épinglage des certificats (ou des clefs brutes, RFC 7250) dans le DNS (DANE, RFC 6698).
Ni l’un ni l’autre ne sont largement supportés. À ma connaissance, seule la bibliothèque GnuTLS implémente le RFC 6091, et aucun navigateur ne supporte nativement DANE (un plugin existe pour ceux qui le veulent).
Toute proposition de solution aura besoin de l’appui d’un poids lourd du web pour s’imposer, indépendamment de ses mérites. C‘est comme ça que seul Certificate Transparency, qui est activement poussé par Google, a une chance d’aller loin (et c’est malheureux, car c’est une fausse solution qui ne résoud aucun des problèmes de X.509).