Apache：SSL信頼チェーンを検証してMITM攻撃を防ぎますか？
特に企業環境では、SSL man-in-the-middle攻撃が思ったよりもはるかに一般的であることに気づきました。私は、透過的なSSLプロキシサーバーを配置しているいくつかの企業について聞いたことがあります。すべてのクライアントは、このプロキシの証明書を信頼するように構成されています。これは基本的に、雇用主がブラウザでポップアップする警告なしに、SSL暗号化トラフィックでさえも理論的に傍受できることを意味します。上記のように、クライアントには信頼できる証明書が付属しています。これは、使用されている証明書を手動で検証することによってのみ明らかにできます。
私には、雇用主が彼の優れた地位を利用して従業員のSSLトラフィックをスパイしているように見えます。私にとって、これはSSLの概念全体を信頼できないものにします。私はmitmproxyを使用して同様の設定を自分でテストし、クライアントと電子バンキングサーバー間の通信を読み取ることができました。これは誰にも明かすべきではない情報です。
したがって、私の質問はかなり単純です：サーバー側で信頼のチェーンを検証するにはどうすればよいですか？クライアントがサーバーの証明書と1つの信頼チェーンのみを使用していることを確認します。これはApacheのSSL構成で実現できるのでしょうか。これは、多くのアプリケーションに簡単に適用できるので便利です。これが不可能な場合、PHPでこれを行う方法を誰かが知っていますか？それとも他に提案はありますか？
この質問は、MITMのトピックが多くの質問で議論されている security.stackexchange.com に適していると思います。とにかく：
サーバー証明書の検証はクライアントでのみ行われ、クライアントで証明書を検証するポイントは正しいサーバーと通信していることを確認する必要があり、クライアントが（信頼できない）サーバーがクライアントのためにこの決定を行います。
SSLインターセプトの場合、サーバーから見たTLSクライアントはSSLインターセプトファイアウォール/ AVです。したがって、サーバー側の問題は、予期されたクライアント（ブラウザー）と通信しているか（ファイアウォール/ AV）通信していないかを検出することです。これを行う最も安全な方法は、クライアント証明書を使用してクライアントを認証することです。実際、クライアント認証が使用されている場合、SSLインターセプトは機能しません。つまり、MITMが予期したクライアント証明書を提供できないため、TLSハンドシェイクは失敗します。
ただし、クライアント証明書はほとんど使用されません。また、TLSハンドシェイクに失敗しても、クライアントはSSLインターセプトなしでサーバーと通信できますが、クライアントはサーバーとまったく通信できません。別の方法は、TLSハンドシェイクのフィンガープリントに基づいてTLSクライアントの種類、つまり暗号の種類と順序、特定の拡張の使用を検出するためにいくつかのヒューリスティックを使用することです... ClientHelloはほとんどの場合完全にサポートしていません。参照 HTTPSのサーバー側のman-in-the-middleの検出 またはセクションIII TLS実装ヒューリスティックス- HTTPSインターセプトのセキュリティへの影響 。
私には、雇用主が彼の優れた立場を利用して従業員のSSLトラフィックをスパイしているように見えます。私にとって、これはSSLの概念全体を信頼できないものにします
問題はSSLの概念にも技術的な実装にもありませんが、他の誰かが接続の1つのエンドポイントを完全に制御できます。つまり、ワークステーション。
それが実際のセキュリティリスクの原因です...
セキュリティの観点から見ると、通常の状況でMITMの成功を妨げているのは信頼の連鎖を断ち切るのは、あなたのワークステーションです。
サーバー側の信頼チェーンを検証するにはどうすればよいですか？
できません。これはクライアント側で行われます。
ユースケースに応じて、何ができるかは RFC 7469HTTP Public Key Pinning で、実際のSSLのリスト（ハッシュ）を含む追加のヘッダーをクライアントに送信します使用する証明書またはCA。
それは間違った方法です。サーバーは信頼の連鎖をチェックしません。それはクライアントです。したがって、会社がこの方法を使用する理由は、会社の環境を保護し、従業員が勤務時間中に何をしているのかを確認するためです。
あなた[〜＃〜]できました[〜＃〜]（種類）、しかし本当の質問はあなたが[〜＃〜] [〜＃〜]かどうかです。
ただし、Apache.confのフラグを変更するほど簡単ではありません。
また、「攻撃者」（例：雇用者）はクライアントコンピュータを制御するため、常に常に試行を失敗させる彼らが十分な労力を費やす傾向がある場合（明るい面で、あなたが非常に大きな魚でない限り、彼らはおそらく傾いていないでしょう、したがって、安全でない限り、ユーザーがあなたに接続できないという目標を達成します）
JavaScriptでTLSを再実装 し、クライアントが接続されている証明書がWebサイトの証明書であるかどうかを確認します。
if 幸運です 、ユーザー ブラウザを使用している可能性があります ここで、クライアント側のJavascriptは、使用されているリモート証明書に関する情報を取得できます（したがって、サーバーの証明書のハードコードされた値に対して簡単に確認できます） ）。
javaScriptを使用して カスタム暗号化 を実行できます。したがって、会社の悪質なTLS MiTMが成功した場合でも、データへのアクセス権は付与されません。もちろん、十分に関心がある場合は（そしてクライアントを制御しているため）、オンザフライで安全なJavaScriptを、送信中のすべての情報も記録（または変更）する独自のものに置き換えることができます。
また、TLS MiTMプロキシを使用する企業は通常、クライアントコンピューターも完全に制御するため、画面とキーロガーを簡単にインストールして、ユーザーが見るすべてのビデオを記録し、ユーザーが入力するすべてのキーストローク（およびマウスの動き）を記録することができます。ご覧のとおり、攻撃者[〜＃〜] [[〜＃〜]がクライアントである場合、攻撃者をだますための絶対的に安全な方法はありません。それは本当に彼らがどれだけ気になるかという質問です...そして、上記の解決策のいくつかはあなたにとって十分に良いかもしれません。