Kann ein Proxyserver SSL-GETs zwischenspeichern? Wenn nicht, würde die Antwortkörperverschlüsselung ausreichen?

Question

Kann ein (|| any) Proxy-Server Inhalte zwischenspeichern, die von einem Client über HTTPS angefordert werden? Da der Proxy-Server den Querystring oder die HTTP-Header nicht sehen kann, denke ich, dass sie das nicht können.

Ich denke über eine Desktop-Anwendung nach, die von einer Reihe von Menschen hinter ihrem Unternehmens-Proxy ausgeführt wird. Diese Anwendung kann auf Dienste über das Internet zugreifen, und ich möchte die integrierte Internet-Caching-Infrastruktur für "Lesevorgänge" nutzen. Wenn die Caching-Proxy-Server den von SSL bereitgestellten Inhalt nicht zwischenspeichern können, wäre es einfach, den Inhalt einer Antwort zu verschlüsseln.

Ich erwäge, dass alle GET-Anforderungen, die wir abrufbar sein möchten, über http mit dem Körper, der mit asymmetrischer Verschlüsselung verschlüsselt ist, angefordert werden, wobei jeder Client den Entschlüsselungsschlüssel hat. Jedes Mal, wenn wir ein GET ausführen möchten, das nicht im Cache gespeichert werden kann, oder eine POST-Operation, wird es über SSL ausgeführt.

Answer 1

Nein, es ist nicht möglich, https direkt zu cachen. Die gesamte Kommunikation zwischen dem Client und dem Server ist verschlüsselt. Ein Proxy befindet sich zwischen dem Server und dem Client. Um ihn zwischenzuspeichern, müssen Sie in der Lage sein, ihn zu lesen, dh die Verschlüsselung zu entschlüsseln.

Sie können etwas tun, um es zwischenzuspeichern. Sie tun im Grunde die SSL auf Ihrem Proxy und abfangen der SSL an den Client gesendet. Grundsätzlich werden die Daten zwischen dem Client und Ihrem Proxy verschlüsselt, entschlüsselt, gelesen und zwischengespeichert und die Daten werden verschlüsselt und auf dem Server gesendet. Die Antwort vom Server wird ebenfalls entschlüsselt, gelesen und verschlüsselt. Ich bin mir nicht sicher, wie Sie dies auf einer großen Proxy-Software (wie Tintenfisch) tun, aber es ist möglich.

Das einzige Problem bei diesem Ansatz ist, dass der Proxy ein selbstsigniertes Zertifikat verwenden muss, um es mit dem Client zu verschlüsseln. Der Client wird feststellen können, dass ein Proxy in der Mitte die Daten gelesen hat, da das Zertifikat nicht von der ursprünglichen Site stammt.

Answer 2

Der Kommentar von Rory, dass der Proxy ein selbstsigniertes Zertifikat verwenden müsste, wenn nicht streng zutreffend.

Der Proxy könnte implementiert werden, um ein neues Zertifikat für jeden neuen SSL-Host zu generieren, mit dem es behandelt werden soll, und es mit einem gemeinsamen Stammzertifikat zu signieren. Im OP-Szenario einer korporativen Umgebung kann das Common Signing-Zertifikat eher einfach als eine vertrauenswürdige CA auf den Client-Rechnern installiert werden und diese "gefälschten" SSL-Zertifikate werden für den Verkehr, der weitergeleitet wird, gerne akzeptiert, da es keine Übereinstimmung des Host-Namens gibt.

In der Tat ist dies genau, wie Software wie die Charles Web Debugging Proxy für die Inspektion von SSL-Datenverkehr, ohne dass Sicherheitsfehler im Browser ermöglichen usw.

Answer 3

Ich glaube, Sie nur SSL und stützen sich auf einem HTTP-Client-Bibliothek verwenden soll, tut Caching (Bsp: WinInet auf Windows). Es ist schwer vorstellbar, dass die Vorteile von unternehmensweitem Caching die Mühe wert sind, ein benutzerdefiniertes Sicherheitsverschlüsselungsschema oder Zertifikatspaß auf dem Proxy zu schreiben. Schlimmer noch, bei dem von Ihnen erwähnten Verschlüsselungsschema klingt das Ausführen asymmetrischer Verschlüsselungen auf dem Entitätskörper wie ein großer Perf Treffer auf der Serverseite Ihrer Anwendung. Es gibt einen Grund, dass SSL symmetrische Chiffren für die tatsächliche Nutzlast der Verbindung verwendet.

Answer 4

Ich denke, Sie sollten nur SSL verwenden und stützen sich auf eine HTTP-Client-Bibliothek, die Zwischenspeichern (Beispiel: WinInet unter Windows). Es ist schwer vorstellbar, dass die Vorteile von unternehmensweitem Caching die Mühe wert sind, ein benutzerdefiniertes Sicherheitsverschlüsselungsschema oder Zertifikatspaß auf dem Proxy zu schreiben. Schlimmer noch, bei dem Verschlüsselungsschema, das Sie erwähnen, klingt das Ausführen asynchroner Chiffren im Entity-Body wie ein großer Perf-Treffer auf der Serverseite Ihrer Anwendung. Es gibt einen Grund, dass SSL symmetrische Chiffren für die tatsächliche Nutzlast der Verbindung verwendet.

Die betreffende Anwendung ist keine Browser-App, sondern eine Desktop-App, die Daten über das Internet zieht. Was passiert, ist, dass alle Instanzen der App das gleiche Stück ungefähr zur selben Zeit ziehen werden. Diese Daten müssen gesichert werden, aber ich hoffe, dass ich die Leistung verbessern kann, indem einige Instanzen der App eine zwischengespeicherte Version vom Unternehmens-Proxy-Server erhalten.

Die Datenblöcke sind klein, aber sie können häufig angefordert werden. Im Wesentlichen werden alle App-Instanzen die gleichen Daten gleichzeitig anfordern.

Der Daten/Nachrichtentext auf der Serverseite wird vorverschlüsselt und in einer verteilten In-Memory-Hash-Tabelle zwischengespeichert. Die Verschlüsselung wird nicht pro Anfrage durchgeführt.

Ich untersuche auch mit einem Nachrichtenbus, wie NServiceBus stattdessen.

Answer 5

Check out www.bluecoat.com ist ein kommerzielles Proxy, um tatsächlich tun können, https Interception Stellen zu blockieren, beschränken Inhalt inspizieren auf Viren und Cache-Inhalt (GETs)

Answer 6

Wie über einen Server einrichten Cache auf dem Anwendungsserver hinter der Komponente, die HTTPS-Antworten verschlüsselt? Dies kann nützlich sein, wenn Sie ein Reverse-Proxy-Setup haben.

Ich denke an so etwas wie diese:

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