web-dev-qa-db-fra.com

Le contenu gzipping via TLS est-il autorisé?

J'ai donc ces quelques directives de compression au niveau http dans nginx:

gzip on;
gzip_http_version 1.1;
gzip_vary on;

J'ai lu que cela devrait être évité en raison d'une attaque CRIME/BREACH, est-ce correct?

tlsbeastcompressioncrimegzip
17
Florian Schneider

J'ai lu que cela devrait être évité en raison d'une attaque CRIME/BREACH, est-ce correct?

Ça dépend.

L'attaque CRIME est déjà atténuée dans les navigateurs actuels en ce qu'ils n'utilisent pas la compression TLS et ont une gestion spéciale des contextes dans HTTP/2.0. BREACH n'est pertinent dans le contexte de la compression de niveau HTTP que si les deux conditions suivantes s'appliquent toutes les deux en même temps (pour citer http://www.breachattack.com/ ):

  • Refléter l'entrée utilisateur dans les corps de réponse HTTP
  • Refléter un secret (tel qu'un jeton CSRF) dans les corps de réponse HTTP

Si aucun ou un seul d'entre eux ne s'applique, vous pouvez utiliser gzip sans être affecté par BREACH. Cela signifie que vous pouvez l'utiliser en toute sécurité pour toutes les pages statiques ou pour toutes les pages qui n'incluent pas de secrets comme les jetons CSRF (ce sont les secrets que l'attaquant veut extraire).

L'attaquant a également besoin de plusieurs requêtes sur le même site et doit être en mesure de voir comment la taille des données transférées change. Donc, si vos secrets changent tout le temps ou si le site change (comme avec l'ajout d'un remplissage aléatoire avec une taille aléatoire), l'attaquant ne pourra pas utiliser BREACH. Voir aussi Défense contre l'attaque INFRACTION .

15
Steffen Ullrich

gzipper des données cryptées SSL élimine les avantages de SSL dans une certaine mesure. Oui, gzipping [~ # ~] tout le contenu [~ # ~] peut ouvrir votre site Web à la vulnérabilité BREACH.

Mais vous pouvez toujours ajouter des ressources certaines pour gzipping. Par exemple, des images publiques peuvent être compressées au format gzip ou des documents publics en général. Cependant, vous devez soigneusement considérer si vous voulez "saboter" votre propre protection SSL.

Cela vaut également la peine d'être lu: https://stackoverflow.com/questions/2767211/can-you-use-gzip-over-ssl-and-connection-keep-alive-headers

EDIT: Je voudrais ajouter qu'en utilisant SPDY, vous pouvez obtenir une compression similaire via des en-têtes compressés et une négociation/renégociation raccourcie des clés. Vous pouvez également "pré" -compresser les ressources fréquemment utilisées (mais ce n'est pas exclusif à SPDY).

2
Scrayos

Le fonctionnement de SSL/TLS et Gzipping est qu'il mappe les données pour réduire la taille d'un paquet d'une manière prévisible et répétable qui peut ensuite être annulée. Ce n'est pas un problème si les pages sont statiques et ont aucun jeton ou cookie envoyé avec eux. En effet, les données demandées sur le site seront constamment les mêmes et la taille des paquets ne changera donc pas. Cependant, avec une page dynamique, le contenu a toujours changé, sauf un peu dans le CSRF et les données utilisateur. En utilisant ces informations, ils peuvent injecter des données dans une demande ou un corps. C'est un problème car cela leur permet de changer le contenu du paquet et de voir comment les cartes de compression sont mappées. Ils ont finalement accès à certaines choses dans le paquet, y compris les cookies, les mots de passe ou les informations utilisateur, Cross Site Demandez des jetons de contrefaçon et tout ce qui a été envoyé.

Pour cette raison, il n'est pas recommandé d'utiliser TLS/SSL pour la compression dynamique des données sensibles, car le paquet peut éventuellement être violé.

0
Robert Mennell