SSLを復号化するコンテンツブロッカー

Question

ゲートウェイでSSL/HTTPS接続を復号化し、コンテンツに基づいて選択的にブロックするコンテンツブロッカーについて聞いたことがあります。

これに関するプライバシーの懸念は何ですか？ウェブサイトがこれをユーザーに起こさないようにする方法はありますか？（HSTSはそれを防ぎますか？）

Steffen Ullrich · Answer

これに関するプライバシーの懸念は何ですか？

SSLを中間者として傍受することによるコンテンツ分析は、クライアントが中間者のCAを信頼している場合にのみ実行できます。これは、このCAが新しい証明書を発行するためです。したがって、通常、システムが一元的に管理され、そのようなCAをインストールできる企業ネットワークでのみ透過的に機能します。また、ユーザーが警告を上書きした場合、またはソフトウェアが証明書を適切に検証しない場合にも機能します。

とにかくシステムを制御している信頼できる当事者（つまり雇用者など）によって傍受が行われる場合、SSL傍受による追加のプライバシーへの影響は、この信頼できる当事者がすでにシステムにアクセスしているため、おそらく問題が少ないでしょう。理論はまた、暗号化された接続の外側のプレーンデータを取得します。

ユーザーが検査に気づかず、機密データを傍受できないと信じて転送する場合、プライバシーへの影響はさらに深刻になります。これらがプライベートデータである場合、これは特に問題になります。しかし、機密性の高い個人データを処理するために会社が管理するシステムを使用することは、とにかく問題であり、SSL傍受に限定されません。

これらの合法的傍受とは別に、攻撃者に知られている信頼できる証明書を使用することによる違法な方法があります。質問の私の理解から、これはあなたが尋ねるものではありませんが、例についてはスーパーフィッシュアドウェアについての話を参照してください。

これがユーザーに起こらないようにする方法はありますか？

WebサイトがSSLインターセプトを検出するのは困難ですが、多くの場合は可能です。 SSLインターセプトは基本的にMITMプロキシでクライアントからのSSL接続を終了し、プロキシからサーバーへの別のSSL接続を作成するため、サーバーにヒットするTLSハンドシェイクは元のクライアントではなくMITMプロキシからのものになります。ハンドシェイクのフィンガープリントを作成し、一般的なブラウザやMITMソリューションと比較することで、SSLインターセプトがおそらく行われたかどうかを判断できます。詳細については、 HTTPSインターセプトのセキュリティへの影響の章TLS実装ヒューリスティックを参照してください。

ただし、実際には、TLSスタックのフィンガープリントを作成するために必要な情報はアプリケーションに公開されず、WebサーバーのTLSエンジン内に保持されます。したがって、Webアプリケーション自体は通常、TLS検査が行われたかどうかを判断できません。

サーバー側からのSSL傍受を阻止する別の方法は、クライアント証明書を要求することです。ほとんどのSSLインターセプトソリューションはこれらを処理できません。発行者のCAが信頼されていないため、サーバーが検出できるサーバー証明書と同じ方法でクライアント証明書を再発行する必要があります。残念ながら、これは、インストールする必要のあるすべてのクライアントに最初に証明書を発行する必要があることを意味します。とにかくクライアントの認証にこれらの証明書を使用したい場合は便利ですが、ほとんどの場合、ロジスティックと使いやすさの悪夢になります。

HSTSはそれを防ぎますか？

HSTSは、サイトにはHTTPSのみでアクセスする必要があると言っています。トラフィックが傍受されてもサイトはHTTPSでアクセスされるため、このヘッダーは役に立ちません。理論的には、 [〜＃〜] hpkp [〜＃〜] ヘッダーを使用するか、組み込みピンセットを使用して、証明書をピン留めする方が便利です。ただし、キーピン留めはSSLインターセプトが原因で証明書が変更されたかどうかを検出しますが、新しい証明書が信頼できるものとして明示的に追加されたCAによって発行された場合は、明示的に無効になります。これは、企業だけでなく多くのウイルス対策製品内でも行われているように、合法的なSSLインターセプトをサポートするために行われます。