DTLS — Web Protocol Lab

#このページで確認できること

UDP 上でハンドシェイクを成立させるために TLS に追加された仕組み(cookie、再送、シーケンス番号)を理解する
cookie 交換が送信元IP詐称・増幅攻撃への対策になっている理由を確認する
WebRTC のどの段階で DTLS が現れるかを確認する
観察する項目: Wireshark フィルタ dtls、ClientHello の再送、HelloVerifyRequest

実装上の制約: 公開の DTLS エンドポイントは提供していません。検証は openssl s_server / s_client の DTLS モードをローカルで動かすか、WebRTC 通話のキャプチャで行ってください。

#TLS との違い

	TLS	DTLS
トランスポート	TCP (信頼性あり)	UDP (パケロス・順序入替あり)
ハンドシェイクの再送	TCP に任せる	自前の再送タイマーを持つ
レコードの順序	ストリーム順が保証される	明示的なシーケンス番号を各レコードに持つ
メッセージ分割	TLSレコードへ分割可能。配送はTCPのバイトストリームに依存	UDPデータグラムに収めるため、ハンドシェイク層にfragment offset / lengthを持つ
アプリデータ	バイトストリーム	データグラム単位。DTLSレコード層は失われたアプリデータを再送しない
到達可能性の確認	TCP 3-way handshake が担う	必要に応じてcookie交換で送信元IP・ポートへのreturn routabilityを確認

DTLSレコード層はアプリデータの再送を行いません。音声・映像のように遅れて届くデータの価値が低い用途に向く一方、信頼性が必要なアプリケーションは上位プロトコルで再送などを設計します。

#ハンドシェイクと cookie 交換

UDPにはTCPの3-way handshakeのような到達可能性確認がなく、送信元IPを詐称したデータグラムもサーバーに届き得ます。サーバーがいきなり証明書などの大きい応答を返すと、増幅攻撃に悪用されるおそれがあります。DTLS 1.2ではcookie付きHelloVerifyRequestを使い、クライアントが同じcookieを付けて再送できること、つまり申告されたIP・ポートへ応答が届くことを本処理の前に確認できます。これは相手の身元を認証する仕組みではありません。

DTLS 1.2 — HelloVerifyRequest による送信元検証

participants: Client, Server
Client -> Server: ClientHello (cookie なし) [UDP]
Server --> Client: HelloVerifyRequest (cookie)
Client -> Server: ClientHello (cookie 付きで再送)
note: 申告されたIP・ポートへのreturn routabilityを確認
Server --> Client: ServerHello + Certificate + ServerHelloDone
Client -> Server: ClientKeyExchange + ChangeCipherSpec + Finished
Server --> Client: ChangeCipherSpec + Finished
Client <-> Server: Application Data (データグラム単位)

DTLS 1.3: TLS 1.3 と同様に通常1往復で成立し、HelloVerifyRequest は廃止されました。増幅の懸念がある場合は HelloRetryRequest + cookie 拡張でreturn routabilityを確認できます。QUICでは、アドレス検証前にサーバーが送れる量を受信量の3倍までに制限し、必要に応じてRetryでアドレスを検証します。クライアントが送るInitial入りUDPデータグラム等の1200バイト下限も、増幅率の抑制や経路MTUの確認に関係します。

#どこで使われるか

WebRTC: メディア(SRTP)の鍵交換とデータチャネル(SCTP over DTLS)の保護。ブラウザ間通信で最も身近な DTLS。詳細は WebRTC。
VPN: Cisco Secure Client (AnyConnect) / OpenConnect 系などには、TLS(TCP)トンネルに加えてDTLS(UDP)トンネルを利用できる実装がある。設定と実装が対応していれば、UDP経路が使えないときにTLS(TCP)側で通信を継続する場合がある。
CoAP (IoT): 制約デバイス向けプロトコル CoAP の暗号化(coaps、UDP 5684)。

#検証コマンド

openssl — ローカルで DTLS サーバー/クライアントを立てる

# 検証用の自己署名証明書を作る
$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
    -days 7 -nodes -subj '/CN=dtls-lab'

# DTLS サーバー (UDP 4433 で待ち受け)
$ openssl s_server -dtls1_2 -key key.pem -cert cert.pem -accept 4433

# 別ターミナルから DTLS クライアントで接続
$ openssl s_client -dtls1_2 -connect 127.0.0.1:4433

tcpdump — ハンドシェイクの観測

$ sudo tcpdump -i lo0 -n 'udp port 4433'
# Wireshark なら filter: dtls — HelloVerifyRequest と cookie 付き再送が見える

出力例 (cipherはOpenSSLのバージョン・設定で変わる)

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Protocol : DTLSv1.2 Timeout : 7200 (sec)

#観測ポイント

openssl	`Protocol : DTLSv1.2` の表示。パケットを落とす環境(不安定なWi-Fi等)ではハンドシェイクの再送間隔が伸びていく様子も観測できる。
DevTools	通常のNetworkパネルにはDTLSレコードが個別リクエストとして表示されない。WebRTC利用時は `chrome://webrtc-internals` の `dtlsState` (new → connecting → connected) で状態を確認する。
Proxy	従来型HTTP CONNECTはTCPトンネルなのでDTLSを直接運べない。VPNやWebRTCでは、ネットワークポリシーでUDPが使えない場合にTCP/TLS系の経路へフォールバックすることがある。MASQUE CONNECT-UDP対応プロキシは別扱い。
tcpdump / Wireshark	フィルタ: `dtls`。DTLS 1.2ではClientHelloの再送、HelloVerifyRequest、epochとシーケンス番号をレコードヘッダーで観測できる。DTLS 1.3の暗号化レコードではレコード番号が保護される一方、ユニファイドヘッダーにはepochの下位2ビット(Eビット)が残る。復号の有無でWiresharkが表示できる項目を分けて確認する。
TLS inspection	DTLSを復号できない装置では、UDPを遮断してTCP(TLS)側へフォールバックさせる構成が使われることがある。その場合は接続までの遅延や品質への影響を確認する。

#関連

ベースの仕組みは TLS を参照。UDP 上の暗号化トランスポートという意味では QUIC が近い位置にありますが、QUIC は DTLS を使わず TLS 1.3 を直接統合した別物です。代表的な利用例である WebRTC も参照してください。