私たちは、OWASP ASVS チェックリストに準拠する必要がある ASP.NET プロジェクトに取り組んでいます。用語の 1 つは、「バックエンド TLS 接続の失敗がログに記録されていることを確認する」です。これを達成する方法を見つけることができませんでしたが、顧客は私たちにそれを求めています。提案/参照はありますか？サンプルコードはさらに良くなります。
owasp へのリンクは次のとおりです: http://code.google.com/p/owasp-asvs/wiki/Verification_V10
前もって感謝します。
私はこれがひどい言い回しであることに同意します。現在、ASVSの改良があります。さあ、私たちが物事をより具体的でテスト可能にするのを手伝ってください。
あなたの例では、TLS接続は通常、アプリケーションとライブラリコードに代わってオペレーティングシステムによって維持されますが、TLS接続がそれが缶にあると言っていることを確認するために実際の努力をすることはめったにありません。ブラウザはユーザーへの警告が上手くなりましたが、ライブラリは驚くほど悪く、エンドツーエンドのエラーをチェックし、接続の状態について賢明なセキュリティ決定を行う際にブラウザを呼び出すアプリケーションは悪くなっています。証明書の失効などの基本的なことでさえ簡単なことですが、デフォルトでこれを有効にするライブラリはほとんどありません。
これは携帯電話アプリで毎日見られます。ほとんどのモバイルアプリを、接続が信頼できないというユーザーフィードバックを提供しないMITMプロキシ経由で接続するのは簡単です。
この要件を次のようにしたいと思います。
「ユーザーエージェントソフトウェア（モバイルアプリ、ブラウザ、Webサービス、ライブラリ）は、接続が信頼できないことをエンドユーザーが容易に理解できることを明確にし、さらに接続を拒否するか、安全でないものを確立するためにユーザーの介入を要求する必要があります。接続。このような失敗した接続や安全でない接続はログに記録する必要があります。」
これにより、OS、ライブラリ、またはアプリケーションに関係なく、誰かがこのインタラクションを所有し、明確なセキュリティ目標（信頼できない接続がない）、セキュリティを優先するユーザビリティコントロール、そして最後にユーザーがひどく悪い選択をした場合は、インシデント前の監視とインシデント後の再構築を許可します（私たちは彼らが常にチャンスを与えられていることを知っているからです）。
これ自体があなたの質問に答えないことは知っていますが、OpenSSLとWCFのどちらを使用するかについては言及していません。ご希望のプラットフォームをお知らせいただければ、コードスニペットを提供させていただきます。