TLS over HTTPの提案仕様

TLS over HTTPである。HTTP over TLSではない。

「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(仕様中ではATLSと記述される)

HTTP上でTLSレコードを送受信する仕様である。

TLSレイヤの実装変更はなくレコードをHTTPのボディで送受信できるようにする。なお、httpとhttps両方で使用可能である。

また、TLS1.2とTLS1.3などすべてのTLSバージョンに対応する。

来週からはじまるIETF100でも議論されるようなので、かいつまんで読んで見る。

クライアント

クライアントからの基本的なメッセージは、POSTでJSONを送信する。

Content-Typeにはapplication/atls+jsonを指定する

   POST /atls
   Content-Type: application/atls+json

   {
     "session": "<session-string>",
     "records": "<base64 encoded TLS records>"
   }

サーバ

サーバも基本的には同様である。

   200 OK
   Content-Type: application/atls+json

   {
     "session": "<session-string>",
     "records": "<base64 encoded TLS records>"
   }

正しくないリクエストを受け取った際は400 Bad Requestを返す

ハンドシェイク

各アプリケーションは、内部的に持つTLS実装を用いてセッションを開始する。作成されたレコードはJSON形式に変換されHTTP上で送信される。サーバ側は受け取ったJSONよりTLSレコードを復元しTLS実装に渡し、同様にTLSレコードを送り返す。

f:id:ASnoKaze:20171111223136p:plain

WebSocketの利用

HTTPを利用するとサーバからメッセージを送ることは出来ません。TLS closeメッセージなどサーバから送れるように、WebSocketsに通信をアップグレードすることもできます。

なぜこんなことをするのか

最後になったが、何故このようなことをしているのか、ドラフト中にも書かれている。

f:id:ASnoKaze:20171111230217p:plain
ネットワーク管理者がネットワーク接続をするクライアントに信頼できるルート証明書をインストールさせ、ローカルネットワークの出口などでクライアントとサーバの中間に入ってTLSをほどき、平文を確認し再度TLSセッションを貼り直すような環境を想定している。