Un serveur proxy peut-il mettre en cache les GET SSL ?Dans la négative, le chiffrement du corps de la réponse suffirait-il ?

Question

Un (||n'importe quel) serveur proxy peut-il mettre en cache le contenu demandé par un client via https ?Comme le serveur proxy ne peut pas voir la chaîne de requête ou les en-têtes http, je pense qu'il ne le peut pas.

J'envisage une application de bureau, gérée par un certain nombre de personnes derrière le proxy de leur entreprise.Cette application peut accéder à des services sur Internet et j'aimerais profiter de l'infrastructure de mise en cache Internet intégrée pour les « lectures ».Si les serveurs proxy de mise en cache ne peuvent pas mettre en cache le contenu fourni par SSL, le simple chiffrement du contenu d'une réponse serait-il une option viable ?

Je considère que toutes les requêtes GET que nous souhaitons pouvoir mettre en cache doivent être demandées via http avec le corps chiffré à l'aide d'un cryptage asymétrique, où chaque client possède la clé de déchiffrement.Chaque fois que nous souhaitons effectuer un GET qui n'est pas mis en cache, ou une opération POST, cela sera effectué via SSL.

Answer 1

Non, il n'est pas possible de mettre directement en cache https.L'ensemble de la communication entre le client et le serveur est crypté.Un proxy se situe entre le serveur et le client, pour le mettre en cache, il faut pouvoir le lire, c'est à dire décrypter le cryptage.

Vous pouvez faire quelque chose pour le mettre en cache.En gros, vous effectuez le SSL sur votre proxy, en interceptant le SSL envoyé au client.Fondamentalement, les données sont cryptées entre le client et votre proxy, elles sont décryptées, lues et mises en cache, et les données sont cryptées et envoyées sur le serveur.La réponse du serveur est également décryptée, lue et cryptée.Je ne sais pas comment procéder sur les principaux logiciels proxy (comme Squid), mais c'est possible.

Le seul problème avec cette approche est que le proxy devra utiliser un certificat auto-signé pour le chiffrer auprès du client.Le client pourra savoir qu'un proxy au milieu a lu les données, puisque le certificat ne proviendra pas du site d'origine.

Answer 2

Le commentaire de Rory selon lequel le proxy devrait utiliser un certificat auto-signé s'il n'est pas strictement vrai.

Le proxy pourrait être implémenté pour générer un nouveau certificat pour chaque nouvel hôte SSL avec lequel il est invité à traiter et le signer avec un certificat racine commun.Dans le scénario OP d'un environnement d'entreprise, le certificat de signature commun peut assez facilement être installé en tant qu'autorité de certification de confiance sur les machines clientes et ils accepteront volontiers ces "faux" certificats SSL pour le trafic proxy car il n'y aura pas d'incompatibilité de nom d'hôte.

En fait, c'est exactement ainsi que des logiciels tels que Proxy de débogage Web Charles permettre l'inspection du trafic SSL sans provoquer d'erreurs de sécurité dans le navigateur, etc.

Answer 3

Je pense que vous devriez simplement utiliser SSL et vous appuyer sur une bibliothèque client HTTP qui effectue la mise en cache (Ex :WinInet sous Windows).Il est difficile d'imaginer que les avantages de la mise en cache à l'échelle de l'entreprise valent la peine d'écrire un système de cryptage de sécurité personnalisé ou un certificat amusant sur le proxy.Pire encore, sur le schéma de chiffrement que vous mentionnez, effectuer des chiffrements asymétriques sur le corps de l'entité ressemble à un énorme succès en termes de performances du côté serveur de votre application ;il y a une raison pour laquelle SSL utilise des chiffrements symétriques pour la charge utile réelle de la connexion.

L'application concernée n'est pas une application de navigateur, c'est une application de bureau qui extrait des données sur Internet.Ce qui va se passer, c'est que toutes les instances de l'application extrairont le même élément à peu près au même moment.Ces données doivent être sécurisées, mais j'espère augmenter les performances en permettant à certaines instances de l'application d'obtenir une version en cache du serveur proxy d'entreprise.

Les blocs de données sont petits, mais ils peuvent être demandés fréquemment.Essentiellement, toutes les instances d’application vont demander les mêmes données les unes que les autres en même temps.

Le corps des données/messages côté serveur sera pré-chiffré et mis en cache dans une table de hachage distribuée en mémoire.Le chiffrement ne sera pas effectué sur une base par demande.

J'étudie également l'utilisation d'un bus de messages, tel que NServiceBus.

Answer 4

Découvrez www.bluecoat.com est un proxy commercial qui PEUT en fait effectuer une interception https afin de bloquer des sites, restreindre le contenu, inspecter les virus et mettre en cache le contenu (GET).

Answer 5

Je pense que vous devriez simplement utiliser SSL et vous appuyer sur une bibliothèque client HTTP qui effectue la mise en cache (Ex :WinInet sous Windows).Il est difficile d'imaginer que les avantages de la mise en cache à l'échelle de l'entreprise valent la peine d'écrire un système de cryptage de sécurité personnalisé ou un certificat amusant sur le proxy.Pire encore, sur le schéma de chiffrement que vous mentionnez, effectuer des chiffrements asymétriques sur le corps de l'entité ressemble à un énorme succès de performance du côté serveur de votre application ;il y a une raison pour laquelle SSL utilise des chiffrements symétriques pour la charge utile réelle de la connexion.

Answer 6

Que diriez-vous de configurer un cache serveur sur le serveur d'applications derrière le composant qui crypte les réponses https ?Cela peut être utile si vous disposez d’une configuration de proxy inverse.

Je pense à quelque chose comme ça :

application server <---> Squid or Varnish (cache) <---> Apache (performs SSL encryption)