Question:
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é?
kalyan
2017-03-12 08:59:19 UTC
view on stackexchange narkive permalink

Cette méthode dont je parle peut améliorer la mise en cache des images, des vidéos et du CSS par le FAI plutôt que de simplement dépendre du cache du navigateur. Et cela prouve également la validité de l'expéditeur. Y a-t-il une raison pour laquelle ces semi-HTTP ne sont 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 du réseau de bout en bout pour chaque requête ne figurant pas dans le cache du navigateur.

Vous souhaitez passer beaucoup de temps CPU à calculer ces hachages?De plus, comment comptez-vous vérifier que vous avez reçu le ou les hachages corrects du serveur?Comment allez-vous "décrypter" en utilisant un hachage?Le hachage n'est pas un cryptage.
Le hachage sera signé par la clé privée du site.Ainsi, le certificat du site peut également être mis en cache qui a une clé publique.Désormais, le hachage du contenu statique est validé par la clé publique à condition que le certificat soit approuvé.Le contenu Reg pour adultes ou le contenu dynamique HTTPS peut être utilisé.HTTPS et cette technique de hachage peuvent coexister mais les objets HTTP et HTTPS ne peuvent pas coexister dans la même page
Je pense que vous parlez essentiellement des suites de chiffrement dites "NULL" comme `TLS_RSA_WITH_NULL_SHA256`.Ils sont très découragés et je ne les ai jamais vus mis en œuvre par accident.
Yah similaire aux suites nulles.Les suites de chiffrement nulles sont découragées par openssl car elles n'assurent pas la confidentialité.Mais le contenu statique peut être visible jusqu'à ce que la validité de l'expéditeur soit prouvée
@MarkBuffalo Je pense que vous avez mal compris la prémisse derrière la question.En outre, compte tenu de ce que fait déjà TLS, le calcul du hachage des données transférées est trivial.
Vous pouvez jeter un œil au [projet de signatures http] (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/).Mais celui-ci est toujours en cours de rédaction depuis près de 4 ans maintenant.
Je sais que le contexte est pour les navigateurs, mais qu'en est-il des applications, principalement celles qui utilisent un cryptage de bout en bout?Ceux-ci peuvent-ils utiliser HTTP pour le transport de données?Quels sont les problèmes de faire cela?MEGA, par exemple, utilise toujours HTTP lorsque cela est possible.
@MarkBuffalo Si l'argument du temps CPU ne fonctionne pas pour TLS, pourquoi pensez-vous que cela fonctionnerait pour quelque chose de plus facile que TLS?
@Scovetta Eh bien, c'est parce qu'il est supposé que toute personne utilisant TLS veut toute la sécurité de TLS et donc utiliser le chiffrement nul est une erreur.Mais la question se pose: et si vous ne voulez pas toutes les fonctionnalités de sécurité de TLS?(De plus, je ne sais pas si TLS avec chiffrement nul fournit toujours l'authentification ou non; je devrais le rechercher. Le schéma proposé * fournirait * l'authentification sans chiffrement)
Je pense que le plus gros problème de loin, ce sont les attaques de relecture que John Wu souligne.Je ne veux pas que les attaquants remplacent des parties d'un site Web auquel j'accède par d'autres parties de celui-ci;pourrait potentiellement causer des dommages graves.
Une attaque de substitution convenue est tout à fait possible @sudo
Pourquoi les gens continuent-ils à chercher des raisons artificielles de ne pas utiliser HTTPS?C'est généralement le chemin le meilleur et le plus simple!* (hurlement autiste) *
@xDaizu rien de mal dans la discussion que je ressens que d'avoir une notion préconçue
HTTPS est également une question de confidentialité.Les signatures numériques ne garantissent pas cela.
Sept réponses:
#1
+54
Out of Band
2017-03-12 14:53:07 UTC
view on stackexchange narkive permalink

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 configurez 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 objectifs. Le passage d'un grand nombre de sites à HTTPS (même ceux proposant du contenu statique inoffensif, comme wikipedia) au cours des deux dernières années ne s'est pas produit 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 à HTTPS s'est produit principalement pour des raisons de confidentialité (voir par exemple RFC 7258, Pervasive Monitoring is an Attack - merci à Michael Kjörling pour l'avoir signalé).

Votre l'idée d'utiliser une somme de contrôle signée est déjà en cours de 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 à une 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é via https ou non, bien que https soit souvent utilisé en plus .

Vous suggérez d'ajouter un troisième protocole en plus de http et https, peut-être 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 à servir du contenu statique en clair pour 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 pris en compte?

Je suppose donc que votre troisième protocole ne peut pas générer beaucoup de vapeur car

  1. il existe déjà des solutions qui fonctionnent lorsque nous avons vraiment besoin de vérifier le contenu, et

  2. Avec une grande partie d'Internet qui est désormais cryptée pour protéger notre vie privée, il semble qu'il n'y aurait pas beaucoup d'utilité pour un autre protocole que n'a pas se protéger contre l'espionnage.

Cela a beaucoup de sens en ce qui concerne la confidentialité.Les gens ne savent pas qui a vu quelles vidéos ou images.Les problèmes de confidentialité réduisent les cas d'utilisation.
Vous devriez vraiment faire référence aux [Meilleures pratiques actuelles d'Internet (BCP) 188] (https://tools.ietf.org/html/bcp188).Aussi connu sous le nom de [RFC 7258] (https://tools.ietf.org/html/rfc7258).Dans les mots de son titre, * Pervasive Monitoring Is an Attack *.Du bas de sa section 2: "Les capacités actuelles permettent à certains acteurs de surveiller le contenu et les métadonnées sur Internet à une échelle jamais vue auparavant. Cette surveillance omniprésente est une attaque contre la confidentialité sur Internet. L'IETF s'efforcera de produire des spécifications qui atténuent la surveillance omniprésente.attaques. "Vous n'obtenez pas une déclaration de politique beaucoup plus claire dans une RFC.
#2
+16
tim
2017-03-12 14:39:57 UTC
view on stackexchange narkive permalink

Votre suggestion est de diviser le HTTPS en deux choses: Signing-Only et Encryption: Signing-Only 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 de ce qui est une donnée sensible et de ce qui ne l'est pas? Cela semble prendre du temps et être 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 des informations sur la page spécifique d'une personne consulte
  • Toutes les demandes peuvent contenir des données sensibles dans la réponse d'en-tête HTTP (comme les cookies en cours de définition)

Votre idée nécessiterait également d'autres modifications:

  • Et le HSTS? Il force tout le trafic via HTTPS et est fortement recommandé. Est-ce que votre compte HTTP de signature uniquement? Comment cela fonctionnerait-il dans la pratique?
  • Qu'en est-il de la convivialité? L'interface du navigateur devrait indiquer à l'utilisateur quel "mode" est actuellement utilisé. Et cela nécessiterait une formation supplémentaire de l'utilisateur sur ce que signifient les modes, et quand quel mode est 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 différents avertissements).
  • Vous auriez besoin en quelque sorte de 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 mettent rarement en cache quoi que ce soit parce que les CDN s'en occupent déjà.

tl; dr : L'approche violerait la confidentialité 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.

La confidentialité a beaucoup de sens.Un bootstrap CSS ou jQuery très courant peut s'intégrer. Mais les problèmes de confidentialité réduisent le cas d'utilisation car le référent peut être visible dans l'en-tête HTTP
Fait amusant: il existe déjà des chiffrements SSL qui fournissent [une authentification sans chiffrement] (https://www.rfc-editor.org/rfc/rfc4785.txt).Les navigateurs les autorisent cependant, car ils pourraient être utilisés pour donner à l'utilisateur un faux sentiment de confidentialité.
@user2428118 Vous vouliez dire "les navigateurs ne les autorisent pas", non?
AilienidyoCMT Oui
@kalyan "Un agent utilisateur NE DOIT PAS envoyer un champ d'en-tête Referer dans une demande HTTP non sécurisée si la page de référence a été reçue avec un protocole sécurisé."([RFC 7231 § 5.5.2] (https://tools.ietf.org/html/rfc7231#section-5.5.2))
+1 Je suis un peu choqué que, sur tant de réponses, vous soyez le seul à avoir mentionné les en-têtes de cookie HTTP.C'est de loin la raison la plus importante d'utiliser HTTPS.
@RaduMurzea Par définition, les données publiques statiques n'ont pas besoin de cookie.
#3
+13
Xiong Chiamiov
2017-03-12 13:15:44 UTC
view on stackexchange narkive permalink

L'implémentation d'une sorte de somme de contrôle fonctionnerait, oui. Mais utiliser 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 dont vous pensez être. Et il assure la confidentialité de vos utilisateurs, empêchant les observateurs de voir les URL spécifiques qu'ils demandent.

Mais le contenu statique qui pourrait être mis en cache par le FAI n'est pas possible avec HTTPS.Et HTTP et HTTPS rester ensemble sur la même page n'est pas possible.Cela a du sens car la validité de l'expéditeur ne peut pas être vérifiée.La signature de la somme de contrôle vérifiera la validité.La partie privée de la partie dynamique peut être préservée en permettant à HTTPS et à la signature numérique du contenu statique de coexister ensemble.Je me demande pourquoi cette technique n'est pas envisagée ou est-elle envisagée?Si oui, quels sont les inconvénients?
De plus, TLS est bien sûr ... enfin, ** TL ** S.
@kalyan J'ai assez de problèmes avec les navigateurs qui ne respectent pas les paramètres de cache et qui se rafraîchit bien.Les FAI mettant en cache mon contenu statique serait un ** cauchemar **.
@ceejayoz D'accord.Mais le contenu HTTP est même maintenant mis en cache par les FAI et les instituts.Le proxy Squid ou d'autres proxys de transfert font cela
@kalyan Raison de plus pour utiliser le HTTPS pour tout.
@kaylan le FAI perdra rapidement tous ses clients si leur contenu mis en cache ne correspond plus à la somme de contrôle envoyée par le serveur d'origine.
@ceejayoz: Cela pourrait être résolu en incorporant un hachage dans l'URL.Le scénario d'utilisation typique que je peux voir pour le contenu statique authentifié impliquerait un serveur https qui sait exactement ce que le contenu statique devrait être, et devrait donc pouvoir inclure un hachage dans l'URL.Si le contenu doit changer, le serveur https doit le savoir et fournir une URL différente pour celui-ci, ce qui rendrait le contenu mis en cache précédent non pertinent.
Pas besoin de mise en cache ISP.Les CDN ont déjà gagné.
#4
+13
John Wu
2017-03-13 00:44:37 UTC
view on stackexchange narkive permalink

Il y a quelques problèmes de sécurité auxquels je peux penser.

Relecture et substitution

Rien n'empêche un homme au milieu de remplacer une ressource signée par une autre ressource signée ( capturé précédemment). Par exemple, je pourrais peut-être faire apparaître un bouton vert GO à l'endroit où un bouton STOP devrait se trouver, ce qui vous fera descendre d'une falaise. Ou je pourrais donner l'impression que votre transfert d'argent 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 sur le même site. Si je suis intelligent, je peux peut-être en trouver une 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 de confidentialité

Un pirate informatique surveillant votre trafic peut être en mesure de déterminer les pages que vous visitez en examinant le modèle des requêtes http pour les ressources statiques.

DoS via l'empoisonnement du cache

Un hacker, 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 simple de contourner le problème.

P.S. Problème de performances

Il existe également un problème de performances: les ressources soumises à une somme de contrôle ne pourront pas être rendues progressivement, car l'ensemble du BLOB est nécessaire pour calculer la somme de contrôle. Ainsi, vos images apparaîtront plus lentement et votre film ne démarrera pas tant que le tout n’aura pas traversé le tube.

+1 Bonne réponse.En ce qui concerne 1) "replay" est un peu trompeur, je pense qu'une simple "substitution" serait plus claire. 2) Je suppose que les en-têtes sont également signés (peut-être séparément).Sinon, il y aurait beaucoup de problèmes 4) Je suppose que la plupart des mitm se situent entre l'utilisateur et le FAI, mais ici, ils devraient s'asseoir entre le FAI et le serveur.Encore un bon point cependant.
Bonne réponse.En ce qui concerne DOS via empoisonnement, même maintenant en https DOS via l'homme au milieu avec certificat auto-signé ou usurpation d'identité est possible.Mais la partie de substitution a beaucoup de sens
"peut-être que je peux en trouver une qui a les mêmes noms de fonction mais qui fait des choses différentes, ou qui manque de certaines validations" - plus dangereusement, utiliser la version du même fichier avant de corriger une faille de sécurité critique.Si la relecture est possible, alors les corrections de bugs (pour les personnes qui sont attaquées) sont impossibles.Bien sûr, c'est un problème pour le contenu mis en cache en général, et les signatures numériques peuvent avoir des dates d'expiration, etc.Mais vous devez être sûr que c'est une bonne idée, avant de laisser un tiers mettre en cache quelque chose pour lequel vous comptez normalement sur https pour la sécurité.
Que diriez-vous de faire un hachage de la signature faire partie de l'URL?Cela limiterait les cas d'utilisation à ceux où l'entité servant l'URL savait quel contenu était attendu, mais si la fonction de hachage est bonne, elle devrait éviter tout problème de mise en cache et bloquer toute attaque de substitution.
Vous pourriez peut-être résoudre le problème de performances en signant des parties du fichier plutôt que le tout.Plus de vérification de hachage est mauvaise, mais au moins vous pourrez commencer à charger les ressources avant qu'elles ne soient entièrement reçues.
#5
+12
Lie Ryan
2017-03-12 21:24:04 UTC
view on stackexchange narkive permalink

Ce problème est en partie résolu par l ' intégrité des sous-ressources. Vous servez la page principale via HTTPS, et cela inclut les métadonnées / hachages de sous-ressources, les sous-ressources peuvent ensuite être récupérées via HTTP pour être mises en cache par des proxies FAI ou via HTTPS pour être mises en cache par un CDN et vous pouvez être sûr que la ressource n'est pas gérée par les intermédiaires tant que le hachage correspond.

Cependant, les navigateurs considèrent toujours les sous-ressources livrées de cette manière comme du contenu mixte car tout modèle qui permet la mise en cache des FAI manque de confidentialité. Au lieu de cela, le modèle qui est mis en avant de nos jours est que les propriétaires de sites mettent en place un CDN pour faire la mise en cache du réseau périphérique, ainsi les caches périphériques sont payés par le propriétaire du site, plutôt que par les utilisateurs. Cela présage également mieux avec le FAI en tant que modèle stupide 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 HTTP n'est pas pris en compte?

Probablement parce qu'il est trivial de supprimer la signature et que vous retomberez dans un contenu non signé. Le modèle SRI, par contre, exige que le document principal indique quand la sous-ressource devrait être sécurisée.

L'intégrité des sous-ressources est assez similaire à la stratégie ci-dessus.Mais oui, la confidentialité et la neutralité du net sont un problème
L'intégrité des sous-sources sert à valider que la ressource n'a été modifiée par * personne *, y compris le propriétaire légitime de la ressource.N'a rien à voir avec l'interception et n'est en aucun cas interchangeable avec https.En effet, tous les exemples du [lien] (https://www.w3.org/TR/2015/WD-SRI-20150707/) que vous avez fournis utilisent en fait https.
+1 pour mentionner l'intégrité des sous-ressources qui est quelque chose qui est utilisé irl et très proche de ce que OP a demandé
@JohnWu si le propriétaire de la ressource est également le propriétaire de la page qui l'inclut, alors le propriétaire peut la modifier en modifiant également la somme de contrôle.
Je ne sais pas quel est votre point de vue immibis.Si le propriétaire de la ressource est également le propriétaire de la page, il ne s'agit pas d'une ressource tierce et le SRI n'est pas nécessaire.
#6
+1
zwol
2017-03-13 00:24:34 UTC
view on stackexchange narkive permalink

Il faut comprendre que les éditeurs de navigateurs n'ont eu que de mauvaises expériences avec les "middlebox", et ils ont choisi le cryptage 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 HTTP / 2.0 en clair. Pour la même raison, il est très peu probable que tout ce qui ressemble à votre idée soit adopté.

Je parie que c'est la vraie raison.Rien à voir avec le fait que les fournisseurs de navigateurs ne sont pas satisfaits des connexions non chiffrées.
#7
+1
sampablokuper
2017-03-13 13:59:10 UTC
view on stackexchange narkive permalink

Il existe des techniques pour signer le contenu statique d'un site Web, en particulier HTML, par exemple:

De telles initiatives ne sont pas encore devenues populaires. Je soupçonne que c'est pour trois raisons:

  • ils sont fastidieux à mettre en œuvre;
  • le changement culturel vers un développement Web plus sécurisé (dont l'utilisation généralisée du HTTPS est une facette) en é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èdent une clé de signature OpenPGP générée et stockée en toute sécurité.

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 étaient universelles, cependant, il y aurait toujours un avantage à mettre en œuvre 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.)

Pourquoi tout le monde semble-t-il penser "qu'il y a encore un avantage au HTTPS qui est qu'il est confidentiel" est un argument décisif en faveur du HTTPS?Il y a toujours un avantage à implémenter la signature HTTP + qui est qu'elle peut être mise en cache.
@immibis, Je ne sais pas pourquoi vous avez posté cette question sur ma réponse, car ma réponse n'indique pas que la confidentialité équivaut à un argument décisif en faveur du HTTPS.Peut-être me confondez-vous avec quelqu'un d'autre?


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...