Et si on allait chercher trop loin alors qu'on a déjà des solutions ?
C’est exactement ce que je me suis dit en lisant ta proposition...
Un système de clé privée/publique par domaine, avec son empreinte qu'on pourrait publier dans les enregistrements DNS, et le tout avec du Perfect Forward Privacy.
On peut faire tout ça sans avoir à créer un nouveau protocole, tout est déjà en place. Mince, je fais déjà tout ça, moi tout seul dans mon coin, qu’on ne vienne pas me dire que ce n’est pas possible.
Le problème n’est pas de pouvoir faire ça, mais de faire en sorte que les clients s’en servent. Et là, je te souhaite bon courage pour obtenir des éditeurs de navigateurs qu’ils prennent en charge ton shttp.
Je m'imagine donc une prise en charge des naviguateurs et des serveurs web en douceur, puisse qu'on ne touche pas à HTTP, ni à HTTPS
Et la marmotte... DANE non plus ne touche à rien de ce qui existe déjà, il peut complètement coexister avec le modèle actuel, et regarde les réticences qu’il rencontre.
Les points négatifs, j'ai du mal à les voir.
Premier point : si les empreintes sont publiées dans le DNS, il faut pouvoir se fier aux données du DNS. Bonne nouvelle, il suffit de les signer, et DNSSEC et là pour ça. Mauvaise nouvelle : les acteurs du web mettent un point d’honneur à faire comme si DNSSEC n’existait pas.
(En fait, ils se moquent tellement de DNSSEC et du fait que le DNS seul n’est pas fiable que lors de l’annonce de la faille Kaminsky — qui trivialise l’empoisonnement de cache —, beaucoup de gens ont réagi en disant « bof, pas grave, de toute façon on a SSL par-derrière pour "garantir" (sic) qu’on se connecte bien au bon serveur, si le DNS nous envoie ailleurs la couche SSL nous avertira ».)
Deuxième point : c’est le même point négatif que toutes les autres alternatives envisagées depuis des années : tant que tu ne mettras pas Google, Mozilla, Microsoft ou Apple derrière toi, ça ne sera jamais implémenté que par quelques geeks dans leur coin.
[^] # Re: shttp
Posté par gouttegd . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 6.
C’est exactement ce que je me suis dit en lisant ta proposition...
On peut faire tout ça sans avoir à créer un nouveau protocole, tout est déjà en place. Mince, je fais déjà tout ça, moi tout seul dans mon coin, qu’on ne vienne pas me dire que ce n’est pas possible.
Le problème n’est pas de pouvoir faire ça, mais de faire en sorte que les clients s’en servent. Et là, je te souhaite bon courage pour obtenir des éditeurs de navigateurs qu’ils prennent en charge ton shttp.
Et la marmotte... DANE non plus ne touche à rien de ce qui existe déjà, il peut complètement coexister avec le modèle actuel, et regarde les réticences qu’il rencontre.
Premier point : si les empreintes sont publiées dans le DNS, il faut pouvoir se fier aux données du DNS. Bonne nouvelle, il suffit de les signer, et DNSSEC et là pour ça. Mauvaise nouvelle : les acteurs du web mettent un point d’honneur à faire comme si DNSSEC n’existait pas.
(En fait, ils se moquent tellement de DNSSEC et du fait que le DNS seul n’est pas fiable que lors de l’annonce de la faille Kaminsky — qui trivialise l’empoisonnement de cache —, beaucoup de gens ont réagi en disant « bof, pas grave, de toute façon on a SSL par-derrière pour "garantir" (sic) qu’on se connecte bien au bon serveur, si le DNS nous envoie ailleurs la couche SSL nous avertira ».)
Deuxième point : c’est le même point négatif que toutes les autres alternatives envisagées depuis des années : tant que tu ne mettras pas Google, Mozilla, Microsoft ou Apple derrière toi, ça ne sera jamais implémenté que par quelques geeks dans leur coin.