Mozilla のMartin Thomson氏が「Secure Negotiation of Incompatible Protocols in TLS」という仕様を提案しているので軽く目を通す。
これは、HTTP/3とHTTS/2ように、バージョンによって下位層に使うプロトコルが異なる場合でも、ダウングレード攻撃を防ぐことを目的としている。そのために、TLSに新しくIncompatibleProtocol拡張を定義する。
HTTPを例に説明をするが、ほかのアプリケーションプロトコルについても適応できる。
（なお、HTTPの場合はAlt-Svcの仕組みがあるため、その点で幾つかの攻撃は防ぐことが出来る）
背景
クライアントとサーバが通信するプロトコルのバージョンを下げさせる、ダウングレード攻撃という攻撃があります。
攻撃の方法としては、通信をブロックし低いバージョンのプロトコルを試行させたり、DNS SVCBレコードを介して高いバージョンのプロトコルをサポートしている事を隠蔽する方法が考えられる。
TLSとQUICのALPN
QUICやTLSでは、ハンドシェイク中にALPNを通して使用するアプリケーションプロトコル及びそのバージョンをネゴシエーションします。このALPNはTLSのハンドシェイクの一部として保護されるため、クライアントとサーバが確実にアプリケーションプロトコルに合意できます。
このALPNではそのコネクションで使用できるアプリケーションプロトコルを提示します。HTTPのように、バージョンによって下位層に使うプロトコルが異なる場合では、下記のようなALPNをクライアントから提示し、サーバが選択することになります。
- TLSのALPN: h2, http/1.1
- QUICのALPN: h3
TLSのハンドシェイクを行うクライアントとサーバは、お互いに本当はh3に対応しているということがハンドシェイク中には知ることが出来ません。
IncompatibleProtocol拡張
TLSの拡張として、IncompatibleProtocol拡張を定義します。
- クライアントからは、IncompatibleProtocolで空を指定します
- サーバは、空のIncompatibleProtocolが送られてきた場合、このコネクションでは非互換なアプリケーションプロトコルをクライアントに通知します
HTTP/3に対応しているサーバに対して、HTTP/2 + TLSで接続を開始した際の例は次のとおりです。
こうすることで、非互換なアプリケーションプロトコルも含めサーバが対応しているアプリケーションプロトコルのバージョンを知ることが出来ます。
その後は具体的なアプリケーションプロトコルの動作に依存するかと思います。
