CRYPTRECシンポジウム2019, Tokyo, Japan

ガイドライン改訂に伴う論点整理とTLS1.3ディプロイメントについて

セキュリティ本部セキュリティ情報統括室
須賀祐治
2019-07-12© 2019 Internet Initiative Japan Inc.

1

自己紹介？
～昔の発表資料から～© 2019 Internet Initiative Japan Inc.

2

「技術翻訳者」連携の必要性
マスゴミ

情報弱者
顧客

Business

エグゼクティブ
営業
現場（エンジニア）
研究所（コストセンター）

噂
対処方法

ベンダー

Geeks
結果（論文など）

アカデミア

2012年3月総合大会「セキュリティプロトコル仕様の脆弱性事例と世代交代困難性」© 2019 Internet Initiative Japan Inc.

3

「技術翻訳者」の役割• 正しい情報をわかりやすく「上」に伝える– 落としてよい情報と肝の情報• 誤りがあればそれを正す– 噂が広まるのは早い• どう解釈しているのか「横」に伝える

2012年3月総合大会「セキュリティプロトコル仕様の脆弱性事例と世代交代困難性」© 2019 Internet Initiative Japan Inc.

4

SSL/TLS バージョンと移行に関する外的要因© 2019 Internet Initiative Japan Inc.

5

今回取り扱う技術の範囲
エンドユーザ
U/I問題

アプリケーション・システム
信頼点

TLS1.3
再設計

セキュア
プロトコル

SSL/TLS

暗号アルゴリズム

PKI

耐量子暗号

運用
© 2019 Internet Initiative Japan Inc.

常時SSL
6

SSL/TLSの経緯• Netscape Communicationsから1995年にInternet
draft が公開された時期と同じくして当時のブラウザ
Netscape NavigatorにSSL2.0が実装• 2014年10月に発表されたPOODLE攻撃はSSL3.0における根本的な問題を露呈• SSLの後継でありIETFで策定されたTLSは
1.0/1.1/1.2が1999/2006/2008年にそれぞれRFCとして公開• 2014年4月からTLS1.3ドラフト策定開始．28版の改訂後，2018年8月ついにTLS1.3がRFCとして公開© 2019 Internet Initiative Japan Inc.

7

SSL/TLSに対する攻撃の分類
仕様そのものの問題

実装上の問題Renegotiationを用いた中間者攻撃

Nov2009-Renegotiation脆弱性
Triple Handshake 攻撃

Padding Oracle 攻撃BEAST 攻撃POODLE 攻撃 ROBOT攻撃

タイミング攻撃Lucky Thirteen attack
TIME attack

圧縮機能における
サイドチャネル攻撃

CRIME attack

領域チェックバグ

Heartbleed Bug

ステート管理の不備

CCS Injection attack

サーバの設定ミス

FREAK 攻撃
Logjam 攻撃© 2019 Internet Initiative Japan Inc.

8

SSL/TLSバージョンごとの状況
プロトコル

バージョン

SSL

2.0
3.0

ステータス

ワークアラウンド

根拠

脆弱

なし

RFC6167

脆弱なし

RFC7568
POODLE攻撃© 2019 Internet Initiative Japan Inc.

9

IETFがSSL2.0/3.0を無効化（トップダウン的な措置）• 2011年3月– RFC 6176：Prohibiting Secure Sockets Layer（SSL） Version 2.0• 2015年6月– RFC 7568：Deprecating Secure Sockets
Layer Version 3.0– http://disablessl3.com/ by Michele Spagnuolo© 2019 Internet Initiative Japan Inc.

10

SSL/TLSバージョンごとの状況
プロトコル

バージョン

SSL

2.0
3.0

ステータス

ワークアラウンド

根拠

脆弱

なし

RFC6167

脆弱なし

RFC7568
POODLE攻撃

TLS

1.0

1.1

1.2

1.3

Renegotiation機能を利用しない

RFC5746

圧縮機能を利用しない

CRIME攻撃1/n-1分割法

BEAST攻撃

リスク受容

Lucky13攻撃問題はあるが回避策あり（ただし回避策がないものもある）

圧縮機能を利用しない

CRIME攻撃

リスク受容

Lucky13攻撃問題はあるが回避策あり

圧縮機能を利用しない

CRIME攻撃

暗号モードとしてGCM, CCM
のみを利用

Lucky13攻撃問題はあるが回避策あり（ただし回避策がないものもある）

安全に設計したと信じられている© 2019 Internet Initiative Japan Inc.

11

2018年9月 TLS1.0/1.1排除の初動• SSL3.0などと同様の die-die-die ドラフト発行– https://tools.ietf.org/html/draft-ietf-tlsoldversions-deprecate– “Deprecating TLSv1.0 and TLSv1.1”– 移行状況に関する数値的根拠も紹介されている（-00 draft：Webサーバの対応状況は以下の通り）© 2019 Internet Initiative Japan Inc.

12

世の中のバージョン移行動向
https://www.ssllabs.com/ssl-pulse/• 毎月レポートが発出– プロトコル種別などの先月との差分表示

参考：K. Urushimaさん http://blog.livedoor.jp/k_urushima/archives/1786599.html© 2019 Internet Initiative Japan Inc.

13

2018年10月 TLS1.0/1.1排除の本格化• 主要ブラウザベンダーが同時に2020年前半に無効化するアナウンス– Chrome, Edge/IE, Firefox, Safari

https://blogs.technet.microsoft.com/jpsecurity/2018/10/16/tlsdeprecation/© 2019 Internet Initiative Japan Inc.

14

TLS1.3の登場• メジャーアップデート– 新しい暗号アルゴリズムへの移行– 0-RTTによる高速処理可能なシーケンス• ガイドラインとの整合性を再検討– ３つのシチュエーションを想定するもブラウザ-サーバという環境のみを想定• TLS1.3実装状況と– TLS1.1以下の排除が加速する→考えていたよりも早い移行が予想される• 緩やかなSHA-3移行とはタイムラインが異なる© 2019 Internet Initiative Japan Inc.

15

TLS1.3 仕様の過去の参照先• ドラフト更新の経緯を参照可能– https://tools.ietf.org/html/draft-ietf-tls-tls13• IETFとは異なるリポジトリで頻繁に更新– https://tlswg.github.io/tls13-spec/© 2019 Internet Initiative Japan Inc.

16

過去の議論を観るには？
• Github– https://github.com/tlswg/tls13-spec/issues• IETF meeting– https://tools.ietf.org/agenda/105/• 年3回のIETF meeting．次回は7月末のIETF-105• TLS WGだけでなくsecdispatch WGやQUIC WG
さらにセキュリティ横断的にCFRG等でもTLS関連
技術が議論されるため要チェック© 2019 Internet Initiative Japan Inc.

17

フォーマルメソッドで設計中のプロトコルの穴を見つける• 米山一樹，セキュリティプロトコル安全性検証の理想と現実， CRYPTRECシンポジウム
2016– https://www.cryptrec.go.jp/symposium/201606
27_invited1.pdf• レピダムBlog, 祝RFC！Transport Layer
Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～– https://lepidum.co.jp/blog/2018-1001/tls1_3security/© 2019 Internet Initiative Japan Inc.

18

TLS1.3 における再設計© 2019 Internet Initiative Japan Inc.

19

懐かしいね2011年はCBCモードの当たり年• 9月：BEAST攻撃（CVE-2011-3389）– SSL 3.0/TLS 1.0 を使用しているブラウザの CBC モードに対して選択
平文攻撃を行うことでブラウザ内の Cookie を入手するツールを公開– ブロックごとではなくバイトごとの全数検索だとうまくいく例を示し，実際にPayPalからのセキュアなCookieを奪取してログイン権限を不正に得るというデモを公開• 10月：XML暗号化仕様– Webサービスの実装物をplaintext validity oracle として利用– XML Parser のエラーの意味を解釈しながらトライ＆エラー• 12月：TLS1.2における Truncated HMAC利用時の問題– RFC6066で規定された拡張機能のひとつであるTruncated HMACを用いたTLS1.2通信における脆弱性が公開– 通常のHMACではなく、80ビットに切り詰めたデータをMAC(データの完全性を保証する認証子)として利用する拡張方式の原理的な問題© 2019 Internet Initiative Japan Inc.

20

CRIME攻撃（2012年9月）• SSL/TLSでCompression(圧縮)機能を有効にしているケー
スでCookie を搾取するデモが公開• 例え同じ長さのデータを圧縮したとしても，圧縮前に同じ文字を含むかどうかで辞書の長さが変わるという事実を用いてトライ＆エラーで暗号化データを復元する

Lucky13攻撃（2013年2月）• SSL/TLSへのタイミング攻撃．演算速度の違いから情報を搾取するサイドチャネル攻撃の１種をネットを介して行う手法• CBCモードを使わない，もしくはMACとしてHMAC-SHA1な
どではなくAEAD(暗号化と認証子付与を同時に行う方式)を用いる．例えば GCMモードやCCMモードなど．

© 2019 Internet Initiative Japan Inc.

21

2013年の問い「CBCを捨てますか？」• 単純な対策方法：CBCを使わない– Lucky13（2月5日）の風潮：RC4使おう！
• Lucky Thirteen: Breaking the TLS and DTLS
Record Protocols• http://www.isg.rhul.ac.uk/tls/Lucky13.html• しかしRC4も死亡（3月13日）• Breaking the TLS and DTLS Record Protocols• http://www.isg.rhul.ac.uk/tls• AEADの普及率が課題…
代替手段があるかどうか？＋相互接続性を確保できるか？
2013年3月 第3回神保町暗号ワークショップ 「ＣＢＣモードの現在（いま）～ＣＢＣモードに何が起こっているか？」© 2019 Internet Initiative Japan Inc.

22

ちょっと面白そうな論文

https://www.usenix.org/conference/usenixsecurity19/presentation-21© 2019 Internet Initiative Japan Inc.

23

https://github.com/RUB-NDS/TLS-Padding-Oracles/blob/master/TlsPaddingOracleScanning.pdf© 2019 Internet Initiative Japan Inc.

24

https://github.com/RUB-NDS/TLS-Padding-Oracles© 2019 Internet Initiative Japan Inc.

25

これあれやん（CVE-2019-1559）•

OpenSSL Security Advisory [26 February 2019]0-byte record padding oracle (CVE-2019-1559)============================================• Severity: Moderate• If an application encounters a fatal protocol error and then calls
SSL_shutdown() twice (once to send a close_notify, and once toreceive one) then OpenSSL can respond differently to the calling
application if a 0 byte record is received with invalid padding
compared to if a 0 byte record is received with an invalid MAC. If theapplication then behaves differently based on that in a way that is
detectable to the remote peer, then this amounts to a padding oracle
that could be used to decrypt data.
• In order for this to be exploitable "non-stitched" ciphersuites must be
in use. Stitched ciphersuites are optimised implementations ofcertain commonly used ciphersuites. Also the application must call
SSL_shutdown() twice even if a protocol error has occurred(applications should not do this but some do anyway).

AEAD ciphersuites are not impacted.

https://www.openssl.org/news/secadv/20190226.txt© 2019 Internet Initiative Japan Inc.

26

Rev重ねるごとに落選していく• draft-02– Remove custom DHE groups.
– Remove support for compression.
– Remove support for static RSA and DH key
exchange.
– Remove support for non-AEAD ciphers.

• draft-03– Remove the unnecessary length field from the AD
input to AEAD ciphers.

• draft-06– Prohibit RC4 negotiation for backwards compatibility.
https://tlswg.org/tls13-spec/draft-ietf-tls-tls13.html© 2019 Internet Initiative Japan Inc.

27

• draft-07– Integration of semi-ephemeral DH proposal.
– Remove resumption and replace with PSK + tickets.
– Move to HKDF.

• draft-08– Remove support for weak and lesser used named
curves.
– Remove support for MD5 and SHA-224 hashes withsignatures.

© 2019 Internet Initiative Japan Inc.

28

• draft-09– Change to RSA-PSS signatures forhandshake messages.
– Remove support for DSA.
– Deprecate SHA-1 with signatures.

• draft-11– Port the CFRG curves & signatures work from
RFC4492bis.
© 2019 Internet Initiative Japan Inc.

29

2016年1月の時点の様子• https://tlswg.github.io/tls13-spec/#rfc.appendix.A.4

TLS_（鍵共有） _（署名） _（AEADのアルゴリズム） _（ハッシュ関数）© 2019 Internet Initiative Japan Inc.

30• draft-13– Require DH public keys and secrets to be
zero-padded to the size of the group.

• draft-14– Define ecdsa_sha1 (*).

• draft-15– Remove old PRNG text.

© 2019 Internet Initiative Japan Inc.

31• draft-16– Change RSASSA-PSS and EdDSA
SignatureScheme codepoints for better
backwards compatibility (*)• draft-23– Add some text on the security of static RSA.

© 2019 Internet Initiative Japan Inc.

32

共通鍵暗号• DESはTLS1.2で既に排除済み• RC4についてもRFC7465が2015年2月に発行されたことを受けて排除済み• CBC暗号モード排除．共通鍵暗号としては
AEAD（Authenticated Encryption with
Associated Data）のみの利用に統一– ChaCha20-Poly1305がAES-GCMと並んで実装必須（Mandatory Algorithms）© 2019 Internet Initiative Japan Inc.

33

ハッシュ関数• MD5, SHA-224 を排除（MUST NOT）
• SHA-1 は SHOULD NOT– 後方互換性のためのSHA-1サポート• 特にSHA-1署名での証明書検証はサポート© 2019 Internet Initiative Japan Inc.

34

CipherSuitesの簡略化• ５つのCipherSuitesのみを規定– （これまでのCipherSuitesと同じ呼び方でいいのか？）• これまでの反省のもと「記載」をかなり簡略化

MUST
SHOULDSHOULD

TLS_（AEADのアルゴリズム）_（ハッシュ関数）© 2019 Internet Initiative Japan Inc.

35

IANAで規定の各種パラメータ

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml© 2019 Internet Initiative Japan Inc.

36

CCM_8_SHA256 推奨の変化

Internet Engineering Steering Group
Area Director of Security Area

https://www6.ietf.org/iesg/minutes/2018/minutes-2018-08-16.txt© 2019 Internet Initiative Japan Inc.

37

署名・鍵交換• DSA排除（ただし現時点で脆弱ではない）して
ECDSA利用に完全シフト• もちろん署名としてはECDSAだけではなく
RSA-PSSも利用可能• 一方で鍵交換に使われるDHは排除されることなく
ECDHと共に残留• 毎回異なる鍵（Ephemeral keys）を生成する
Forward secrecy を満たす方式のみ© 2019 Internet Initiative Japan Inc.

38

1軍（電子政府推奨暗号リスト）• いずれもリストに掲載されており安全であると認識されている• レガシーな暗号であるという論理だけで移行が進められているという問題がある（私見）– 傷もついていないのに…
© 2019 Internet Initiative Japan Inc.

39

MUST for certificates

MUST

MUST for CertificateVerify and certificates

Edwards曲線上の Schnorr 署名ライクな EdDSA© 2019 Internet Initiative Japan Inc.

40

MUST
SHOULD

secp256r1, secp384r1, secp521r1: Standards for Efficient Cryptography Group,
SEC 2: "Recommended Elliptic Curve Domain Parameters“ http://www.secg.org/sec2-v2.pdf
x25519, x448：”Elliptic Curves for Security”, https://datatracker.ietf.org/doc/rfc7748/© 2019 Internet Initiative Japan Inc.

41

脱線（本日3回目）• これ使っていいかよーわからん• Bitcoin署名時のPRNG空間の狭さでノンス使いまわして奪取問題．これが対策のひとつ．

© 2019 Internet Initiative Japan Inc.

42

Post Quantum な暗号ライブラリ© 2019 Internet Initiative Japan Inc.

43

いくつかの先駆的な取り組み• Microsoft Research, Open Quantum Safe library– https://github.com/open-quantum-safe/– https://qtesla.org/• Google, Post-quantum confidentiality for TLS– https://www.imperialviolet.org/2018/04/11/pqconftls.ht
ml• CloudFlare, Introducing CIRCL: An Advanced
Cryptographic Library– https://blog.cloudflare.com/introducing-circl/© 2019 Internet Initiative Japan Inc.

44

https://csrc.nist.gov/news/2019/pqc-standardization-process-2nd-round-candidates© 2019 Internet Initiative Japan Inc.

45

じゃあ軽量暗号はTLSに載る？
• 現時点では正直わからんけど…
「最小実装」プロファイルとかなら？
• Light-Weight Implementation Guidance(LWIG)© 2019 Internet Initiative Japan Inc.

46

あとはRFC8387は読もうかね© 2019 Internet Initiative Japan Inc.

47

常時SSL（Always On SSL）への対応

マーケティング用語？
© 2019 Internet Initiative Japan Inc.

48

PRISMhttp://en.wikipedia.org/wiki/Global_surveillance_disclosures_(2013%E2%80%93present)© 2019 Internet Initiative Japan Inc.

49

IETF 88 – Pervasive Surveillance

http://www.youtube.com/watch?v=oV71hhEpQ20© 2019 Internet Initiative Japan Inc.

50

起点はおそらくスノーデン• 全部暗号せな なにもかも抜かれてしまうで．
• せや！全ての通信を暗号化したらええやん．
• でも，それTLSじゃなくてよくね？
– E2E的）IPsecなどの より下のレイヤでカバー– C2C的）S/MIME, GnuPGなどでカバー© 2019 Internet Initiative Japan Inc.

51

日本がフルボッコにあったから？
（もしそうなら消極的では？）

https://www.youtube.com/watch?v=toaR0uSabK8© 2019 Internet Initiative Japan Inc.

52

（私見）無理しないでいいよ© 2019 Internet Initiative Japan Inc.

53

思うところは…
• 日本的な「しなやかさ」で対応できないか– 必要なところだけ使っているサイトが多い• そういう意味では数値は実態を表していない• つまりアンフェア• 別観点ではサプライチェーンが信用できないのであれば「国産」であることも導入要因に？

© 2019 Internet Initiative Japan Inc.

54

TLS_*_anon_WITH_*• 暗号化ONLY CipherSuitesの復活は？
– TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA• と思ったら同じこと考えてるヒト居た（嬉）

https://datatracker.ietf.org/doc/draft-camwinget-tls-ts13-macciphersuites© 2019 Internet Initiative Japan Inc.

55

証明書・PKIとユーザインターフェイス© 2019 Internet Initiative Japan Inc.

56

1-to-1ではない証明書の是非• ワイルドカード証明書– ネットワークトポロジによっては管理コスト低下• マンション証明書– 異なる組織のFQDNがSANに共存している• IPアドレス証明書– SANに含めた証明書事例：1.1.1.1 (DNS界隈)© 2019 Internet Initiative Japan Inc.

57

マンション証明書
Subject Alternative Name

• 異なるドメイン名がSANに共存している証明書

VPSでお隣のVMに入居してる人の顔を知らない状況とよく似てる
https://censys.io/certificates/2843400699468ff9439c3ec89c3ee475d8d6ae9d1ca4107cad94d54b112c5e8f© 2019 Internet Initiative Japan Inc.
VPS: Virtual private server 58

多様な接続形態・NWトポロジー• VPSの利用• ロードバランサによる負荷分散– 鍵の配備位置問題– 複数の鍵を別に置くことのリスク• IoTなどミニマムセットでの利用© 2019 Internet Initiative Japan Inc.

59

マンション証明書のリスク• 異なる組織が同じ鍵ペアを利用している– 理論的にはお隣さんのTLSトラフィック読める？
• SNIの仕組みとかVMの独立性に依存しそう– そもそも VPSベンダーが鍵生成してるから…
– go.jp でもマンション証明書を保持してるFQDNあり• 自分で調べたサービスは秘密鍵がぶっこ抜けないようになってた– （いや，そこは本質じゃない）© 2019 Internet Initiative Japan Inc.

60

リモート鍵とかHSMとかで解決？
• ネットワークトポロジで分類できそう• リモート：鍵が必要になった時点で問い合わせ– レスポンスできる？
– そもそもVPS借りてる意味は？

• 物理的なHSMを預ければいいのかい？
– コスト高いわ，物理配送が必要で即時開通できん© 2019 Internet Initiative Japan Inc.

61

あらゆることが原因で
EVSSL証明書が泣いている事例たち• Mixed-Content• 証明書OID処理バグ• クロスルート証明書 ← new!
– フィーチャーフォン等のレガシー対応とも関連© 2019 Internet Initiative Japan Inc.

62

EVSSL証明書の再考• 2017年7月 Janog40 meeting の資料から– 当時はまだグリーンバーによるメリットがあった© 2019 Internet Initiative Japan Inc.

63

別のEVSSL証明書 不活性問題
ルート証明書
ルート証明書[EV]中間CA１[EV]中間CA2[EV]

ブラウザのトランスアンカーに入っている

同じ名前でルート証明書でない「クロスルート証明書」と呼ばれる中間CA証明書(1)が存在するという状況

サーバ証明書© 2019 Internet Initiative Japan Inc.

64

別のEVSSL証明書 不活性問題
ルート証明書
ルート証明書[EV]中間CA１[EV]

ブラウザのトランスアンカーに入っている

中間CA2[EV]SSL/TLS接続した際にサーバから
この２枚の証明書を送りつける場合はセーフ
サーバ証明書© 2019 Internet Initiative Japan Inc.

65

別のEVSSL証明書 不活性問題
ルート証明書
ルート証明書[EV]中間CA１[EV]

ブラウザのトランスアンカーに入っている

中間CA2[EV]SSL/TLS接続した際にサーバから
この３枚の証明書を送りつける場合はアウト
サーバ証明書本来な左の にパスが伸びる実装が素直では？
© 2019 Internet Initiative Japan Inc.

66

これフィーチャーフォン対策でした
ルート証明書
ルート証明書[EV]✕中間CA１[EV]中間CA2[EV]• 中間CA1を送らないとルート証明書までのパスを辿れない• 泣く泣くEV不活性にしている実情• ある業界：10 / 55

サーバ証明書© 2019 Internet Initiative Japan Inc.

67

信頼点の変更による影響© 2019 Internet Initiative Japan Inc.

68

信頼点って重要だと知らされた事例• あんまりなにもいいません© 2019 Internet Initiative Japan Inc.

69

ステークホルダーの関係
CAベンダー
イイモノを選択（証明書ストア・審査）

B
A/
C

証明書購入
（ある意味イイモノを選択）

ro
se
w
um
or
rF

プロモーション
EV証明書販売促進
コンテンツ制作
コンテンツ
HTTPSサーバ
ホルダー
業務委託
サーバ運用
（ある意味イイモノを選択）

ブラウザベンダー
サービス提供アクセス（ある意味イイモノを選択）

利便性提供

イイモノを選択ユーザ© 2019 Internet Initiative Japan Inc.

70

閉域での証明書利用の是非• 信頼点が突然変わるケース：
基本的にはCAがポカしたとき• 利用形態によってはプライベート証明書を許諾することもあるのだろうか？

© 2019 Internet Initiative Japan Inc.

71

閉域での証明書利用の是非• 信頼点が突然変わるケース：
基本的にはCAがポカしたとき• 利用形態によってはプライベート証明書を許諾することもあるのだろうか？
• もう一つの観点：CTとプライバシ© 2019 Internet Initiative Japan Inc.

72

Certificate Transparencyの課題• CTの仕組みにより証明書発行すると
FQDNがバレる– JANOG40で紹介した Censys 等で簡単に念のため自主規制– https://censys.io/certificates?q=%28%22.＊＊
念のため自主規制
念のため自主規制%22+and+parsed.validity.start%3A+%5B
念のため自主規制
2019-07-01+TO+*%5D%29+AND+tags
念のため自主規制
念のため自主規制%3A+%22ev%22
https://www.janog.gr.jp/meeting/janog40/program/censys© 2019 Internet Initiative Japan Inc.

73

Predictions© 2019 Internet Initiative Japan Inc.

74

POSITIVE• Decentralized PKIの普及– https://github.com/WebOfTrustInfo/rwot1sf/blob/master/draft-documents/
Decentralized-Public-Key-InfrastructureCURRENT.md• Self-sovereign Identity (Management) から
Self-sovereign Key Management へ– 暗号資産の鍵管理をユーザ自らの手に© 2019 Internet Initiative Japan Inc.

75

NEGATIVE• 正常系では動作するTLS1.3 Clientは– 相変わらず証明書検証無視• 新署名アルゴリズム対応でエラー処理時に起こりそう– TLS1.2 ClientHello extensionとの互換性確保が仇となる実装ミス• 同じ用語で異なる意味・エンコーディング• DNS over TLS, DNS over HTTPS も結局信じられない世界が来るかも– 結局手元のツール・U/I をどう信じるか• CT（Certificate Transparency）とプライバシ© 2019 Internet Initiative Japan Inc.

76

TLS1.3 への移行に際して© 2019 Internet Initiative Japan Inc.

77

TLS1.3実装状況
https://github.com/tlswg/tls13-spec/wiki/Implementations

fizz
NSS
Mint

languagrole(s) version
e
C++
C/S
-28
C
C/S
RFC 8446
Go
C/S
-18

nqsb

OCaml C/S

name

ProtoTL JavaScri
C/SS
pt
miTLS F*
C/S
Tris
Go
C/S
BoringSC
C/SSL
WiresharCotherkpicotls C
C/SrustlsRust

C/S

Haskell
Haskell C/S
tls
Leto
C#
S
OpenSSC
C/SL
wolfSSL CC/SGnuTLS C

C/Stlslite-ng Python C/SC-11

features/limitations

Based on libsodium, includes secure design abstractions. Zero-copy for advanced perform
Almost everything, except post-handshake auth and X448
PSK resumption, 0-RTT, HRR
PSK/DHE-PSK, no EC*, no client auth, no 0RTT -- live server at tls13test.nqsb.io port 443
ping @hannesm, contains a static PSK/DHE_PSK token: id: 0x0000secret:-13

EC/DHE/PSK, no HelloRetryRequest

RFC 8446
RFC 8446-23, -28, RFC
8446-18 to -28, RFC
8446-18,-21,-23,-26-28 (final on
branch)EC/DHE/PSK/0-RTT, no RSA-PSS, no post-HS-auth, no ESNIECDHE/PSK/0-RTT, no HelloRetryRequest-28

ECDHE w/ P* and X*, full, HRR, PSK, 0RTT

-18

P-256, X25519, HelloRetryRequest, resumption, 0-RTT, KeyUpdate

Full decryption and dissection support for drafts 19-21 since 2.4.0 (keylog format). Suppo
since 2.4.3, -23 since 2.4.5, -24 to -28 (+0RTT trial decryption) since 2.6.0. Tracking bug
P-256, X25519, HelloRetryRequest, resumption, 0-RTT
P-256/P-384/curve25519, HRR, resumption, 0-RTT client

DHE, X25519, AES, no PSK no 0RTT. Tested against NSS
P-256, P-384, P-521, X25519, X448, Ed25519, Ed448, HelloRetryRequest, resumption, P
RFC 8446
stateless server, Post-handshake auth, KeyUpdate, RSA-PSS certs, no FFDHE-18/-22/-23/-26/- P-256, P-384, X25519, Ed25519, HelloRetryRequest, resumption, PSK, 0-RTT, CCS, coo
28
Post-Handshake Auth, KeyUpdate-28
P-256, P-384, X25519, FFDHE, RSA-PSS (keys and certs), HelloRetryRequest, KeyUpda
ECDHE (all), EdDHE (X25519, X448), FFDHE (all), AES-GCM, Chacha20, HelloRetryReq
RFC 8446
and certificate signatures, cookie extension, CCS, PSK, resumption, no ECDSA certificate
78© 2019Internet
Initiative (x25519,
Japan Inc. X448), FFDHE (all), AES-GCM, Chacha20, RSA, HelloRe
ECDHE(all),EdDHE

実装調査のポイント• クライアント側（ブラウザ）の実装状況に依存したサーバの選択が必要• ブラウザでは以下のようにOpenSSL, BoringSSL,
NSS などの暗号ライブラリが内部で利用されている– Microsoft IE/Edge– Chrome– Firefox– OperaWindows CNG (CAPI)
BoringSSL
NSS
Chromeベースでの実装に移行© 2019 Internet Initiative Japan Inc.

79

TLS1.3ライブラリはRFC8446ではなくInternetDraft（中途）版も存在• 先に挙げたライブラリ群は対応済のものが多いが，未実装の機能・アルゴリズムもあるので注意
BoringSSL

Open
SSL

NSS

-23, -28,
RFC 8446

RFC
8446

RFC 8446

P-256, X25519,
HelloRetryRequest, resumption,
0-RTT, KeyUpdate

P-256, P-384, P-521,
X25519, X448, Ed25519,
Ed448, HelloRetryRequest,
resumption, PSK, 0-RTT, CCS,
cookies, stateless server,
Post-handshake auth, KeyUpdate,
RSA-PSS certs, no FFDHE
Almost everything, except post-handshake auth and X448

© 2019 Internet Initiative Japan Inc.

80

参考：TLS1.3サーバ構築の一例• 2017年5月 OpenSSLでの構築方法公開– https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/– 設定の注意点など細かい内容まで記載• 2018月9月11日 OpenSSL1.1.1リリースで正式サポート– https://www.openssl.org/blog/blog/2018/09/11/release111/• 2018年10月Apache 2.4.37 リリース
mod_ssl で OpenSSL1.1.1対応– https://httpd.apache.org/download.cgi– enable-tls1_3 フラグでコンパイルすることで簡単に構築可能© 2019 Internet Initiative Japan Inc.

81

参考：Apache2.4系での拡張ログ対応
https://httpd.apache.org/docs/current/mod/mod_ssl.html#logformats• クライアントがどのバージョン，CipherSuites
で接続されたかを別のログファイルに追記

その他様々な情報を残すことが可能→© 2019 Internet Initiative Japan Inc.

82

まとめに代えて• 実態に即したガイドライン発行を目指したい．
そのためには多くの皆様のご意見を頂戴できればと思います．
• 本当に世の中で役立つアクティビティでありたいので戦うときは戦うという姿勢で．

© 2019 Internet Initiative Japan Inc.

83

お問い合わせ先 IIJインフォメーションセンター
TEL：03-5205-4466 （9：30～17：30 土/日/祝日除く）
info@iij.ad.jp
http://www.iij.ad.jp/© 2019 Internet Initiative Japan Inc.

84