Pourquoi avons-nous besoin de HTTPS pour le contenu statique? Si nous pouvons avoir une somme de contrôle à la fin signée par la clé privée, cela ne prouvera-t-il pas la validité?
Cette méthode dont je parle peut améliorer la mise en cache des images, des vidéos et des CSS par le FAI plutôt que simplement en fonction du cache du navigateur. Et cela prouve également la validité de l'expéditeur. Y a-t-il une raison pour laquelle ce semi-HTTP n'est pas pris en compte?
Le coût de la signature asymétrique est une chose à laquelle je peux penser. Mais si nous regroupons des morceaux de contenu statique et calculons la somme de contrôle sha256 par lots, la validation de la signature dans le navigateur peut être un meilleur compromis que le coût réseau de bout en bout pour chaque demande ne se trouvant pas dans le cache du navigateur.
Pourquoi avons-nous besoin de HTTPS pour le contenu statique? Si nous pouvons avoir une somme de contrôle à la fin signée par la clé privée, cela ne prouvera-t-il pas la validité?
Je pense que vous mettez en place un homme de paille avec cette question. En fait, nous n'avons pas besoin de HTTPS pour le contenu statique, et le but de HTTPS n'est pas seulement de prouver la validité du contenu. C'est juste un de plusieurs fins. La décision de basculer un grand nombre de sites vers HTTPS (même ceux qui proposent du contenu statique inoffensif, comme wikipedia) au cours des deux dernières années ne s'est pas produite principalement parce que les gens craignaient d'obtenir le mauvais contenu; c'est parce que les gens craignaient que les agences à trois lettres espionnent les utilisateurs; par exemple. le passage à grande échelle au HTTPS s'est produit principalement pour des raisons de confidentialité (voir par exemple RFC 7258, Pervasive Monitoring is an Attack - merci à Michael Kjörling de l'avoir signalé).
Votre idée d'utiliser une somme de contrôle signée est déjà en production partout sur Internet: les logiciels que vous téléchargez sont souvent vérifiés comme ça. Les gestionnaires de packages/systèmes de mise à jour de la plupart des systèmes d'exploitation le font, et les projets logiciels individuels le font à plus petite échelle en publiant des signatures pgp/gpg avec leurs téléchargements de logiciels.
Tout cela fonctionne indépendamment du fait que ces téléchargements soient livrés via https ou non, bien que https soit souvent utilisé en plus .
Vous proposez d'ajouter un troisième protocole en plus de http et https, peut-être un appelé httpv pour "vérifié", qui intègre la vérification du contenu dans le protocole mais laisse de côté le reste de ssl.
Je suis d'accord qu'il y aurait un avantage à diffuser du contenu statique en clair afin qu'il puisse être mis en cache. Mais ce n'est pas une option si vous vous inquiétez des problèmes de confidentialité à la lumière des programmes de la communauté du renseignement pour espionner toutes nos communications.
Une raison particulière pour laquelle ce semi HTTP n'est pas considéré?
Je suppose donc que votre troisième protocole ne peut pas rassembler beaucoup de vapeur, car
il existe déjà des solutions qui fonctionnent lorsque nous avons vraiment besoin de vérifier le contenu, et
avec une grande partie d'Internet maintenant cryptée pour protéger notre vie privée, il semble qu'il n'y aurait pas beaucoup d'utilisation pour un autre protocole que ne protégeait pas contre l'espionnage.
Votre suggestion est essentiellement de diviser HTTPS en deux choses: signature uniquement et cryptage: la signature seule empêche un homme actif au milieu d'injecter son propre contenu - comme les balises de script - et le cryptage protégerait les données sensibles.
Mais qui déciderait des données sensibles et de celles qui ne le sont pas? Cela semble long et source d'erreurs.
Vous pouvez bien sûr déclarer automatiquement les images, CSS, vidéos et fichiers JS comme non sensibles. Mais le sont-ils?
- Les fichiers JS sont utilisés pour échanger des données
- Les images et les vidéos peuvent contenir des données très sensibles
- Les fichiers CSS peuvent fournir un aperçu de la page spécifique qu'une personne consulte
- Toutes les demandes peuvent contenir des données sensibles dans la réponse d'en-tête HTTP (telles que les cookies en cours de définition)
Votre idée nécessiterait également d'autres modifications:
- Et HSTS? Il force tout le trafic via HTTPS et est fortement recommandé. Votre HTTP de signature seule compterait-il? Comment cela fonctionnerait-il dans la pratique?
- Et l'utilisabilité? L'interface du navigateur devrait indiquer à l'utilisateur le "mode" actuellement utilisé. Et cela nécessiterait une formation supplémentaire de l'utilisateur sur la signification des modes et le moment approprié. Cela entraînera beaucoup de confusion (les utilisateurs ne comprennent même pas tous les éléments de l'interface actuelle, tels que le cadenas ou les divers avertissements).
- Vous devrez en quelque sorte signaler au serveur de mise en cache du FAI que vous demandez ce fichier. Vous ne pouvez pas simplement envoyer la demande au serveur via HTTP, car cela entraînerait une fuite de cookies et d'autres données sensibles. Ou vous devrez spécifier que les cookies ne doivent jamais être envoyés à ces fichiers non sensibles. Mais comment feriez-vous cela de manière fiable? Bien sûr, ils pourraient être servis à partir d'un domaine différent, mais cela nécessite une refonte majeure des sites Web existants. Et si ces fichiers non sensibles devaient être protégés par une sorte d'authentification?
En dehors de cela, les avantages de cette approche semblent faibles. D'après ce que je lis, les FAI ne mettent plus rien en cache car les CDN s'en occupent déjà.
tl; dr: L'approche violerait la vie privée des utilisateurs et introduirait des problèmes de sécurité en raison de problèmes d'utilisabilité pour l'utilisateur final ainsi que pour le développeur.
L'implémentation d'une sorte de somme de contrôle fonctionnerait, oui. Mais l'utilisation de TLS est beaucoup plus facile.
Il est également généralement conseillé d'utiliser des protocoles standard, sauf si vous avez une très bonne raison de ne pas le faire.
Enfin, https offre une variété d'autres avantages. Dans les limites du système CA, vous savez que vous recevez le fichier de qui vous pensez être. Et il offre une confidentialité à vos utilisateurs, empêchant les observateurs de voir quelles URL spécifiques ils demandent.
Il y a quelques problèmes de sécurité auxquels je peux penser.
Replay et substitution
Rien n'empêche un homme au milieu de remplacer une ressource signée par une autre ressource signée (capturée précédemment). Par exemple, je pourrais être en mesure de faire apparaître un bouton vert GO à l'endroit où devrait se trouver un bouton STOP, ce qui vous fera quitter une falaise. Ou je pourrais faire croire que votre transfert en espèces a échoué afin que vous le soumettiez encore et encore et que je sois payé plusieurs fois.
Si une partie du contenu statique d'un site est un fichier Javascript, je peux peut-être l'échanger avec un autre fichier Javascript du même site. Si je suis intelligent, je peux peut-être en trouver un qui a les mêmes noms de fonction mais qui fait des choses différentes, ou qui manque de certaines validations.
Redirection
Je pourrais intercepter votre demande d'image et répondre avec une redirection 302 vers une URL dont les paramètres de chaîne de requête comprennent une attaque XSRF.
Perte d'intimité
Un pirate informatique surveillant votre trafic peut être en mesure de déterminer les pages que vous visitez en examinant le modèle de requêtes http pour les ressources statiques.
DoS via l'empoisonnement du cache
Un pirate, travaillant un homme au milieu, substitue un fichier invalide à l'une des réponses. Le proxy met le fichier en cache. Les navigateurs qui tentent d'utiliser la ressource mise en cache constateront qu'elle échoue à la validation et afficheront une erreur, sans moyen facile de contourner le problème.
Problème de performances P.S
En outre, il existe un problème de performances: les ressources soumises à une somme de contrôle ne pourront pas être rendues progressivement, car l'intégralité du BLOB est requise pour calculer la somme de contrôle. Ainsi, vos images apparaîtront plus lentement et votre film ne commencera pas tant que le tout n'aura pas traversé le tuyau.
Ceci est partiellement résolu par intégrité de la sous-ressource . Vous servez la page principale sur HTTPS, et cela inclut les métadonnées/hachages de sous-ressource, les sous-ressources peuvent ensuite être récupérées sur HTTP pour être mises en cache par les proxys ISP ou sur HTTPS pour être mises en cache par un CDN et vous pouvez être sûr que la ressource n'est pas altérée par les intermédiaires tant que le hachage correspond.
Cependant, les navigateurs considèrent toujours les sous-ressources livrées de cette façon comme du contenu mixte, car tout modèle qui autorise la mise en cache du FAI manque de confidentialité. Au lieu de cela, le modèle qui est poussé de nos jours est pour les propriétaires de sites de configurer un CDN pour effectuer la mise en cache réseau Edge, donc les caches Edge sont payés par le propriétaire du site plutôt que par les utilisateurs. Cela augure également mieux avec le FAI en tant que modèle muet de neutralité du réseau.
Si nous pouvons avoir une somme de contrôle à la fin signée par la clé privée, cela ne prouvera-t-il pas la validité? ... Une raison particulière pour laquelle ce semi HTTPs n'est pas considéré?
Probablement parce qu'il est trivial de retirer la signature et vous retomberez dans un contenu non signé. Le modèle SRI, d'autre part, exige que le document principal indique quand la sous-ressource devrait être sécurisée.
Il faut comprendre que les fournisseurs de navigateurs n'ont eu que de mauvaises expériences avec les "boîtiers intermédiaires", et ils ont choisi le chiffrement de bout en bout comme le meilleur moyen de les empêcher d'interférer. C'est pourquoi, par exemple, ils refusent d'implémenter le texte clair HTTP/2.0. Pour la même raison, il est très peu probable que quelque chose dans le sens de votre idée soit adopté.
Il existe des techniques pour signer le contenu statique d'un site Web, en particulier HTML, par exemple:
- http://www.sanface.com/pgphtml.html
- https://web.archive.org/web/20080725190448/http://members.aol.com/EJNBell/pgp-www.html
De telles initiatives ne sont pas encore devenues populaires. Je soupçonne que c'est pour trois raisons:
- ils sont difficiles à mettre en œuvre;
- le changement culturel vers un développement Web plus sûr (dont l'utilisation généralisée de HTTPS est une facette) était encore à ses balbutiements lorsqu'ils ont été proposés pour la première fois;
- de nombreux développeurs Web ne savent pas comment utiliser les outils OpenPGP, et encore moins posséder une clé de signature OpenPGP générée et stockée de manière sécurisée.
Néanmoins, ces techniques constituent en principe un excellent mécanisme pour vérifier l'intégrité des ressources statiques sur les sites Web.
Même si une telle signature de ressources Web statiques était universelle, cependant, il y aurait toujours un avantage à implémenter HTTPS: confidentialité . La signature seule ne fournirait pas cela, mais le cryptage fourni par HTTPS le fournirait. (Au moins, HTTPS assurerait la confidentialité tant que la spécification applicable pour HTTPS n'a pas de bogues critiques et a été correctement implémentée.)