Question:
Pourquoi la spécification HTTP / 2 ne nécessite-t-elle pas TLS?
David Mulder
2016-01-29 23:38:52 UTC
view on stackexchange narkive permalink

Bien qu'aucun navigateur n'implémente la spécification HTTP / 2 complète pour le moment en se limitant à la partie TLS, il y a des histoires sur Internet selon lesquelles cette implémentation incomplète de la spécification est un moyen de résister au lobbying `` diabolique '' des fournisseurs de services mobiles qui veulent injecter des publicités et façonner le trafic. Maintenant, je comprends bien sûr que l'analyse, la mise en forme et même la modification du trafic sont possibles sur des connexions non sécurisées, mais est-il vrai que le manque de consensus sur le TLS requis a été causé par le lobbying des fournisseurs de services Internet? Et secondaire, y a-t-il des raisons de croire que si c'est le cas, que c'était principalement pour les raisons invoquées?

J'étais un peu en doute si je devais publier ceci sur sceptics.SE ou ici, mais je me suis dit qu'il y a des gens ici qui ont suivi le processus d'écriture de la spécification HTTP / 2, alors je demanderais ici. Si c'est hors-sujet ici, veuillez simplement fermer / migrer vers sceptics.SE (et je corrigerai le message avec une affirmation notable clairement citée).
Je n'ai pas suivi la conception HTTP / 2, mais ma première pensée est que * "les navigateurs utilisent déjà TLS, c'était probablement une partie très facile à construire sur la base de leur base de code existante" *. Ensuite, * "il y avait forcément des inquiétudes concernant les clients à faible puissance / mobiles incapables de gérer la surcharge HTTPS, ou les FAI incapables d'ajouter des proxies de mise en cache sur les connexions à latence élevée" *. Ensuite, * le façonnage du trafic n'est pas seulement mauvais et anticoncurrentiel, il peut faire partie d'un modèle d'entreprise à plusieurs niveaux *. En d'autres termes, quelles preuves vous font penser qu'il y avait un lobbying des FAI _motivé par la publicité et la mauvaise conception du trafic_?
@TessellatingHeckler Que c'est une histoire souvent répétée sur Internet. Est-ce une preuve? Non, c'est pourquoi je demande si c'est vrai ici ;-) Personnellement, je pense que c'est bizarre que les navigateurs nécessitent HTTP / 2 pour de «nouvelles fonctionnalités cool».
Ils ne nécessitent souvent pas HTTP / 2 mais HTTPS. Par exemple, la compression brotli n'est activée qu'avec HTTPS pour Firefox actuel et le prochain Chrome. La principale raison est la peur de l'incompatibilité avec les systèmes existants, car le HTTPS est plus sûr contre l'inspection par des appareils cassés.
Je vote pour clore cette question comme hors sujet parce que, sur la base de vos commentaires sur la réponse de Steffen, vous semblez chercher l'opinion de quelqu'un qui faisait partie du comité standard ou qui a suivi de près les travaux du comité. Une telle question semble trop subjective pour le format de ce site.
@NeilSmithline Les réponses présentent des opinions personnelles et je suis à la recherche de faits concrets, je trouve quelque peu insultant que la recherche de faits référencés sur la sécurité se termine par «apparemment chercher une opinion». Je veux dire, cette question pourrait bien être hors sujet, mais si elle est hors sujet, c'est à cause du thème de la question (processus de prise de décision derrière les aspects de sécurité des spécifications), pas à cause de la subjectivité. Je veux dire, on peut soutenir que l'on ne sait pas avec certitude quelles sont les `` vraies '' raisons pour lesquelles un groupe a fait pression contre quelque chose, mais
au moins si ISP où le lobby principal est une question totalement factuelle.
Mes excuses @DavidMulder. J'ai utilisé le mot «subjectif» car c'est l'une des raisons courantes de clôture des questions sur ce site. Peut-être ai-je été imprudent dans mon choix. Je pense généralement que la question est intéressante, mais pas celle qui convient bien à ce site. Je pense que c'est démontré par la réponse de Steffen qui a été votée alors que vous pensez qu'elle ne répond pas à votre question. Encore une fois, désolé pour mon choix de mot.
@NeilSmithline Comme je l'ai souligné dans mon premier commentaire, je suis tout à fait d'accord si cette question est hors sujet, mais ce n'est pas parce que c'est quelque peu différent que la question est hors sujet. Je veux dire, cela a clairement * quelque chose * à voir avec la sécurité (experte) et comme je l'ai également dit auparavant, je n'arrive pas à trouver des raisons pour que cela soit hors sujet. Peut-être que j'ai raté quelque chose sur la méta cependant ... mais ce serait bien de le lier ici alors. Quoi qu'il en soit, la réponse de Steffen répond maintenant à la question, mais je ne suis pas sûr si l'existence d'un vote positif et intéressant mais de retour (suite)
alors la réponse subjective est une raison pour que la question elle-même soit hors sujet. : /
Deux réponses:
Steffen Ullrich
2016-01-30 00:20:55 UTC
view on stackexchange narkive permalink

Il n'y a aucune raison technique de limiter HTTP / 2 à TLS. La communication sans TLS a son utilité technique, peu importe s'il s'agit d'un trafic non chiffré ou si le trafic est chiffré par d'autres moyens (VPN, etc.).

Restreindre HTTP / 2 à TLS dans la norme lierait l'utilisation du protocole HTTP / 2 à l'utilisation de TLS pour des raisons politiques (*) uniquement. De telles liaisons pour des raisons non techniques sont généralement évitées: si vous regardez par exemple la RFC pour HTTP / 1.1, elles maintiennent explicitement la couche de transport ouverte, c'est-à-dire reconnaissent que HTTP / 1.1 est généralement utilisé au-dessus de TCP / IP mais peut être utilisé en plus d'autres protocoles (RFC2616, section 1.4).

Ainsi, alors que l'on pourrait penser qu'il y a eu du lobbying diabolique, je pense que la majorité a simplement trouvé que les normes devraient être un lieu pour les détails techniques mais pas pour les politiques (*) déclarations.

Un fil de discussion intéressant dans ce contexte est Le chiffrement obligatoire est théâtre sur la liste de diffusion HTTP de l'IETF WG en 2013, qui met diversité d'opinions parmi les utilisateurs techniques. Et il est également visible à partir de ce fil de discussion qu'il ne s'agit pas d'un lobbying de la part d'un FAI ou similaire, mais qu'il existe des raisons techniques de ne pas trop lier HTTP / 2 à TLS, car TLS n'est pas connu pour être la solution optimale pour la diversité de l'authentification , des problèmes de cryptage et de confidentialité: dans certains cas, vous voulez avoir une meilleure protection que TLS peut offrir et dans d'autres cas, vous n'avez pas besoin de la protection mais la surcharge de TLS vous dérange.

(*) Pour clarifier ce que je considère comme politique: c'est moins de la géopolitique ou de la politique d'entreprise, mais surtout des opinions personnelles influencées par ces politiques plus larges. Cela conduit à des arguments basés sur la vision personnelle de la manière dont le monde devrait fonctionner et non sur des raisons techniques. Parfois, ces arguments politiques sont même aveugles aux arguments techniques parce qu'ils ne correspondent pas à la vision personnelle du monde. Cela inclut l'argumentation selon laquelle tous les cas d'utilisation nécessitent la confidentialité (ce que TLS n'offre pas complètement de toute façon), que les petits systèmes sans grandes ressources devraient simplement grandir ou ne pas utiliser HTTP, que la mise en cache est une chose sans importance qui n'a pas besoin d'être prise en compte (c'est-à-dire nous avons beaucoup de bande passante et ne nous soucions pas si les autres ne le font pas) etc.

Mais est-ce la raison pour laquelle ils ne l'ont pas fait? Comme dans, avez-vous suivi le développement de la spécification? Parce qu'à l'origine, il * était * destiné à être inclus et il a été supprimé à une date ultérieure.
Je n'ai pas suivi les discussions en détail mais seulement de manière approximative. Mais vous pouvez lire une vue plus détaillée sur http://daniel.haxx.se/blog/2015/03/06/tls-in-http2/. En effet, il y avait suffisamment de raisons techniques pour ne pas rendre le TLS obligatoire et les seules raisons pour le rendre obligatoire étaient politiques et non techniques.
Mais voyez, quand j'ouvre ce lien, il dit: "Qui était contre le TLS obligatoire? Oui, beaucoup de gens me le demandent, mais je m'abstiendrai de nommer des personnes ou des entreprises spécifiques ici car je n'ai pas l'intention de discuter avec eux des détails et des subtilités dans la façon dont je décris leurs arguments. Vous pouvez les trouver vous-même si vous le souhaitez et vous pouvez très certainement faire des suppositions éclairées sans même le faire. " donc -1 parce que c'est ** exactement ** ce que j'essaye de découvrir.
Comme dans, rien dans ce lien ou dans votre message ne répond à la question. Si quoi que ce soit, le lien que vous fournissez laisse l'option entièrement ouverte selon laquelle ce sont principalement les fournisseurs de services Internet qui ont fait pression pour ne pas le rendre obligatoire. D'autant que ce ne sont pas les navigateurs comme l'indique le fait qu'ils * l'ont * rendu obligatoire à la fin.
@DavidMulder: J'ai ajouté un lien vers une discussion sur la liste de diffusion IETF de 2013 où ce problème est discuté. À mon avis, cela montre qu'il y a suffisamment de raisons techniques pour ne pas faire dépendre HTTP / 2 de TLS et que ce n'est pas le lobbying de certains FAI qui était le problème ultime.
Je ne suis pas d'accord pour dire que le cryptage obligatoire est uniquement politique et non technique. La sécurité contre l'interception est très certainement un cas d'utilisation et un cas important. Maintenant, le cryptage crée des problèmes dans la mesure où vous ne pouvez pas mettre en cache https sans MiTM, mais c'est vraiment une question d'efficacité et de cas d'utilisation, et non ce que la plupart appelleraient politiques. Vous pouvez transformer n'importe quoi en argument politique. Mon choix de déjeuner pourrait être transformé en politique par exemple, mais cela ne rend pas ma décision intrinsèquement politique.
@SteveSether: Il existe des cas d'utilisation pour HTTP / 2 sans cryptage, il existe des cas d'utilisation pour une utilisation avec TLS, il existe des cas d'utilisation avec d'autres types de cryptage comme IPSec. Il n'y a aucune raison technique d'imposer l'utilisation de TLS pour le chiffrement ni de restreindre le chiffrement à TLS. Le cryptage et l'application sont deux couches différentes qui peuvent être combinées selon les besoins. Mais je ne pense pas que ce soit l'endroit pour refaire toutes les discussions. Jetez un œil aux discussions animées sur la liste de diffusion de l'IETF.
Steve Sether
2016-01-30 03:54:57 UTC
view on stackexchange narkive permalink

Le chiffrement obligatoire présente au moins une chose que la communication non chiffrée ne fait pas. Une communication véritablement cryptée de bout en bout (au moins http sur SSL) est impossible à mettre en cache et nécessite plus de bande passante. Le fait d'exiger SSL / TLS limiterait la mise en cache des informations non sensibles par un serveur proxy intermédiaire.

Le chiffrement a également un coût. Cela ajoute des frais généraux et ajoute de la puissance de traitement. Mais il en va de même pour de nombreuses fonctionnalités de n'importe quel protocole. Il est donc juste de se demander pourquoi le chiffrement est spécial et facultatif.

Il y a des raisons pratiques de ne pas exiger TLS également. À moins que vous ne souhaitiez former les utilisateurs à ignorer les certificats effrayants auto-signés ou expirés, TLS vous oblige à obtenir un certificat signé pour chaque point de terminaison et à le maintenir depuis leur expiration. Des millions d'appareils dans les foyers et les entreprises communiquent via http. Les moniteurs pour bébé, les machines à laver, les routeurs, les téléphones, etc. ont tous communément des interfaces http. Exiger TLS signifierait que ces appareils ne pourraient pas adopter http 2, et devraient rester sur http 1.1.

Il y a aussi d'autres problèmes, mais je pense que cela implique fortement ce qui est valorisé. Stephen appelle cela «politique», mais cela semble être une simplification excessive par rapport à un argument de normes. La politique peut signifier beaucoup de choses. Parfois, cela signifie des intérêts contradictoires. Parfois, cela signifie «géopolitique», et parfois il s'agit d'idéologie politique. Et parfois ça veut dire ... je ne sais même pas quoi. Jeter tout cela dans un seau semble un peu réducteur à mon avis.

"Le chiffrement a également un coût. Il ajoute des frais généraux et ajoute une certaine puissance de traitement." Ma première pensée. Imaginez un Arduino ou un autre microcontrôleur essayant de faire du TLS.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...