組織でのSSL傍受に関連するリスクは何ですか？
SSLインターセプターがセキュリティ上の理由で組織にインストールされており、中間CAからの証明書がすべてのドメインマシンにインストールされている場合、このセットアップではどのようなリスクが発生しますか？
リスクは、指定された警備員に建物のすべてのドアを開く鍵を与えることによって暗示されるものとほぼ同じです。
警備員は貴重なターゲットになります。攻撃者は、金色の鍵を手に入れるために、警備員を強奪したり賄賂を贈ったりしたいと思うでしょう。
すべてを網羅しているため、キーはすべての手順とセキュリティ層をバイパスします。潜在的な攻撃者がすべてのドアを開く鍵を持っている場合、建物の部分を互いに分離することはできません。
一部のセキュリティガードの手に開いたすべてのキーが存在するだけの知識は、ユーザーを非常に不信にさせます。人間のユーザーはプライバシーを重視する傾向があり、誰かが日常的に自分のデスクとロッカーを開いて内容を検査するという考えは好きではありません。
重要な類推を超えて、SSLインターセプトを使用すると（組織固有のCAを使用して MitM攻撃 オンザフライで）、次のような特定の影響があります。
デスクトップシステムでは、傍受を行うには、「信頼できるストア」に特別なCA証明書をインストールする必要があります。このインストールは、新しいOSがインストールされるたびに再度実行する必要があります。ユーザーは自分で削除できます。一部のWebブラウザー（特にFirefox）は、OSトラストストアを無視して独自のものを使用します。したがって、ここには破損の余地が十分にあります。これは、OSの構成とソフトウェアのインストールをロックダウンすることである程度修正できますが、ロックダウンするほど、ユーザーの満足度は低下します。
OSトラストストアは、単なるSSL以外の用途に使用できます。たとえば、ソフトウェアの更新やドライバーの署名を確認するために使用できます。したがって、組織CAの秘密鍵を盗むことに成功した攻撃者は、SSL接続を傍受するだけでなく、ネットワーク全体で広範囲にわたる力を獲得する可能性があります（すでに多くのことです）。
したがって、組織CAの秘密鍵は機密性が高くなりますが、特別なCAは構造上、必要があるため、その場で偽のSSLサーバー証明書を発行します。したがって、「インターネットに近い」サーバー上でオンラインでなければなりません。
このようなMitMインターセプトは、証明書ベースのクライアント認証を破壊します。
https://Webサイトがクライアント証明書を使用することはほとんどありませんが、一部の銀行が（少なくとも実験的な展開の一環として）顧客を認証するために使用しているのを見てきました。多くの管轄区域では、雇用主によるユーザーの通信の自動検査は合法ですが、通常は従業員の契約書にある明示的な通知のような、いくつかの条件に従います。そのような傍受に関連する法的リスクが存在する可能性があります（手紙を読んだり、電話をタップしたり、オフィスにビデオカメラを設置したりするのと同様）。法務部を迂回することを強くお勧めします。
したがって、組織のSSLインターセプトにより、SSLでダウンロードされたコンテンツの検査が可能になる（したがって、ウイルス対策やその他のフィルターをプロキシーに適用できる）一方で、新しい脆弱性も開かれていると言えます。したがって、全体的なセキュリティ状況は、このようなシステムのインストールによって悪化する可能性があります。
ルートCAまたは中間CAの侵害は、商用CAの侵害よりも簡単になるため、従業員がインターネットに直接接続されている場合に、HTTPS接続で検出できない中間者攻撃をユーザーにマウントするコストを削減します（たとえば、コーヒーショップのwifi）。これは非常に大きな脅威だとは思いません。
悪意のある雇用者/ sysadmin /侵害されたプロキシサーバーからのユーザーへのリスクは明らかに増加しています。攻撃者は個人のソーシャルネットワーキング/電子メール/銀行の資格情報をすべて傍受して盗むことができます。
運用上、これにより、プロキシサーバーの信頼済みストアにないルート証明書の問題が発生しました。これは、ネットワーク管理者がアプライアンスのパッチに追いついていない場合、またはアプライアンスが古くなっている場合に一般的です（Bluecoatを参照）。
HTTPSプロキシを使用するサーバーには、特にプロキシがロードバランサーなどのネットワーク機器を誤ってプロキシする場合、多くの問題があることに気付きました。このため、サーバーのプロキシを無効にしました。
最後に、CAインフラストラクチャを内部的に展開し、高可用性を実現する際に問題が発生する可能性があります。 CRLは（HTTPSではなく）HTTP経由で使用可能である必要があり、OCSPは適切に構成する必要があります。
CRLが頻繁に更新されない場合（next update）一部の内部クライアントは、証明書が取り消されたことを証明できないという前提に基づいて、証明書を拒否することができます。
最後に、ルート証明書は、該当するすべてのローカルストアにある必要があります。たとえば、Java、Firefox、IE/Windowsにはすべて、更新する必要のあるさまざまなストアがあります。証明書の展開は、GPOを介した展開ほど簡単ではありません。
また、このルート証明書の展開では、集中管理されていない（BYOD）Mac、iPhone、モバイルデバイスなどのAD以外のデバイスも検討してください。
最終行
一元化されたSSLプロキシの展開に伴う複雑さにより、セキュリティポリシーに予期しない、または維持されないホールが生じる可能性があります。
セキュリティポリシーに適合しない互換性のないコンポーネントを維持、免除、または禁止するには、包括的なソリューションを導入する必要があります。これは可能な限りシンプルにする必要があります。
e.g. Exempt servers, and mobile devices on wifi. Everything on corpnet as a workstation must be proxied.
私は昨年クライアントのためにこれを行いましたが、適切なリスク分析を実行すると、プロキシサーバーの侵害またはルート証明書の損失は確かに技術的なリスクですが、他のリスクは最終的な評価においてより高い要素であることがわかります。
注：これは場所によって異なります。たとえばヨーロッパ以外では、プライバシーリスクが適用されない場合があります。
- プライバシー-あなたの会社がインターネットの私的使用を許可している場合、従業員がそのようなことだけから保護されていると想定できるパッケージを検査すると、あらゆる種類のトラブルに遭遇する可能性があります。
- 責任-SSLが役割を果たす場所で何かが発生した場合。従業員がオンラインバンキングで取引を行い、攻撃が成功した場合、SSLセッションを解読すると、すぐに攻撃の域に入ることができます。今、あなたは無実であることを証明する必要があります。 SSLインターセプトがなければ、誰かがあなたが有罪であることを証明する必要があります。
- 法務-法務部に確認してください。電気通信とその傍受については多くの法律があり、それらの一部はSSL傍受に適用される場合があります。これは詳細に依存する可能性があり、法的専門家だけがそれに答えることができます。
- 例外-すべての会社には、例外を主張できる人がいます。ユニオンオフィス、データプライバシー担当者、トップレベルの幹部、合併＆買収チームのメンバー、医師などが考えられます-通信が許可されている人が常にいるため、合法的に傍受できるかどうか慎重に確認する必要があります苦痛の世界に終わることなくそれらを。
- 攻撃面-プロキシサーバーがハッキングされるリスクについて他の人がすでに回答しています。これらのSSLプロキシの多くが非常に不適切にセキュリティ保護されていることを示す多くのテストと調査があることを付け加えておきます。 2004年から2016年までの詳細なレポートを見つけました。当面の間、どのベンダーが問題を修正したのかわからないため、リンクを設定したくありませんが、簡単に検索すると明らかになります。
- 証明書の取り扱い-すでに説明しました。 PKIを実行している場合、または適切な証明書とキー管理プロセスが整っている場合は、これで問題ありません。そうしないと、これが問題の潜在的な原因になります。
（1）この文脈での「許可」とは、本質的にそれを厳密に禁止しないすべてのものです。資格付きで許可する場合（休憩時間中は、仕事に影響を与えない限り、緊急の場合のみ）、許可します。私はこれを私の国の最高裁判所の裁判官と話しました、そして彼は彼らがこれが厳密にバイナリであることを彼らが見ると非常に明白でした。
私が見ることができる主なリスクは、プロキシサーバー自体の侵害です。これにより、攻撃者はそのシステムを通過するすべてのトラフィックを解読できます。
このセットアップは一部の認証メカニズムと互換性がないという事実があります。SSLクライアント証明書認証に依存するシステムは機能しません。
より広い問題は、実装自体の品質です。適切な失効メカニズムとすべてのCA要素に対する厳格なセキュリティを備えた、プライベートCAと中間CAを使用する必要があります。設計段階で不適切な処理を行うと、SSLトラフィックよりもはるかに多くのことが残ります。