3.2. 厳格なTLS (Strict TLS)

SSL Stripping ([RFC7457] のセクション2.1で要約されている攻撃) を防ぐために、以下の推奨事項が提供されます:

• アプリケーションプロトコルが、実装または展開に対して厳格なTLS構成と、暗号化されていないトラフィックからTLS保護されたトラフィックへの動的アップグレード (STARTTLSなど) の選択肢を許可する場合、クライアントとサーバーは厳格なTLS構成を優先すべきです (SHOULD)。

• アプリケーションプロトコルは通常、初期プロトコル交換中にサーバーがTLSを提供する方法を提供し、時にはサーバーがTLSのサポートを通知する方法 (例: TLSが必要であることを示すフラグ) も提供します。残念ながら、これらの指示は通信チャネルが暗号化される前に送信されます。クライアントは、これらの指示がサーバーによって通知されていない場合でも、TLSのネゴシエーションを試みるべきです (SHOULD)。

• HTTPクライアントとサーバーの実装は、WebサーバーがTLS専用クライアントを受け入れる意思があることを通知できるようにするため、HTTP Strict Transport Security (HSTS) ヘッダー [RFC6797] をサポートしなければなりません (MUST)。

• Webサーバーは、TLS専用クライアントを受け入れる意思があることを示すためにHSTSを使用すべきです (SHOULD)。ただし、HSTSを使用することが実際に全体的なセキュリティを弱める方法で展開されている場合を除きます (例えば、[RFC6797] のセクション11.3で説明されているように、自己署名証明書でHSTSを使用することは問題になる可能性があります)。

理由: 保護されていない通信とTLS保護された通信を組み合わせると、SSL Strippingおよび類似の攻撃への道が開かれます。通信の初期部分が完全性保護されていないため、通信を平文のままにしておくことを目的とする攻撃者によって操作される可能性があるためです。