TLS1.3 Study まとめ

2
Kaoru Maeda 前田 薫 @mad_p

kazuさん: TLS1.3のフルハンドシェイク: DH鍵交換はクライアントからスタート。サーバ視点ではすぐ鍵がわかる。1往復目の帰りから暗号化できる #tls13_study

2018-02-14 19:43:54
Kaoru Maeda 前田 薫 @mad_p

kazuさん: CertificateVerifyによってサーバの認証が行える。証明書をもらったから相手がわかるのではなく、秘密鍵を使って署名させ検証することでわかる #tls13_study

2018-02-14 19:45:25
Kaoru Maeda 前田 薫 @mad_p

kazuさん: RSA鍵交換では、秘密鍵を相手の公開鍵で暗号化して送っていたので、受け取れて暗号通信ができるということで暗黙的に秘密鍵を使っていることがわかった #tls13_study

2018-02-14 19:46:50
Kaoru Maeda 前田 薫 @mad_p

kazuさん: 鍵交換とサーバー認証が分離されたので、CertificateVerifyが必要になった #tls13_study

2018-02-14 19:47:19
Kaoru Maeda 前田 薫 @mad_p

kazuさん: Finishedによって暗号鍵を切りかえる。ChangeCipherSpecは必要なくなった #tls13_study

2018-02-14 19:48:27
さいぺ @cipepser

鍵を変えるタイミング(Finishedのあと)が規定されるので、Change Cipher Specはなくなる #tls13_study

2018-02-14 19:48:51
Kaoru Maeda 前田 薫 @mad_p

鍵交換のときにEphemeralでないといけないと言われているが、ECでないDHEでもいい? → いいけど、鍵が大きく大変になる #tls13_study

2018-02-14 19:50:10
Kaoru Maeda 前田 薫 @mad_p

kazuさん: TLS拡張が暗号化されることになった。例えばALPNの場合、TLS1.2ではサーバーが選んだプロトコルは平文で送られたので、観測者は「こいつらh2しゃべってるな」とわかった。TLS1.3では返信が暗号化されるのでわからない #tls13_study

2018-02-14 19:51:31
Kaoru Maeda 前田 薫 @mad_p

kazuさん: 再トライ(HelloRetryRequest)。鍵交換では複数の公開鍵を送ってもよいが、鍵はでかいので、まずクライアントはひとつだけ送ってみる。サーバがもしその方式が扱えなければ方式を指定してやり直してね、とお願いする #tls13_study

2018-02-14 19:53:05
Kaoru Maeda 前田 薫 @mad_p

kazuさん: クライアントはそれを覚えておいて、次回の通信では要求された方式を最初に選ぶ #tls13_study

2018-02-14 19:53:44
Kaoru Maeda 前田 薫 @mad_p

kazuさん: TLS1.2にはセッションの再開というモードがあった。続きで通信できるならサーバ認証をすっ飛ばせる。セッションID(サーバが状態を持つ)、セッションチケット(サーバは状態を持たずにチケットに埋め込んで渡しておく) #tls13_study

2018-02-14 19:55:47
Kaoru Maeda 前田 薫 @mad_p

kazuさん: ポイントは、サーバ認証をすっとばせること #tls13_study

2018-02-14 19:56:07
Kaoru Maeda 前田 薫 @mad_p

kazuさん: もうひとつはPSK(Pre-Shared Key)。これは公開鍵とか使わず、あらかじめ設定しておいた秘密を使う。共通の秘密を持っているならサーバ認証すっとばせるよね #tls13_study

2018-02-14 19:56:57
さいぺ @cipepser

セッションのresumption、PSKはサーバ認証をすっ飛ばせる →どちらもclient、serverで情報を共有してる状態なので統合できる #tls13_study

2018-02-14 19:57:35
さいぺ @cipepser

具体的には、ClientHelloにPSKを付ける #tls13_study

2018-02-14 19:58:23
Kaoru Maeda 前田 薫 @mad_p

kazuさん: これふたつ、似てんじゃん! 統合できんじゃね? ということで統合された。TLS1.3のPSKにはふたつの意味がある: 外部PSKと再開PSK。ClientHelloに入ってきたPSKがどちらなのかで区別できる #tls13_study

2018-02-14 19:58:28
Kaoru Maeda 前田 薫 @mad_p

kazuさん: このときにDHE公開鍵も交換するので前方秘匿性は担保できる。なんとなくTLS1.3美しい! と思えてきましたね? #tls13_study

2018-02-14 19:59:35
Kaoru Maeda 前田 薫 @mad_p

kazuさん: 0RTT: おたがいにPSKを持っているなら、いきなり暗号化できんじゃね? → ClientHelloといっしょに暗号化したデータも送る(early dataというフラグをつける) #tls13_study

2018-02-14 20:00:24
さいぺ @cipepser

PSKがあるなら0RTTで暗号化できるよね!ただし、ephemeralではないので前方秘匿性はない #tls13_study

2018-02-14 20:01:06
Kaoru Maeda 前田 薫 @mad_p

kazuさん: サーバはearly dataを受け入れたらフラグを返す。early data部分はPSKを使っているので前方秘匿性がない #tls13_study

2018-02-14 20:01:50
さいぺ @cipepser

リプレイ攻撃のリスクがあるので、副作用のあるリクエストでリプレイ攻撃されると状態を変えられてしまう #tls13_study

2018-02-14 20:02:30
Kaoru Maeda 前田 薫 @mad_p

kazuさん: early data部分は横から聞いてる人がそのまま送っても正しいデータなので、使い方に注意。PUTがリプレイされたりとかあるかも #tls13_study

2018-02-14 20:04:30
Kaoru Maeda 前田 薫 @mad_p

EndOfEarlyDataはなぜ必要? → 複数レコードで送ってもよいため、終わりの印が必要 #tls13_study

2018-02-14 20:04:44
Kaoru Maeda 前田 薫 @mad_p

kazuさん: 標準化の歴史。draft18でX25519が採用された。DJBがアメリカ政府の息がかかっていないところで作った方式。NISTは疑似乱数にバックドアを仕込んだ前科があるので誰も信用していない! #tls13_study

2018-02-14 20:06:47
さいぺ @cipepser

乱数生成アルゴリズム「Dual_EC_DRBG」にバックドアの恐れがあるとして注意を呼びかけ | スラド セキュリティ security.srad.jp/story/13/09/25… 2013年ですか。全然知らなかったです。 #tls13_study

2018-02-14 20:06:54