[2021/05/16 追記] 議論が進み、MASQUEを実現する仕様が幾つか出てます
- 提案仕様「HTTP Transport Authentication」について - ASnoKaze blog
- CONNECT-UDP HTTPメソッドの仕様 - ASnoKaze blog
- HTTPコネクションでIPパケットをProxyさせる、新しいCONNECT-IPメソッドの仕様 - ASnoKaze blog
GoogleのDavid Schinazi氏が「The MASQUE Protocol」という仕様を提出している。
初版のdraftであり、議論の呼び水としての立ち位置が強いがまずは読む。
MASQUE Protocol
MASQUEはMultiplexed Application Substrate over QUIC Encryptionの略称です。この提案仕様では、例えばHTTP/3のQUICコネクションを確立したあとに、そのQUICコネクションをVPNとして使う例を上げています。もちろん、他のプロトコルも通信可能だと思います。
このMASQUEプロトコルの大きな特徴としては、第三者がMASQUEプロトコルの使用に気づかないところである。
- クライアント・サーバ間の通信を見てもMASQUEプロトコルを喋ってることがわからない
- 第三者がサーバに通信を試みてもただのWebサーバにしか見えない (MASQUEプロトコルを喋るための鍵がないため)
もちろんHTTP/2 over TCPにフォールバックも可能だがパフォーマンス的には劣ることになる。
また、Datagramフレームの利用などを上げているが、具体的なVPN over QUICの仕組みには言及しておらず、方向性含め議論となると思われる。
(「QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム)」)
例
HTTP/3として通信を開始したあとに、クライアントを認証したあとに、そのストリームはMASQUEプロトコル専用に移行します。
- MASQUE通信を行うクライアントとサーバは事前に共通鍵を共有しておくか、サーバはクライアントの秘密鍵に対応する公開鍵をリストしておきます。
- クライアントは通常のHTTP/3で、サーバに接続します。(ラベルEXPORTER-masqueを用いた、TLS keying material exporterで得られた値を後のノンスとして使用する。)
- クライアントは/.well-known/masque/initialに対してCONNECTメソッドのリクエストを投げます。この際に認証に使う、Masque-Authenticationを付加します。公開鍵を使う場合と、共通鍵を使う場合で異なります
Masque-Authentication: PublicKey u="am9obi5kb2U=";a=1.3.101.112; s="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==" Masque-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3; s="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ=="