Et si on allait chercher trop loin alors qu'on a déjà des solutions ?
Mon point de vue est qu'on devrait faire de HTTP ce qu'on a fait avec FTP, en l'adaptant aux besoins.
Si l'objectif est de protéger la vie privée, d'éviter les interceptions en clair et de modifier le contenu des paquets, alors je ne pense pas qu'on est besoin de la chaîne de confiance, toute relative, d'HTTPS.
On garde HTTP, on peut réfléchir aux problèmes d'HTTPS mais à côté, on peut implémenter SHTTP.
SHTTP, ça serait des tunnels SSH pour sécuriser HTTP. 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.
Les avantages, c'est qu'SSH est déjà bien connu, et qu'on sait faire du PFP avec.
Avec l'exemple d'SFTP, on peut avoir une idée des points négatifs qu'on aurait avec SHTTP.
Du point de vue de l'administration système, je trouve ça plus gérable. (On génére une paire de clefs pour un domaine donné, ça fait une ou deux lignes dans un fichier de conf, on récupére l'empreinte, qu'on publie dans le dns pour le domaine donné.)
Ca permet une transition en douceur, même si il reste des questions techniques à résoudre.
- Est-ce qu'on garde le port 80, par exemple.
Ca permet de ne pas confondre HTTP dans HTTPS et de garder les certificats pour ce qu'ils sont.
Généraliser HTTPS, c'est, peut-être, faire croire qu'il n'y plus de risques et l'utilisateur si il voit un cadenas, pensera qu'il est à l'abri.
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 qu'on verrait apparaître des liens en shttp:// sur les pages web et les moteurs de recherche.
L'enregistrement des empreintes dans le naviguateur pour la comparer les empreintes avec celle du DNS. Ainsi, soit le site aurait compromis si l'empreinte change, soit il aurait changé de clefs.
Les points négatifs, j'ai du mal à les voir.
La charge plus importante pour encrypter les données, mais que ça soit du SHTTP ou HTTPS, ça posera les mêmes problèmes, je pense.
# shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -2.
Et si on allait chercher trop loin alors qu'on a déjà des solutions ?
Mon point de vue est qu'on devrait faire de HTTP ce qu'on a fait avec FTP, en l'adaptant aux besoins.
Si l'objectif est de protéger la vie privée, d'éviter les interceptions en clair et de modifier le contenu des paquets, alors je ne pense pas qu'on est besoin de la chaîne de confiance, toute relative, d'HTTPS.
On garde HTTP, on peut réfléchir aux problèmes d'HTTPS mais à côté, on peut implémenter SHTTP.
SHTTP, ça serait des tunnels SSH pour sécuriser HTTP. 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.
Les avantages, c'est qu'SSH est déjà bien connu, et qu'on sait faire du PFP avec.
Avec l'exemple d'SFTP, on peut avoir une idée des points négatifs qu'on aurait avec SHTTP.
Du point de vue de l'administration système, je trouve ça plus gérable. (On génére une paire de clefs pour un domaine donné, ça fait une ou deux lignes dans un fichier de conf, on récupére l'empreinte, qu'on publie dans le dns pour le domaine donné.)
Ca permet une transition en douceur, même si il reste des questions techniques à résoudre.
- Est-ce qu'on garde le port 80, par exemple.
Ca permet de ne pas confondre HTTP dans HTTPS et de garder les certificats pour ce qu'ils sont.
Généraliser HTTPS, c'est, peut-être, faire croire qu'il n'y plus de risques et l'utilisateur si il voit un cadenas, pensera qu'il est à l'abri.
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 qu'on verrait apparaître des liens en shttp:// sur les pages web et les moteurs de recherche.
L'enregistrement des empreintes dans le naviguateur pour la comparer les empreintes avec celle du DNS. Ainsi, soit le site aurait compromis si l'empreinte change, soit il aurait changé de clefs.
Les points négatifs, j'ai du mal à les voir.
La charge plus importante pour encrypter les données, mais que ça soit du SHTTP ou HTTPS, ça posera les mêmes problèmes, je pense.