J'ai trouvé un article sur dnscurve.org qui résume les problématiques NXT vs NSEC vs NSEC3, par contre, il date un peu donc je sais pas si c'est toujours d'actualité.
Beaucoup pour penser que HTTPS n'est pas la solution, personne pour proposer une meilleure (en pratique, pas la théorie branlette intellectuelle) solution…
J'aime bien la théorie branlette intellectuelle, et alors? Y a ceux qui ont les idées, et ceux qui les appliquent (à leur sauce si ils veulent).
Ton principe général résout un problème qui n'existe pas sans résoudre le problème que tu soulèves (oui, je me répète).
Je t'ai relu et en fait, je ne comprends pas ce que tu veux dire, ni quel problème je soulève.
Je pense avoir assez explicité mon idée donc je ne vais pas me répéter.
Je suis plus attaché au principe général, qu'au principe technique que je propose:
Un système de clé privée/publique (par domaine/enregistrement dns) avec le support de PFP et l'enregistrement de l'empreinte dans le dns.
Et si il peut être adapter à SMTP ou d'autres, c'est encore mieux.
Le principe de clé privée/publique, il est commun à TLS, SSH. Alors, peu importe l'aspect technique.
Le sujet, c'est Mozilla qui pousse HTTP vers la sortie, mais je ne pense pas que généraliser HTTPS soit la solution, il y a trop de contraintes à gérer les certificats alors que une bonne paire de clefs avec un support PFP peut faire le travail.
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.
Au temps pour moi, j'avais zappé la discussion sur DANE et surtout sa description. C'est très intéressant d'ailleurs.
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.
Pas mieux, j'ai pas encore essayé DNSSEC, uniquement à cause de l'énumération des enregistrements DNSSEC de la zone.
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.
On est d'accord. Je vais divergé un peu mais mon opinion c'est que Mozilla ne défend plus les utilisateurs.
Premier exemple, Firefox 31.6.0 sous Windows (à vérifier pour GNU/Linux, *BSD), ne permet plus de désactiver javascript par l'interface utilisateur, il faut passer pour about:config.
Les requêtes safebrowsing semblent interroger les serveurs de Google, donc les sites qu'on visite, les fichiers qu'on télécharge, peuvent être connus de Google (Je serais moins réfractaire si c'était les serveurs de Mozilla).
Les requêtes Jquery (j'entends par là, tout ce qui va sur googleapis.com) qu'on retrouve sur certains sites et qui intérrogent les serveurs de Google encore, je comprends pas pourquoi on fait des requêtes (sur Google), alors que le principe d'Internet c'est d'être décentralisé, du coup je préférerais avoir la librairie incluse dans le navigateur par exemple.
Un dernier petit exemple, les referer, on sait que Facebook & co, peuvent suivre les utilisateurs, même si ils ne sont pas inscrits grâce au bouton "j'aime" parce ce que le navigateur transmet le site référant à l'image du bouton.
C'est pour tout ça et pour d'autres exemples que je pense que Mozilla a arrêté de se battre pour des idéaux. Et si ils ont arrêté de se battre, alors on a plus rien à attendre d'eux.
Et je sais bien que certains exemples, que j'ai cité, peuvent casser certains sites web ou sont contraires aux RFCs mais je résumerai en disant qu'avant, on avait au moins le choix, maintenant on a le choix du conformisme.
Pour revenir au sujet, DANE semble aller dans le bon sens pour résoudre les faiblesses d'HTTPS mais j'aime bien mon idée aussi.
En fait, je pense que les deux sont bonnes, DANE résout les faiblesses d'HTTPS, alors que ma proposition voudrait généraliser le cryptage des données de la plus simple des manières.
DANE pour la sécurité des transactions, la chaîne de confiance, SHTTP pour généraliser la protection de la vie privée et des correspondances.
Et d'ailleurs, il faudrait appliquer les mêmes principes à SMTP mais celui-là est encore plus oublié qu'HTTP, et il faut rajouter le cryptage des requêtes DNS.
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.
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 0. Dernière modification le 07 mai 2015 à 16:17.
Il y a DNSCurve avec un système de clefs publiques et de courbes elliptiques (voir Wikipedia pour plus de détails).
dnscache le supporte et il y a curvedns mais pas de support dans BIND ou d'autres.
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 0.
J'ai trouvé un article sur dnscurve.org qui résume les problématiques NXT vs NSEC vs NSEC3, par contre, il date un peu donc je sais pas si c'est toujours d'actualité.
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 0.
DTLS est évoqué dans ce sens
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -3.
J'aime bien la théorie branlette intellectuelle, et alors? Y a ceux qui ont les idées, et ceux qui les appliquent (à leur sauce si ils veulent).
Je t'ai relu et en fait, je ne comprends pas ce que tu veux dire, ni quel problème je soulève.
Je pense avoir assez explicité mon idée donc je ne vais pas me répéter.
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -4.
Je suis plus attaché au principe général, qu'au principe technique que je propose:
Un système de clé privée/publique (par domaine/enregistrement dns) avec le support de PFP et l'enregistrement de l'empreinte dans le dns.
Et si il peut être adapter à SMTP ou d'autres, c'est encore mieux.
Le principe de clé privée/publique, il est commun à TLS, SSH. Alors, peu importe l'aspect technique.
Le sujet, c'est Mozilla qui pousse HTTP vers la sortie, mais je ne pense pas que généraliser HTTPS soit la solution, il y a trop de contraintes à gérer les certificats alors que une bonne paire de clefs avec un support PFP peut faire le travail.
[^] # Re: shttp
Posté par bakeru . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -4.
Au temps pour moi, j'avais zappé la discussion sur DANE et surtout sa description. C'est très intéressant d'ailleurs.
Pas mieux, j'ai pas encore essayé DNSSEC, uniquement à cause de l'énumération des enregistrements DNSSEC de la zone.
On est d'accord. Je vais divergé un peu mais mon opinion c'est que Mozilla ne défend plus les utilisateurs.
Premier exemple, Firefox 31.6.0 sous Windows (à vérifier pour GNU/Linux, *BSD), ne permet plus de désactiver javascript par l'interface utilisateur, il faut passer pour about:config.
Les requêtes safebrowsing semblent interroger les serveurs de Google, donc les sites qu'on visite, les fichiers qu'on télécharge, peuvent être connus de Google (Je serais moins réfractaire si c'était les serveurs de Mozilla).
Les requêtes Jquery (j'entends par là, tout ce qui va sur googleapis.com) qu'on retrouve sur certains sites et qui intérrogent les serveurs de Google encore, je comprends pas pourquoi on fait des requêtes (sur Google), alors que le principe d'Internet c'est d'être décentralisé, du coup je préférerais avoir la librairie incluse dans le navigateur par exemple.
Un dernier petit exemple, les referer, on sait que Facebook & co, peuvent suivre les utilisateurs, même si ils ne sont pas inscrits grâce au bouton "j'aime" parce ce que le navigateur transmet le site référant à l'image du bouton.
C'est pour tout ça et pour d'autres exemples que je pense que Mozilla a arrêté de se battre pour des idéaux. Et si ils ont arrêté de se battre, alors on a plus rien à attendre d'eux.
Et je sais bien que certains exemples, que j'ai cité, peuvent casser certains sites web ou sont contraires aux RFCs mais je résumerai en disant qu'avant, on avait au moins le choix, maintenant on a le choix du conformisme.
Pour revenir au sujet, DANE semble aller dans le bon sens pour résoudre les faiblesses d'HTTPS mais j'aime bien mon idée aussi.
En fait, je pense que les deux sont bonnes, DANE résout les faiblesses d'HTTPS, alors que ma proposition voudrait généraliser le cryptage des données de la plus simple des manières.
DANE pour la sécurité des transactions, la chaîne de confiance, SHTTP pour généraliser la protection de la vie privée et des correspondances.
Et d'ailleurs, il faudrait appliquer les mêmes principes à SMTP mais celui-là est encore plus oublié qu'HTTP, et il faut rajouter le cryptage des requêtes DNS.
# 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.