プロキシサーバーはSSL GETをキャッシュできますか？もしそうでなければ、応答本体の暗号化で十分でしょうか？

Question

（|| any）プロキシサーバーは、httpsでクライアントから要求されたコンテンツをキャッシュできますか？プロキシサーバーがクエリ文字列やhttpヘッダーを見ることができないので、私は彼らができないと考えます。

私はデスクトップアプリケーションを検討しており、企業のプロキシの背後にある多くの人々によって実行されています。このアプリケーションはインターネット上のサービスにアクセスする可能性があります。私は、「読み取り」のための内蔵インターネットキャッシングインフラストラクチャを利用したいと考えています。キャッシングプロキシサーバーがSSL配信コンテンツをキャッシュできない場合、単純に応答のコンテンツを暗号化することは実行可能なオプションですか？

キャッシング可能にするすべてのGETリクエストは、httpを介して本体に非対称暗号化を使用して暗号化されており、各クライアントには解読キーがあります。キャッシュ可能でないGETやPOST操作を実行したい場合はいつでも、SSL経由で実行されます。

Answer 1

いいえ、httpsを直接キャッシュすることはできません。クライアントとサーバー間の通信はすべて暗号化されます。プロキシはサーバーとクライアントの間に置かれ、キャッシュするためには、暗号化を解読する必要があります。

キャッシュするには何かできます。基本的には、プロキシでSSLを行い、クライアントに送信されるSSLを傍受します。基本的に、データはクライアントとプロキシの間で暗号化され、復号化され、読み取られ、キャッシュされ、データは暗号化されてサーバーに送られます。サーバからの応答も同様に解読され、読み取られ、暗号化される。私はあなたが主要なプロキシソフトウェア（イカのような）でこれをどうやって行うのかは分かりませんが、可能です。

このアプローチの唯一の問題は、プロキシが自己署名証明書を使用してクライアントに暗号化する必要があることです。クライアントは、証明書が元のサイトからのものではないため、中央のプロキシがデータを読み取ったことを伝えることができます。

Answer 2

ロリのコメントは、厳密に真ではないにしても、プロキシが自己署名証明書を使用しなければならないというコメントです。

プロキシを実装して、新しいSSLホストごとに新しい証明書を生成し、共通のルート証明書で署名することができます。 OPのcorportate環境のシナリオでは、共通の署名証明書をクライアントマシンに信頼できるCAとして簡単にインストールすることができ、ホスト名の不一致がないため、プロキシされているトラフィックに対してこれらの "偽の" SSL証明書を喜んで受け入れます。

は、実際には、これは正確にどのようにソフトウェアなど、ブラウザにセキュリティエラーを発生させずにSSLトラフィックの検査を可能にCharles Web Debugging Proxyような

Answer 3

私はあなただけでSSLを使用して、HTTPクライアントライブラリに依存すべきだと思うことキャッシュします（例：WindowsではWinInet）。エンタープライズ全体のキャッシングの利点は、カスタムのセキュリティ暗号化スキームや証明書の面白さをプロキシに書き込む苦労があることは想像もつきません。さらに悪いことに、あなたが言及している暗号化スキームでは、エンティティ本体上で非対称暗号を実行することは、アプリケーションのサーバー側で膨大なパーセンテージのように聞こえます。 SSLが接続の実際のペイロードに対称暗号を使用する理由があります。

Answer 4

SSLを使用し、キャッシュするHTTPクライアントライブラリ（例：Windowsの場合はWinInet）に依存する必要があると思います。エンタープライズ全体のキャッシングの利点は、カスタムのセキュリティ暗号化スキームや証明書の面白さをプロキシに書き込むという苦労があることは想像もつきません。さらに悪いことに、あなたが言及している暗号化スキームでは、エンティティ本体の非同期暗号を実行すると、アプリケーションのサーバー側で大きなヒットとなります。 SSLが接続の実際のペイロードに対称暗号を使用する理由があります。

関連アプリケーションはブラウザアプリではなく、インターネット経由でデータをプルするデスクトップアプリです。何が起きるかは、アプリのすべてのインスタンスがほぼ同じ時間に同じ部分を引っ張るということです。このデータを保護する必要がありますが、私はアプリのいくつかのインスタンスを企業のプロキシサーバーからキャッシュされたバージョンにすることによってperfを増やしたいと考えています。

データチャンクは小さいですが、頻繁にリクエストされる可能性があります。基本的にすべてのアプリケーションインスタンスは、同じデータを同時に要求します。

サーバー側のデータ/メッセージ本文は、事前に暗号化され、分散メモリ内ハッシュテーブルにキャッシュされます。暗号化は、要求ごとに実行されません。

また、NServiceBusなどのメッセージバスを使用して調査しています。

Answer 5

チェックアウトwww.bluecoat.comは、実際には、コンテンツを制限、サイトをブロックするために、httpsの傍受を行うことができ、ウイルスやキャッシュの内容を検査商用プロキシです

Answer 6

を（取得）どのようにサーバーの設定についてhttpsレスポンスを暗号化するコンポーネントの背後にあるアプリケーションサーバーのキャッシュ？これは、リバースプロキシを設定している場合に便利です。

私はこのような何かを考えています：

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