Apache：SSL信頼チェーンを検証してMITM攻撃を防止しますか？

11

SSLの中間者攻撃は、特に企業環境では、思ったよりもはるかに一般的であることに気付きました。透過的なSSLプロキシサーバーを設置しているいくつかの企業について聞いたことがあります。すべてのクライアントは、このプロキシの証明書を信頼するように構成されています。これは基本的に、雇用主は理論的には、SSLで暗号化されたトラフィックでさえ、ブラウザに警告が表示されることなく傍受できることを意味します。前述のように、クライアントには信頼できる証明書が付属しています。これは、使用されている証明書を手動で検証することによってのみ明らかにできます。

私には、雇用主が彼の優れた地位を利用して従業員のSSLトラフィックをスパイしているように見えます。私にとって、これはSSLの概念全体を信頼できないものにします。私はmitmproxyを使用して同様のセットアップを自分でテストし、クライアントと電子バンキングサーバー間の通信を読み取ることができました。これは、誰にも明かされるべきではない情報です。

したがって、私の質問はかなり単純です：サーバー側で信頼チェーンを検証するにはどうすればよいですか？クライアントがサーバーの証明書と1つの信頼チェーンのみを使用するようにします。これは、ApacheのSSL構成で実現できるのでしょうか？これは、多くのアプリケーションに簡単に適用できるため便利です。これが不可能な場合、誰かがPHPでこれを行う方法を知っていますか？または、他に提案はありますか？

— エルロン79
ソース

1

雇用主が従業員のトラフィックを見ても問題ありません。雇用主のリソース（PC、ネットワーク接続など）を使用していますが、これらはあなたのものではありません。そして、あなたがあなたの銀行口座に送信するデータを事業者が見ることができるのではないかと心配するなら、職場ではなく自宅でやりましょう。また、企業のセキュリティポリシーに違反する試みは、あなたに対する裁判所の対象となる場合があります。

— -Crypt32

2

多くの欧州企業では、オフィス機器の私的使用は雇用契約で規制されています。私が働いている会社では、個人的にサーフィンをするかもしれませんが、それは問題ではありません。ポルノ、ファイル共有などの例外があります。同時に、企業が従業員をスパイすることを禁止する法律があります。したがって、私や他の多くの人にとって、多くの企業でプライベートサーフィンが許可されている間、雇用主が従業員のトラフィックを傍受することは明らかに禁じられているため、これは問題ではありません。

— エルロン79

2

ほとんどの（私の経験では）米国政府が所有するワークステーションには、ログインごとに次の2つの通知が含まれます。「このISを使用した通信、またはこのISに保存されたデータは非公開であり、定期的な監視、傍受、検索の対象となり、開示または使用される可能性がありますこのISには、USGの利益を保護するためのセキュリティ対策（認証やアクセス制御など）が含まれています。個人の利益やプライバシーのためではありません。」これらのシステムの使用は、多くの場合、同じことを規定する署名済みの契約によってカバーされます。重要な点は、システムの所有者があなたから身を守ることです。

— ランドール

これは、米国とヨーロッパの多くの違いの1つです。上記の@Randallという用語は、ほとんどのヨーロッパ諸国では違法です。

— エルロン79

私が引用した用語は不完全であり、他の用語は明示的に監視されないアクティビティをリストしています。欧州の雇用主がそのような前提条件をコンピューターの使用条件にすることはできないという言及はありません（私はヨーロッパで事業を行っており、そのような監視プロセスをセットアップしていますが、ビジネスをしていない部門で働いていますがヨーロッパ）、ただし、明示的かつ透明である限り、そのような用語は違法ではないことを示唆する参照を見つけることができます。

— ランドール

9

この質問は、多くの質問でMITMのトピックが議論されているsecurity.stackexchange.comにより適していると思います。とにかく：

サーバー証明書の検証はクライアントでのみ行われ、クライアントで証明書を検証するポイントはクライアントが正しいサーバーと通信しており、信頼できないことを確認する必要があるため、何らかの方法でサーバーに移動することはできません（信頼されていない）サーバーがクライアントのためにこの決定を行います。

SSLインターセプトの場合、サーバーから見たTLSクライアントは、SSLインターセプトファイアウォール/ AVです。したがって、サーバー側の問題は、予想されるクライアント（ブラウザー）と通信しているかどうか（ファイアウォール/ AV）を検出することです。これを行う最も安全な方法は、クライアント証明書を使用してクライアントを認証することです。実際、クライアント認証が使用されるとSSLインターセプトは機能しません。つまり、MITMが期待されるクライアント証明書を提供できないため、TLSハンドシェイクは失敗します。

のみ、クライアント証明書はほとんど使用されません。また、TLSハンドシェイクの失敗は、クライアントがSSLインターセプトなしでサーバーと通信できることを意味しませんが、クライアントはサーバーとまったく通信できないことを意味します。別の方法は、TLSハンドシェイクのフィンガープリントに基づいてTLSクライアントの種類、つまり暗号の種類と順序、特定の拡張機能の使用を検出するためのヒューリスティックを使用することです... SSLインターセプティングプロキシは理論的には元のClientHelloはほとんどありません。参照してください検出のman-in-the-middle HTTPS用のサーバ側でまたはセクションIII TLSの実装ヒューリスティックでHTTPS傍受のセキュリティへの影響。

— ステフェン・ウルリッヒ
ソース

14

私には、雇用主が彼の優れた地位を利用して従業員のSSLトラフィックをスパイしているように見えます。私にとって、これはSSLの概念全体を信頼できないものにします

問題はSSLの概念や技術的な実装ではなく、接続のエンドポイント、つまりワークステーションを他の誰かが完全に制御できるということです。
それが実際のセキュリティリスクの根源です...

セキュリティの観点から見ると、通常の状況ではMITMの成功を妨げるのは、信頼の連鎖を破るのはワークステーションです。

サーバー側で信頼チェーンを検証するにはどうすればよいですか？

できません。これはクライアント側で行われます。

使用事例に応じて、RFC 7469 HTTP公開キーピニングを使用して、実際のSSL証明書または使用するCAのリスト（ハッシュ）を含む追加のヘッダーをクライアントに送信します。

— HBruijn
ソース

4

HPKPは、証明書が明示的に追加されたCAによって署名されている場合、ブラウザーによって無視されるため、役に立ちません。これは、信頼できる当事者、つまり企業のファイアウォールまたはローカルデスクトップAVによるSSLインターセプトを許可するために特に行われます（多くの場合、SSLインターセプトを行います）。

— ステフェンUllrich

2

RFCの§2.6：「ローカルポリシーに従って、一部のホストのピン検証を無効にすることは許容されます。たとえば、UAは、検証済みの証明書チェーンがUA（または基盤となるプラットフォーム）に組み込まれたトラストアンカーではなく、ユーザー定義のトラストアンカー。」

— -HBruijn

3

それは間違った方法です。サーバーは信頼チェーンをチェックしません。クライアントです。したがって、会社がこの方法を使用する理由は、会社の環境を保護し、従業員が勤務時間に何をしているかを確認するためです。

— beli3ver
ソース

ええ、はい、おそらくサーバー側だけではこれを防ぐことができないことを知っています。ただし、一部のクライアント側JSもだまされる可能性があります。ところで、従業員のスパイはほとんどのヨーロッパ諸国で違法です。ウェブサイト運営者として、クライアントがだまされないようにしたいので、信頼のチェーンを安全な方法で検証できる方法があるかどうか疑問に思います。

— エルロン79

多分それは許可されていません。しかし、ほとんどの企業は従業員をスパイせず、会社のネットワークをセキュリティで保護するだけであり、ほとんどのWebフィルターまたはスキャナーはこれを確認するためにSSL接続を切断する必要があります。したがって、これは中間攻撃の合法的な男です

— -beli3ver

私はあなたの主張を理解しています。ただし、この質問は、HTTPS接続がエンドツーエンドで暗号化されるようにする方法に関するものです。上で説明した設定は企業環境では非常に一般的ですが、同じ種類の攻撃は、boy深い少年がガールフレンドをスパイしたり、家主がテナントのトラフィックを傍受したりするために使用される可能性があります。これらの人々はまだ証明書をインストールするようにだまされる必要がありますが、それは簡単な部分です。ただし、これは違法です。HTTPS接続が実際に暗号化されたe2eであることを確認できる方法があるかどうかはまだ疑問です。

— エルロン79

3

それは可能ではありません。クライアントでルート証明書が変更された場合、それを確認する方法はありません。サーバーはチェックを行わず、クライアントがチェックを行います。

— beli3ver

3

あなたは（のような）COULDですが、本当の問題はあなたがSHOULDかどうかです。

ただし、apache.confのフラグを変更するほど簡単ではないことに注意してください。

また、「攻撃者」（例：雇用主）がクライアントコンピューターを制御するため、十分な努力を払う傾向がある場合は常に攻撃を阻止することができます（明るい面では、非常に大きな魚でない限り、おそらくそうではありません）傾斜しているので、安全でない限りユーザーがあなたに接続できないという目標を達成します））

javascriptでTLSを再実装し、クライアントが接続されている証明書がWebサイトの証明書である場合、そこでチェックを行うことができます。
運が良ければ、ユーザーはブラウザを使用している可能性があり、クライアント側のJavaScriptは使用されているリモート証明書に関する情報を取得できます（したがって、サーバーの証明書のハードコードされた値に対して簡単に検証できます）。
JavaScriptを使用してカスタム暗号化を実行できます。そのため、会社の悪意のあるTLS MiTMが成功した場合でも、データへのアクセスは許可されません。もちろん、（クライアントを制御するので）十分に関心がある場合、彼らは安全なjavascriptを転送中のすべての情報も記録（または変更）する独自のJavaScriptに即座に置き換えることができます。

また、TLS MiTMプロキシを使用する企業は通常、クライアントコンピューターを完全に制御するため、画面とキーロガーを簡単にインストールして、ユーザーが見るすべてのビデオを記録し、ユーザーが入力するすべてのキーストローク（およびマウスの動き）を記録できます。あなたが見ることができるように、攻撃者がするとき、ISクライアントは、彼を欺くために何も絶対に安全な方法はありません。それは本当に彼らがどれだけ気にするのかという質問です...そして、上記の解決策のいくつかはあなたにとって十分かもしれません。

— マティヤ・ナリス
ソース

「TLSをJavaScriptで再実装できます」どうやって？どこ？

— curiousguy

それをクリックし、それは別の質問と回答にあなたを導き、そして最後になります-リンクですqoutedテキストがあること@curiousguy digitalbazaar /フォージプロジェクト

— マティヤNalis

それで、それはいつ使用可能ですか？どの目的のために？

— curiousguy

特にこのServerfaultの質問で尋ねられた目的のために、他の多くのことの中でも@curiousguy。クライアント上で独自のJS TLSを実行している場合、そのクライアントJSは、クライアントが接続されているTLSサーバー（およびその公開キー）を正確に認識します。次に、その公開キーを承認済みサーバーの公開キー（JSにハードコーディングされている）と比較し、それらが同じかどうかを確認できます。同じでない場合、接続はMiTMによってハイジャックされています。

— マティヤナリス