JavaScript / FlashはSSL接続を検証して「SSLインスペクション」を防止できますか？
Fiddler を介してSSL Webページがデバッグされているかどうか、または SSL Proxy を介してデバッグされているかどうかを確認したい。
だから一部の人々は尋ねるかもしれません
JavaScriptを使用してSSLを再検証するポイントは何ですか？
私の目標は、接続が this 回答で述べられているように、サードパーティの傍受の影響を受ける時期を知ることです。脆弱性は、パスワードが公開される可能性があり、ユーザーセッションも公開されることです。悪意のあるソフトウェアまたは企業のITポリシーがSSLの傍受と監視を指示している場合、これはすべて可能です。
SSL接続が傍受されている場合はどうすればよいですか？
アプリケーションの機密性に応じて、また2要素認証が使用されている場合、プログラムで接続をブロックしたり、Webサイトの特定の部分へのアクセスを制限したりできます。そのキオスクを使用することのセキュリティリスクを示すバナー通知を配置することもできます。 ...または、ユーザーがリスクを理解した上で、ユーザーに「例外」を追加することを許可する場合があります。
私の質問：
JavaScriptは、CAチェーンを含む現在のSSL証明書の詳細を確認できますか？
これに取り組む正しい方法は、証明書の発行者を見て、証明書チェーンの残りの部分を調べることだと思います。次のステップは、チェーン内の各証明書を一覧表示し、それらのCAのいずれかがルートCAが公的に信頼されているものと等しいかどうかを確認することです。ユーザーが自分のローカルコンピューターに追加した可能性がある証明書を具体的に除外したい。
Security.stackexchange.comの人々がこれに取り組む方法についてのアイデアを提供してくれることを期待しています。
JavaScriptが現在のSSL接続を検証できない場合、代替手段は何ですか？
これは純粋なJavaScriptソリューションでは可能かもしれないし、可能でないかもしれないので、これを達成することができるはずなので、この質問にFlashのタグを付け、JavaScriptに応答を返します。
誰かがJava MEの経験がある場合は、これが可能かどうかを述べてください。他の広く展開されているプラグインについても同様です。
関連技術のソースコードを高く評価しています。
あなたは代替案について尋ねました。率直に言って、これは難しい問題です。誰かがあなたのSSLセッションで介入者を演じていて、ユーザーがそれに気づかなかったり、それを続行することを許可していない場合、あなたは本当に厳しい状況にいます。ただし、JavaScriptがこのHTTPS接続で提供されているサーバーの証明書を確認できない場合は、検討できるいくつかの代替案についてブレインストーミングを行います。これらのアイデアはどちらも、せいぜい完璧からはほど遠いですが、役立つ場合に備えて私はそれらを渡します。
アイデア1.ブラウザーを信頼しないでください。 1つの代替手段として、2要素認証と確認を使用して、ブラウザーセッションに100％依存しないようにする方法があります。たとえば、オンラインバンキングアプリケーションの場合、ユーザーが機密性の高い操作を実行すると、サーバーはユーザーの携帯電話にSMSメッセージを送信してトランザクション情報をリストします（ "$ 100をAT＆Tに支払う？このPIN：2781 "）を入力し、ユーザーに承認を得て応答するか、PINをブラウザセッションに入力するように要求します。ただし、これはユーザーにとって煩わしくて不便です。
アイデア2. RAWソケット。探索できる別の可能性：FlashまたはJavaを使用して、一部のRAWソケットを開くTCPポートこれがプロキシによって傍受/中間者されない場合は、プロキシを検出するためのオプションがいくつかあります。1つの簡単な検出戦略：サーバーが、 rawソケットは、このHTTPS接続に関連付けられたソースIPアドレスとは異なります（ただし、これは誤ったアラームを生成する可能性があります...）また、Flashなしでプロキシをバイパスすることも、Java ftp：//などの、ブラウザは認識するがプロキシはインターセプトしない他のプロトコルハンドラ。
いいえ-DOMは現在のページのSSL証明書へのアクセスを公開していません。アクセスできるのはlocation.protocolこれにより、HTTPS経由で配信されているかどうかを確認できます
Webブラウザーのコンテキストでは、2種類のSSL接続があります。ブラウザーが管理するものと、コード（Java、JavaScriptなど）がそれ自体を管理するものです。
第1の種類の場合、ブラウザーはサーバー証明書チェーンの詳細を提供しないため、ほとんどの場合不運です。ブラウザーは「これはすべておかしいです」と通知しますが、ブラウザーが誤って導かれていないことを確認する方法はありません。
2番目の種類についても、これはコードがサーバーへの接続を開き、完全なSSLハンドシェイク自体を実行することを意味します。もちろん、その時点でコードはseeサーバーからの証明書チェーンであり、「直接信頼」（クライアントコードはすでに「知っている」）を含む任意の方法でそれを検証できます。サーバーの公開鍵）、または少なくとも特定の予想されるルートCAを使用します。このアプローチには、コストをかけて対処できるいくつかの実際的な問題があります。
- 完全なSSL実装を埋め込む必要があります。これは必ずしも巨大ではありませんが、注意が必要です。クライアントとサーバーの両方のコードを制御するため、サイズを小さくすることができます。そのため、使用する予定の正確なプロトコルバージョンとアルゴリズムに集中できます。
- JITコンパイラ なしでインタプリタを使用すると、パフォーマンスが問題になる可能性があります。
- これは、クライアントコードが変更されていないことを確認できる場合にのみ意味があります。 JavaScriptコード自体がダウンロードされたSSL接続についてJavascriptで何かをチェックしても意味がありません。 Man-in-the-Middle は、JavaScriptコードを変更してチェックを削除できます。
- 一部のネットワークでは、特にプロキシに関して、クライアントコードからサーバーへの未加工の接続を開くのが難しい場合があります。
パフォーマンスのために、 Java ME を使用する必要があります。ほとんどのJava ME実装は基本的なインタープリターを使用するため、これはJavascriptまたはFlashよりも速くありませんexcept Java ME標準ライブラリにJava.math.BigIntegerが含まれている通常はネイティブコードとして実装されるため、非常に高速な任意の大きな整数の演算。これは、SSLハンドシェイクに関連するRSAまたはDHの計算に必要です。
Java MEアプレットはsignedである可能性があるため、正しいコードがクライアントで実行されていることを確認するために、再びJava MEが助けになる可能性があります。 Fiddlerを実行できる攻撃者は、ローカルのトラストストアに自分の偽のCAを挿入できる攻撃者であるため、これは実際には問題を解決しません。同じ攻撃者が、自分の偽のCAを他のローカルトラストストア（アプレット署名証明書を検証するためのもの）に追加する可能性があります。しかし、これは素晴らしいひねりを加えます：ifクライアント接続がインターセプトされ、その後、実際のフォレンジック検査により、キャッシュされた署名付きアプレットが明らかになる場合があり、アプレットが偽物であることが明らかになり、あなたは、サーバーのメンテナーとして、悪者ではありません。認証からそのような法的保護を受けることはできませんが、署名は役立ちます。もちろん、これは状況に大きく依存します。
プロキシの問題は深刻です。多くのローカルネットワーク、特に企業は、次のことを行いません [〜＃〜] nat [〜＃〜] ;代わりに、すべての外部トラフィックはいくつかのプロキシを経由する必要があります。ユーザーのWebブラウザーはプロキシの場所を認識していますが、JavaScriptまたはJavaコードは認識していません。さらに、プロキシは認証を必要とする場合があり、ローカルセッションの資格情報にリンクされる場合があります。ここでも、ブラウザはコードではなく透過的に通過します。この種の問題に対処するために、フレームワークによって提供されるHTTPコードに渡されるHTTPリクエストを介してSSLトラフィックをトンネリングすることを想像してみてください。これは可能ですが（私は10年ほど前にそれを行いました）、簡単ではありません。
しかし、これはすべて悪臭がします。あなたが話しているような種類のMitM攻撃は、攻撃者がX.509信頼モデル（たとえば、自身の不正なCAを信頼できるCAとしてクライアントのシステムにインストールする。 OSソフトウェアの更新alsoはこの信頼モデルを使用しているため、その時点では、クライアントシステムは少なくとも攻撃者の完全な制御下にあると想定する必要があります。ある意味で、フィドラーは悪人が使用するものではありません。なぜなら、フィドラーが動作することを可能にする条件は、前述の悪人がはるかに大きく、より完全なスケールの悪を実行することも可能にするからです。
要約すると、JavaScriptまたはJava MEクライアント側コードからのSSL接続の確認は、リビングルームのテーブルにある素敵なメモのように役に立たず、潜在的な強盗に警察に電話をかけるように要求します。
（ただし、カナダで働く可能性があります。）
脅威モデル（SSLをプロキシするがチェックコードを改ざんしようとしないプロキシを検出する）がある場合、コンテンツをチェックサムし、サーバーによって計算されたハードコードされたチェックサムと比較するすべてのページにJavaScriptコードを埋め込むことができます。クライアントに到達したページがサーバーが送信したページと一致するかどうかを判断します。しかし、おそらくここには重要な技術的課題がいくつかあると思いますし、それがあなたを大いに買うとは思いません（悪意のあるプロキシが常にチェックコードを削除する可能性があることに注意してください）。
スイス について学び、ワシントン大学の "web tripwires" に興味があるかもしれません。
これは現在、どのブラウザでも（私が知る限り）サポートされていません。
Firefoxの未解決のバグ がこれに何らかのサポートを導入していますが、解決されていません。
EmscriptenでコンパイルされたOpenSSL を使用することにより、JavaScriptでこれをサポートできますが、そのリンクは骨を提供するだけであり、アプリへのJSリンケージを構築する必要があります。
Adobe AlchemyでコンパイルされたOpenSSLを使用して（検索して）、Flashでこれをサポートできますが、新しいFlashエンジンとOpenSSLで作業をやり直す必要があります。
Silverlightと.NETに関しては、通常、ServicePointManagerを使用して呼び出しをインターセプトし、SSL証明書を検証しますが、SL4ではそれができないようです。
これについて Microsoft Connect に投稿がありますが、これは仕様によるものです。この機能をSilverlight開発者が利用できるようにすべきだと思う人はだれでも、そこに返信を投稿することをお勧めします。