(これは、Security.SEに関するこの質問と非常によく似ています。)
クライアントとして、証明書をチェックすることにより、SSL / TLS接続がMITMプロキシ(Fiddlerまたはその他)によって傍受されていないことを確認できます。これが、サーバーを認証するための証明書を持つことの全体的な目的です。
証明書を検証することを選択したため、Fiddlerにトラフィックの表示を許可することしかできませんでした。同様に、MITMプロキシサーバー(主に企業環境で使用される)は、クライアントマシンにCA証明書をインストールする必要があります。これが発生する環境では、クライアントは実際には使用するマシンを制御していません。クライアントは、そのプロキシを制御する人に管理を委任します。
最終的には、(a)SSL / TLSが使用され、(b)正しく使用されていることを確認するのはクライアントの唯一の責任です(最初に通信する予定のマシンに対して信頼できる証明書を使用)。(詳細については、Webmasters.SEのこの長い説明を参照してください。)
ブラウザでSSLがプロキシなどを介して傍受されていないことを確認するにはどうすればよいですか?
警告を無視しないようにユーザーに伝えます。一致するCA証明書がマシンにインストールされている企業プロキシがある場合、原則として、証明書の詳細を確認できます。使用しているマシンを信頼できない場合は、傍受されないようにするネットワークから、独自のマシンを使用する必要があります。
残念ながら、モバイルデバイスはこれらの詳細をチェックするにはかなり貧弱ですが、サーバーとしてできることはあまりありません。
クライアントがサーバーが送信したものと同じサーバー証明書を受信したかどうかを確認する1つの方法は、クライアント証明書認証を要求することです。これにより、クライアントは独自の秘密鍵を使用してハンドシェイク(サーバー証明書を含む)に署名し、サーバーは次のことができます。署名が期待するものと一致するかどうかを確認します。これには、クライアント証明書を処理するためにもう少しインフラストラクチャが必要です(そして、ユーザーにそれらの使用方法を示す必要があります)。
編集:あなたのコメントについて。
これはsslの欠陥であり、誰かが監視しているかどうかを確認する方法がなく、その目的全体を損なうことになります。
実際にはそうではありませんが、実際の状況であっても、最終的にはユーザーが何と誰と話しているのかを確認する責任があります。代理人による投票のための適切なフォームに記入し、この投票権を誰かに委任する場合、または郵便局から小包を受け取るためにIDと配達票を誰かに渡す場合は、あなたがその人を信頼しなさい。あなたが誰かにあなたの銀行のパスワードを与え、彼らがあなたのためにあなたの銀行に電話をかけた場合、あなたの銀行はそれがあなたであるかどうかを知る方法がありません。
ユーザーだけが適切なサーバーと通信していることを確認できます。そうでない場合、正規のサーバーはユーザーと連絡を取り合っていないため、何か問題が発生していることを警告することはできません。
ユーザーが何をするかを制御できないため、ユーザーにサーバーから適切なサーバーとの通信を強制することはできません。彼らは彼らが望む誰にでも彼らのパスワードを与えることができました、あなたは知らないでしょう。(せいぜいそうしないように彼らに教えることができます。)
あなたができることは、あなたのサーバーがあなたのユーザーではない誰かにデータを与えるのを防ぐことです。実際の例えに従って、これは、その人が存在することを主張するメカニズムを使用して行うことができます(他の人のIDを持って来たとしても、他の人のために行動することを許可しません)。これは、クライアント証明書を使用する場合にSSL / TLSを使用して実行できます。認証できるのは秘密鍵の所有者のみであり、中間者は認証できません。(もちろん、実用的な観点から、ユーザーは自分の秘密鍵を与えないようにする必要があります。)