httpsでWebサービスに接続します。ユーザーが特定の操作を実行すると、これがバックグラウンドでトリガーされます。httpsサーバからサーバ通信への途中の攻撃を防ぐ方法
リンクはサーバーとWebサービスの間にありますが、ユーザーはそれを認識しません。
証明書を見ることができないので、エラーが発生します。これはサーバーとサーバーの関係であり、どのようにして2つのサーバー間の中間攻撃で人を緩和できますか？証明書が失効した場合、コード内で何が起こりますか？
私たちはASP.NETを使用しています。
その - あなたは
ServicePointManager.ServerCertificateValidationCallback
リファレンス経由で独自の検証動作を指定することができます：https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.servercertificatevalidationcallback(v=vs.110).aspx
デフォルトの実装は非常に合理的である - 検証が失敗したときに例外をスローします。
Webサービスを消費するために書かれたHTTPクライアントライブラリを使用している場合は、証明書の検証に失敗した場合は呼び出しが失敗します。正しいhttpクライアントライブラリは、接続するホスト名が証明書のサブジェクト名、CAが正しいかどうかなどを確認することを含め、完全な検証を行います。.NETの実装が正しいことを願っていますが、確かにテストして検証する必要がありますそのデフォルトの動作は正しいです。あなた次第
* "正しいhttpクライアントライブラリは...そのCAは正しいでしょう" * - 必ずしも真実ではありません。 Webセキュリティモデルでは、インターセプトは有効なユースケースです。その理由は[RFC 7469]（https://tools.ietf.org/rfc/rfc7469.txt）の上書きの理由です。このオーバーライドにより、攻撃者は既知の良いピンセットを壊すことができます。したがって、使用されているセキュリティモデルを知る必要があります。 * ".NETの実装がその点で正しいと願っています..." - MicrosoftはWebセキュリティモデルを使用していません。 – jww
@jww私はあなたのことを完全に理解していません。 "オーバーライドの理由は...オーバーライドにより、攻撃者は既知の良いピンセットを壊すことができます。"私は混乱しています。また、「Webセキュリティモデル」が意味することを明確にしていない。特定の人が参照または使用できるもののように、あなたはそれについて話します。あなたが5年前の時点で現状を意味するのであれば、TLS証明書を検証した人は誰もいません。それは壊れていて、人々はそれを修正しています:) –
トピックに投票して閉じるのは奇妙です。 –
@MK。 - 書かれているように、これは設計とセキュリティの両方のエンジニアリングに関する質問です。細部が重要で正しいためには難しいかもしれないので、質問のためのより良いサイトがあります。これまでに提供されてきた答えは、多くのことを求めています。 – jww
@Jwwその後、より良いサイトは何ですか？ –