読者です 読者をやめる 読者になる 読者になる

TLS Jump Startとは

TLS Jump Start

CloudFlareの方によって、TLS Jump Startという仕様が提案されている。
雑にですが簡単に斜め読みした(例のごとく間違い等あるかと思います)
https://tools.ietf.org/html/draft-vkrasnov-tls-jumpstart-00


TLSの通信では初期接続時に複数回のラウンドトリップが発生します。
TCPの3ウェイハンドシェイクも含めれば、データの送受信を開始するのに3回のラウンドトリップが発生します。
このラウンドトリップ回数を減らすのがTLS Jump Startです。

概要

TLS Jump StartではTCP3ウェイハンドシェイク中に、UDPでClientHelloとServerHelloをやりとりしてしまいます。


クライアントは、SYN・ACKを受け取るよりも前にServerHelloを受け取っていればそのままTCPTLSハンドシェイクの続きを送信します。




もちろん、サーバからUDPでのServerHelloが送られてこない場合はTCPで通常通りのTLSハンドシェイクを行います。

クライアントの動作

TLS Jump Startを開始する場合は、最初にUDPでClientHelloを送信しなければならない(MUST)。
その後(もしくは同時に)、TCP接続を開始しなければならない(MUST)。このときUDPTCPで使用するポートは同じであるべきである(SHOULD)。


TCP接続が確立されたらサーバからUDPの応答があったか確認する。もしデータが届いていれば、TCP接続でTLSハンドシェイクを続けても良い(MAY)。
もし、データが完全でない場合は新しくTCPでClientHelloを送信しなければならない(MUST)、このときclient
random_bytesは新しく生成ものを用いる。

サーバの動作

サーバはTCPでのポート番号と同じポート番号でUDPのClientHelloを受け付けなければならい。
UDPでClientHelloを受け取った際、サーバはIPとポートより送信元を確認します。
もしも、送信元によるTCPコネクションが既に確立されていればメッセージを無視します(MUST)。


サーバは過去に受け取ったClientHelloを対応するレスポンスメッセージとともに一定期間ヒストリとして保存しとく必要があります(MUST)。
同じIPから既にメッセージが届いていれば無視し、新しい接続であればServerHelloなどを返さなければならない(MUST)


TCPコネクションが確立され、最初のメッセージ待ちます。もし、最初のメッセージがClientHelloであれば、ヒストリをチェックしその送信元からのエントリがあれば削除します。


もし、最初のメッセージがClientKeyExchangeかCertificateかFinishedであれば、サーバはヒストリから該当エントリを取り出します(MUST)。そのエントリを使ってハンドシェイクプロセスを続行し、ヒストリからそのエントリを削除します。

セキュリティ周り

ハンドシェイクの完全性は配送手段に影響されません。


UDPを使うことで、他のUDPプロトコルと同様に、反射増幅攻撃に対する脆弱性があります。
しかしながら、同一のIPには1度しかメッセージを返さないため、強く制限されています。