slides at http2勉強会 #10

1. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3 と 0-RTTのこわ〜い話
DeNA Co., Ltd.
Kazuho Oku

2. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3とは
n TLSのメジャーバージョンアップ
⁃ より速く
⁃ より安全
⁃ プライバシー保護
TLS 1.3 と 0-RTT のこわ〜い話

3. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
より速く
n ハンドシェイクの⾼速化:
⁃ TLS 1.2: フル=2 RTT, リザンプション=1 RTT
⁃ TLS 1.3: フル=1 RTT, リザンプション=0 RTT
n アプリケーションデータの暗号化フォーマットの最適化
TLS 1.3 と 0-RTT のこわ〜い話

4. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
より安全
n AEAD必須
⁃ cf. BEAST攻撃
n 圧縮禁⽌
⁃ cf. CRIME攻撃
n Perfect Forward Secrecy
⁃ リザンプション時も
TLS 1.3 と 0-RTT のこわ〜い話

5. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
プライバシー保護
n TLS 1.2以前の問題:
⁃ 証明書が平⽂で流れる
• 誰が通信してるのか、まるわかり
⁃ 特にクライアント認証で問題
⁃ リザンプションのチケットが同⼀のまま複数回、平⽂
で流れる
• 複数のTLS通信にまたがったユーザトラッキングが可能
n TLS 1.3:
⁃ できるだけ多くの情報を（証明書等も）暗号化
⁃ チケットは毎回更新
TLS 1.3 と 0-RTT のこわ〜い話

6. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
で、具体的にどう変わったの?
TLS 1.3 と 0-RTT のこわ〜い話

7. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.2の通信フロー
TLS 1.3 と 0-RTT のこわ〜い話
ClientHello
ServerHello
Cer@ficate
Cer@ficateVerify
Finished
Client Server
Applica@on Data
暗号化
Session Ticket(s)
Finished

8. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3の通信フロー
TLS 1.3 と 0-RTT のこわ〜い話
ClientHello
ServerHello
EncryptedExtensions
Cer@ficate
Cer@ficateVerify
Finished
Finished
Client Server
(EC)DH鍵+パラメータ
(EC)DH鍵
パラメータ
サーバ証明書
サーバ証明書検証MAC
ハンドシェイク検証MAC
ハンドシェイク検証MAC
Applica@on Data
Session Ticket(s)
(EC)DH鍵交換由来の鍵で暗号化

9. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3のレコードフォーマット
n TLS 1.2以前では、アプリケーションデータのみ暗号化
n TLS 1.3では、Hello以外のすべてのデータを暗号化
平⽂: 16 03 01 00 04 DE AD BE EF
暗号⽂: 17 03 01 04 55 (DE AD BE EF 16 00 00 00)
TLS 1.3 と 0-RTT のこわ〜い話
type version length data
type
“encrypted”
version length data type padding
暗号化される部分

10. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
TLS 1.3の通信フロー（0-RTTリザンプション）
TLS 1.3 と 0-RTT のこわ〜い話
ClientHello
(ECDH + session @cket)
Client Server
@cket + (EC)DH鍵交換由来の鍵で暗号化
0-RTT Data
(PSK由来の鍵で暗号化)
ServerHello (ECDH)
EncryptedExtensions
Finished
0.5-RTT Data
Finished Session Ticket

11. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
リザンプションについて
n TLS 1.3では、クライアントはsession ticketを使い捨て
⁃ サーバは接続毎にsession ticketを暗号化して送信
⁃ クライアントはsession ticketを平⽂で送信
⁃ → 盗聴者は、複数のTLS接続にまたがったトラッキン
グができない
n TLS 1.3では、リザンプション時も(EC)DH鍵交換をする
⁃ → TCP接続ごとのforward secrecyが確保される
⁃ リザンプション時に前回の暗号化鍵を使うことも仕様
上可能だが、ブラウザの対応予定なし
TLS 1.3 と 0-RTT のこわ〜い話

12. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
そのほか
TLS 1.3 と 0-RTT のこわ〜い話

13. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
Chinese Menu問題
n TLS 1.2以前:
⁃ RSA_WITH_AES_128_CBC_SHA (002f)
⁃ ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
(c023)
⁃ …
n TLS 1.3:
⁃ 鍵交換: secp256r1 (23), ...
⁃ 証明書検証: rsa_pkcs1_sha256 (0401), ...
⁃ 暗号化: AES_128_GCM_SHA256 (1301), …
TLS 1.3 と 0-RTT のこわ〜い話

14. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
バージョン問題
n TLS 1.3でいいよ！
⁃ 上位互換なんだから
n TLS 2がいいよ！
⁃ ⼤幅な変更なんだから
n TLS 4がいいよ！
⁃ SSL 3よりも、いいプロトコルなんだから
n TLS 2017がいいよ！
⁃ これで混乱しないでしょ
TLS 1.3 と 0-RTT のこわ〜い話

15. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
今後のスケジュール
n 2016/10 – WG last call なう
n 2016/12 – ヘッダを2バイト削っても問題ないか試す
n 2016/02 – セキュリティレビューを待って制定?
TLS 1.3 と 0-RTT のこわ〜い話

16. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTTのこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話

17. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
その前にCM
TLS 1.3 と 0-RTT のこわ〜い話

18. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
picotlsいいですよ
n H2Oの次期TLS実装 (MITライセンス)
⁃ TLS 1.3とQUICで使⽤予定
n 特徴:
⁃ TLS 1.3のみ実装
• 0-RTT や early-data にも対応
⁃ とても⼩さい
• 暗号ライブラリこみで100KB程度
⁃ 組み込みでも便利！
• OpenSSLの暗号ライブラリ(libcrypto)と組み合わせるこ
ともできる
TLS 1.3 と 0-RTT のこわ〜い話

19. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTTのこわ〜い話
TLS 1.3 と 0-RTT のこわ〜い話

20. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTTのこわ〜い話
HTTP Workshop 2016における、Subodh Iyengar⽒の発
表および関連した議論において出てきた話題を紹介します
TLS 1.3 と 0-RTT のこわ〜い話

21. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
0-RTT dataとは
n ハンドシェイク完了前にアプリケーションデータを送信
可能
⁃ メリット: 1RTT 節約
⁃ デメリット: ハンドシェイク毎リプレイ可能
n 正しい使い⽅: リプレイされても困らないデータのみ0-
RTTで送信しましょう
↓
それって現実的なの？
TLS 1.3 と 0-RTT のこわ〜い話

22. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
HTTPとリトライ
n HTTP仕様⽈く:
⁃ 「べき等性のあるメソッドはリトライしても良い」
⁃ 「べき等性のないメソッドは⾃動リトライ禁⽌」
• e.g. POST
n 現実:
⁃ ブラウザはPOSTもリトライ
• ただし、サーバが何も⾔わずに接続を切った場合
• 再接続が必要だと判断した場合、接続を切って再POSTを
期待するサーバ実装が現実に存在する
⁃ Chromeは既にQUICで0-RTT+POSTリトライしてる
TLS 1.3 と 0-RTT のこわ〜い話

23. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
３種類のsafety
n retry-safety
⁃ クライアントにリトライさせないようにする
n idempotence
⁃ リトライされても安全
n replay-safety
⁃ アプリケーションデータをリプレイされないようにす
る
TLS 1.3 と 0-RTT のこわ〜い話

24. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
３種類のsafety
n retry-safety
⁃ リトライ攻撃の例: TLSを中継してHTTPSレスポンス
の代わりにTCP切断を送信
⁃ 典型的対策: フォームにnonceを紐付けて、リクエス
ト受信時にmemcachedにnonceを突っ込む
n idempotence
⁃ リトライされても⼤丈夫
⁃ 結果がべき等だから
n これらの⼿法は、リトライ攻撃がユーザアクセスとほぼ
同時期に発⽣することを前提としている
TLS 1.3 と 0-RTT のこわ〜い話

25. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
３種類のsafety
n replay-safety
⁃ 定義: アプリケーションデータをリプレイされても安
全（0-RTT dataだから「リプレイ」できる）
⁃ 2年前のHTTPSリクエストをリプレイされたらどうな
る?
• memcachedのリプレイ対策情報は既に消えているだろう
• べき等性を保つべきリソースの状態は既に変化しているか
も
TLS 1.3 と 0-RTT のこわ〜い話

26. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
replay-safetyをどう確保するか
n 案1. session ticketに署名つきで有効期限を⼊れる
n 案2. フォームのhidden要素に有効期限を⼊れる
n 注意点:
⁃ TLS 1.2以前では、リプレイ/リトライ回数の上限は、
ブラウザがPOSTを⾃動再試⾏する回数
⁃ TLS 1.3+0RTTでは、上限が攻撃者がリプレイする回
数に変わる
• サーバファームでカウンタを⽤いて抑⽌するとしても、
DC/POP単位にならざるを得ない
• DoSベクタにならないよう注意が必要
TLS 1.3 と 0-RTT のこわ〜い話

27. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
まとめ
TLS 1.3 と 0-RTT のこわ〜い話

28. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved.
まとめ
n TLS 1.3はメジャーバージョンアップ
⁃ セキュリティ・プライバシ・パフォーマンスの向上
⁃ picotlsいいよ（宣伝）
n 0-RTTは取扱いに注意が必要
⁃ 攻撃下ではサーバ側でオフにできるように
TLS 1.3 と 0-RTT のこわ〜い話