TLS 1.3 と 0-RTT のこわ〜い話

Copyright(C)2016DeNACo.,Ltd.AllRightsReserved.

TLS 1.3 と 0-RTTのこわ〜い話

DeNA Co., Ltd.Kazuho Oku


TLS 1.3とは

n  TLSのメジャーバージョンアップ⁃  より速く⁃  より安全⁃  プライバシー保護

TLS 1.3 と 0-RTT のこわ〜い話


より速く

n  ハンドシェイクの⾼速化:⁃  TLS 1.2: フル=2 RTT, リザンプション=1 RTT⁃  TLS 1.3: フル=1 RTT, リザンプション=0 RTT

n  アプリケーションデータの暗号化フォーマットの最適化



より安全

n  AEAD必須⁃  cf. BEAST攻撃

n  圧縮禁⽌⁃  cf. CRIME攻撃

n  Perfect Forward Secrecy⁃  リザンプション時も



プライバシー保護

n  TLS 1.2以前の問題:⁃  証明書が平⽂で流れる•  誰が通信してるのか、まるわかり

⁃  特にクライアント認証で問題⁃  リザンプションのチケットが同⼀のまま複数回、平⽂

で流れる•  複数のTLS通信にまたがったユーザトラッキングが可能

n  TLS 1.3:⁃  できるだけ多くの情報を（証明書等も）暗号化⁃  チケットは毎回更新



で、具体的にどう変わったの?



TLS 1.2の通信フロー


ClientHello

ServerHelloCer@ficate

Cer@ficateVerify

Finished

Client Server

Applica@onData

暗号

化

SessionTicket(s)Finished


TLS 1.3の通信フロー


ClientHello

ServerHello

EncryptedExtensionsCer@ficate

Cer@ficateVerifyFinished

Finished

Client Server(EC)DH鍵+パラメータ

(EC)DH鍵

パラメータ

サーバ証明書

サーバ証明書検証MAC

ハンドシェイク検証MAC

ハンドシェイク検証MAC

Applica@onDataSessionTicket(s)(E

C)DH

鍵交

換由

来の

鍵で

暗号

化


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)


type version length data

type“encrypted”

version length data type padding

暗号化される部分


TLS 1.3の通信フロー（0-RTTリザンプション）


ClientHello(ECDH+session@cket)

Client Server

@cket+

(EC)DH

鍵交

換由

来の

鍵で

暗号

化 0-RTTData

(PSK由来の鍵で暗号化)ServerHello(ECDH)EncryptedExtensionsFinished

0.5-RTTDataFinished SessionTicket


リザンプションについて

n  TLS 1.3では、クライアントはsession ticketを使い捨て⁃  サーバは接続毎にsession ticketを暗号化して送信⁃  クライアントはsession ticketを平⽂で送信⁃  → 盗聴者は、複数のTLS接続にまたがったトラッキン

グができないn  TLS 1.3では、リザンプション時も(EC)DH鍵交換をする

⁃  → TCP接続ごとのforward secrecyが確保される⁃  リザンプション時に前回の暗号化鍵を使うことも仕様

上可能だが、ブラウザの対応予定なし



そのほか



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), …



バージョン問題

n  TLS 1.3でいいよ！⁃  上位互換なんだから

n  TLS 2がいいよ！⁃  ⼤幅な変更なんだから

n  TLS 4がいいよ！⁃  SSL 3よりも、いいプロトコルなんだから

n  TLS 2017がいいよ！⁃  これで混乱しないでしょ



今後のスケジュール

n  2016/10 – WG last call なうn  2016/12 – ヘッダを2バイト削っても問題ないか試すn  2016/02 – セキュリティレビューを待って制定?



0-RTTのこわ〜い話



その前にCM



picotlsいいですよ

n  H2Oの次期TLS実装 (MITライセンス)⁃  TLS 1.3とQUICで使⽤予定

n  特徴:⁃  TLS 1.3のみ実装•  0-RTT や early-data にも対応

⁃  とても⼩さい•  暗号ライブラリこみで100KB程度

⁃  組み込みでも便利！•  OpenSSLの暗号ライブラリ(libcrypto)と組み合わせるこ

ともできる







HTTP Workshop 2016における、Subodh Iyengar⽒の発表および関連した議論において出てきた話題を紹介します



0-RTT dataとは

n  ハンドシェイク完了前にアプリケーションデータを送信可能⁃  メリット: 1RTT 節約⁃  デメリット: ハンドシェイク毎リプレイ可能

n  正しい使い⽅: リプレイされても困らないデータのみ0-RTTで送信しましょう

↓それって現実的なの？



HTTPとリトライ

n  HTTP仕様⽈く:⁃  「べき等性のあるメソッドはリトライしても良い」⁃  「べき等性のないメソッドは⾃動リトライ禁⽌」•  e.g. POST

n  現実:⁃  ブラウザはPOSTもリトライ•  ただし、サーバが何も⾔わずに接続を切った場合•  再接続が必要だと判断した場合、接続を切って再POSTを

期待するサーバ実装が現実に存在する⁃  Chromeは既にQUICで0-RTT+POSTリトライしてる



３種類のsafety

n  retry-safety⁃  クライアントにリトライさせないようにする

n  idempotence⁃  リトライされても安全

n  replay-safety⁃  アプリケーションデータをリプレイされないようにす

る



３種類のsafety

n  retry-safety⁃  リトライ攻撃の例: TLSを中継してHTTPSレスポンス

の代わりにTCP切断を送信⁃  典型的対策: フォームにnonceを紐付けて、リクエス

ト受信時にmemcachedにnonceを突っ込むn  idempotence

⁃  リトライされても⼤丈夫⁃  結果がべき等だから

n  これらの⼿法は、リトライ攻撃がユーザアクセスとほぼ同時期に発⽣することを前提としている



３種類のsafety

n  replay-safety⁃  定義: アプリケーションデータをリプレイされても安

全（0-RTT dataだから「リプレイ」できる）⁃  2年前のHTTPSリクエストをリプレイされたらどうな

る?•  memcachedのリプレイ対策情報は既に消えているだろう•  べき等性を保つべきリソースの状態は既に変化しているか

も



replay-safetyをどう確保するか

n  案1. session ticketに署名つきで有効期限を⼊れるn  案2. フォームのhidden要素に有効期限を⼊れるn  注意点:

⁃  TLS 1.2以前では、リプレイ/リトライ回数の上限は、ブラウザがPOSTを⾃動再試⾏する回数

⁃  TLS 1.3+0RTTでは、上限が攻撃者がリプレイする回数に変わる•  サーバファームでカウンタを⽤いて抑⽌するとしても、

DC/POP単位にならざるを得ない•  DoSベクタにならないよう注意が必要



まとめ



まとめ

n  TLS 1.3はメジャーバージョンアップ⁃  セキュリティ・プライバシ・パフォーマンスの向上⁃  picotlsいいよ（宣伝）

n  0-RTTは取扱いに注意が必要⁃  攻撃下ではサーバ側でオフにできるように


Internet

TLS 1.3 と 0-RTT のこわ〜い話