Webサイトに直接SSL接続していることを確認するにはどうすればよいですか？
私は、SSL接続があればMITM攻撃はないと考えていました。今は正しくないようです（この質問のコメントを参照してください 信頼できるネットワークで外部（信頼できない）Cookieを読み取ることはセキュリティの観点から大丈夫ですか？ ）
私はそれがどのように機能するか、そして各ブラウザが証明書をインストールする必要があるかどうかまだわかりませんが、LAN接続のプロキシがドメインをリダイレクトする（おそらく誤解している）か、代替の証明書を使用しているようです（証明書は必要ありません）ドメインと一致しますか？私はまだ混乱しています）。
実際のサイトに接続しているかどうかを確認することはできますか？プロキシが実際の証明書/キーを持たないドメインに対して有効な証明書を作成する方法を説明できれば、それも役に立ちます。 （これは2つの質問であることを知っていますが、どちらも1つの回答で説明できる可能性があります。）
目的のリモートサーバーと直接通信していることを確認するには、2つのポイントが必要です。
- サーバー証明書を信頼していることを確認する必要があります（通常は RFC 328 / RFC 528 によって行われます）。
- 到達しようとしているホスト名に対して証明書が発行されたことを確認する必要があります（ RFC 2818セクション3.1 および RFC 6125 ）。
そのリモートサーバーを構成するものは、サービスプロバイダー次第です。ここでは、複数の種類のプロキシサーバーを混乱させています。
HTTPS接続に使用できる通常のHTTPプロキシサーバーがあります。これは、HTTP
CONNECT動詞を使用して行われ、ブラウザとターゲットサーバー間のSSL/TLSトラフィック全体がプロキシサーバーによって中継されるだけです。 SSL/TLS接続に関する限り、これはIPルーティングとほぼ同じです。プロキシは何も認識しません。HTTPリバースプロキシサーバーがあります。これは リンク先の質問 で説明されています。ただし、要求が内部的に処理されるのはサービスプロバイダー次第です。
データベース接続の場合 と同じように、リクエストがHTTPワーカーノードによって処理される場合、サービスプロバイダーがSSL/TLSを使用して内部HTTPトラフィックを保護すると便利です。この場合、ロードバランサー/リバースプロキシのヘッドノードは、これらの内部Webサーバーのクライアントになります。
あなたが関係している限り、「本当のサイト」はヘッドノード/リバースプロキシです。
https://www.google.com/取得するリクエストを処理するためのボックスは1つ以上あります。あなたに関する限り、その背後にあるクラスター全体が（大きな）マシンです。MITMプロキシサーバー。一部のHTTPプロキシサーバーは、HTTPトラフィックを調べることができます（例 Squid + SSL Bump ）。そのために、彼らはその場で独自の認証局を使用して証明書を再生成します。マシンがこのローカルCAを信頼するように明示的に構成されていない限り、そのような証明書はブラウザーでの検証に失敗します（上記のステップ1）。
SSLプロキシを使用している場合は、プロキシを信頼するように特別に設定する必要があります。プロキシはワイルドカード証明書を使用するため、ブラウザはどのサイトの証明書も受け入れます。明らかに、完全に信頼していないSSLプロキシを使用することはvery悪い考えです。
通常のHTTPプロキシはSSLをプロキシできますが、データをコピーするだけで、変更やデコードはできません。サイトの通常の証明書は引き続き表示されます。
Webサイト側のセキュリティの低下が心配な場合は、それについて確認または実行できることは何もありません。彼らはあなたが彼らに送信することを選択したすべてのデータを解読する権利があります。彼らがそれを守らないなら、あなたはそれについて何もすることができません。 SSLエンドポイントとして内部でプロキシを使用している場合、復号化されたデータを内部ネットワーク上で安全に保つのは彼らの責任です。データが危険にさらされた場合にできることは何もありません。彼らは、復号化されたデータを必要に応じて処理できるはずです。
SSLは、2つのSSLエンドポイント間のデータのみを保護します。
プロキシが中間者として機能できる唯一の方法（クライアントとサーバーがSSL/TLSプロトコルの破損していないバージョンを正しく実装し、認証局がその仕事を正しく行うと想定）は、次の場合です。ブラウザはプロキシを信頼しています。これは、接続の開始時に、クライアントが、他のエンドポイントに、認識された認証局によって生成された有効な証明書があることを検証するためです。
クライアントとサーバーの間にプロキシがある場合があります。これは、たとえば、内部ホストとインターネットの間の直接接続がないことが多いエンタープライズネットワークでは一般的です。ただし、プロキシはバイトのやり取りしかできません。コンテンツを変更することはもちろん、知ることもできません。接続しているIPアドレスは認識できますが、参照しているURLは認識できません。
では、何がうまくいかないのでしょうか？お使いのブラウザがそのCAに署名する意思がある場合、proxy.example.comは、クライアントが接続しようとしているサーバーで、次にproxy.example.comはサーバーへの独自の接続を作成でき、クライアントの接続は可視的または透過的にプロキシにリダイレクトされます。その場合、プロキシは中間者です。
一部の企業ネットワークでは、企業独自の認証局を信頼するようにすべてのクライアントを構成し、すべてのSSL接続を書き換えるプロキシを課しています。クライアントは、企業のCAによって署名された証明書を持つすべてのサイトを確認します。すべての証明書には有効な署名があるため、日常の使用ではこれに気付かないでしょう。これが発生しているかどうかを確認する方法（ブラウザー自体が改ざんされておらず、証明書リストのみが改ざんされていると想定）は、特定の証明書に署名したユーザーを確認するか、信頼できる認証局のリストを参照することです。