SSL は基本的に end-to-end な暗号プロトコルです。SSLでは
ブラウザがアクセスしたＷＥＢサーバの正当性を判断する手段として
基本的に
（１） サーバ証明書のデジタル署名（ＣＲＬの検証を含む）
（２） 署名認証局の正当性
（３） サーバ証明書の subject.cn に書かれたサーバのＤＮＳ名
この３つを持っています。

（１）（２）を偽造することは困難ですので、たとえば、攻撃者は
（３）を攻略するためにＤＮＳデータベースへの攻撃を行って
なりすましによりＷＥＢサーバを偽装したとします。
この場合、（２）の検査によりブラウザが警告を発します。
また、ＤＮＳデータベースへの攻撃では数件のＷＥＢサーバの
改ざんになり、攻撃対象がおのずと限られることもポイントです。

ところで、（３）のＤＮＳ名の検査で、「*」がワイルドカードとして
解釈されるようにブラウザのSSLが実装されています。
これは、たとえば、クラスタ構成の場合において使用されます。

しかし、このワイルドカード機能は、TLDに対しても適用されます。
つまり、subject.cn=* なサーバ証明書は全てのＤＮＳ名とマッチし、
その場合（３）の検査ではブラウザは警告を発しません。

ここで、エシュロンが出てきます。認証機関が秘密裏に
subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
さらに、そのサーバ証明書を大きなＩＸのルーターにインストールし、
すべての 443/tcp のパケットを横取りして、man-in-the-middleの攻撃を
するプログラムをインストールしたと「仮に」したら、どうでしょうか。

この場合、ブラウザは警告を発しませんので、利用者は
わざわざサーバ証明書の内容を検査しないでしょう。
利用者は man-in-the-middle攻撃がなされたことに気が付きません。

また、この攻撃は、ＩＸを通るすべての HTTPS 接続を対象とすることが
できます。そして、セッションＩＤを利用することで、「すべての 443/tcp」
でなく「指定された時間帯や確率で SSL ハンドシェイク」を横取りして再現性を低くし、
クライアント側からの疑惑を回避させることも可能です。

ここまでお読みになられた方なら、あなたがするべきことが何か
もうわかっていますよね。
さあ、あなたの接続先のサーバ証明書が subject.cn=* でないことを確認しましょう。