幅広い環境でSSL対応するために知っておくべきこと

- SSL関連の障害がなぜ起きてしまうのか？
- 何で対応端末が変わるのか
- 何をすれば障害を防げるのか？
- SSL対応するためにどういう体制を組んでいたらいいのか？

おことわり: 社内向け勉強会のスライドを再編集したものです。社外向けに割愛した結果、ちぐはぐになっている部分があります。

Transcript

1. SSL対応のために
 知っておきたいこと
 あらゆる環境でSSL対応するには

2. おことわり
 • このスライドは社内で発表したものを再編集したものです • 当たり障りのないスライドのみ残しているためチグハグになっていま す
3. 想定聴者
 • 応用情報技術者ぐらいの知識を持っている人 ◦ 共通鍵暗号、公開鍵暗号、デジタル署名、デジタル証明書 の雰囲気 を知っている • SSL証明書を何かしら使ったことがある人
4. 今回の勉強会のテーマ
 • SSL関連の障害がなぜ起きてしまうのか？ ◦ 何で対応端末が変わるのか • 何をすれば障害を防げるのか？ • SSL対応するためにどういう体制を組んでいたらいいのか？ 今日はググっても出てこない話を中心にします
5. 何が対応端末を左右するのか
 • 技術的な話 ◦ 証明書の種類 (RSA/ECDSA) ◦ TLSのバージョン Cipher Suite (暗号通信のやり方) ◦ SNI • 人間的な話 ◦ ルート証明書 (証明書の調達先) ググったら出てくる
6. 技術的な話
 • だいたい定石があります • いつも同じことをしていたらあまりトラブ ルにはなりません • 他人のマネも容易です ◦ RSA/ECDSA ◦ TLS Version, Cipher Suite ◦ SNI
7. 人間的な話
 • 業界動向で世界が一変します ◦ 極端な話「好き」とか「嫌い」とかで決まりま す • 証明書は定期的に変えなければなら ないため強制的に追従させられます ◦ ルート証明書
8. 技術的な話

9. TLSのネゴシエーション概要
 TLS(SSL)のネゴシエーション で、通信先の認証と暗号通信 のやり方の決定が行われる Client Server サーバ証明書, TLS Version, Cipher Suite 決定 接続開始要求 TLS Version, 対応Cipher Suites 一覧 暗号鍵交換 交換した鍵で暗号通信 (例: HTTP) (共通鍵暗号... AESなど) ネゴシエーション TLS HTTP IP, TCP
10. TLSネゴシエーション時にホストは分からない
 • TLSのネゴシエーション時にはホスト名が分からない • TLSネゴシエーション後、HTTP通信をしはじめて初めて HTTP Host ヘッダとしてサーバに渡される TLS HTTP IP, TCP
11. https://www.google.com/ にアクセスするときの例
 クライアント(ブラウザ)から見ると… 1. www.google.com をDNS解決する 2. (1) の IPアドレスに対し TLSネゴシエーション要求 3. サーバからSSLサーバ証明書が送られてくる a. “*.google.com” を名乗るサーバ証明書が来る 4. 接続しようとしているのは www.google.com で証明書と一致 しているので OK
12. 1つのIPアドレスで2つ以上の証明書を使うときに困る
 • 1つのIPアドレスには複数の証明書 を使うことはできない • どの証明書を返せばいいか分から ないため サーバ 証明書1 *.aaa.example 証明書2 *.bbb.example クライアント 接続要求 ？？？ SSL証明書1つに対し 最低1つIPアドレスが必要
13. SNI拡張
 • 接続要求時にホスト名を送信する 拡張仕様 • サーバはホスト名がわかるので適 切な証明書を送ることができる IPアドレスを節約できる サーバ 証明書1 *.aaa.example 証明書2 *.bbb.example クライアント 接続要求 + ホスト名 ホスト名に あった証 明書を送 る ただし拡張のため対応していない環境があることに注意 (例: Android 2.3未満, 旧バージョンのScala Play WSなど) 意外と対応していないクライアントは多い
14. TLSバージョン
 • TLS1.0, 1.1 はオワコンにさせようという動きがある • が、気にせず TLS1.0〜1.2 をサポートしていたら良い ◦ 中間者により低いバージョンを使わせる攻撃を回避する拡張がある (TLS_FALLBACK_SCSV) ◦ 極めて秘匿性の高い情報をやり取りする場合は別途検討 • TLS1.2 only にすると Android 4.xの一部等がサポート外に なる可能性がある ◦ あくまで 1.0, 1.1 は deprecated な扱いで運用する
15. Cipher Suite (暗号通信のやり方)
 以下の組み合わせ。暗号通信の技術的安全性を左右する ネゴシエーション時のサーバ負荷も変わる • どうやって鍵を交換するか (鍵交換アルゴリズム) ◦ RSA, DHE_RSA, ECDHE_RSA 等 • 共通鍵暗号に何を使うか ◦ AES-128-GCM 等 • メッセージ認証アルゴリズムに何を使うか ◦ HMAC-SHA-256 等
16. Cipher Suite の詳細を知りたい
 語り始めるとそこだけで2時間かかるので割愛！ 次の本 (無料でPDFあり) を読むのがおすすめ 『クラウドを支えるこれからの暗号技術』 https://herumi.github.io/ango/ Cipher Suite の意味を知るには 第1部 で十分です
17. Cipher Suite を決める上で注意すること
 • 低セキュリティなものしか対応していないパターン ◦ 古い環境など ◦ 例: Windows XP IE8, Java7, ... • 高セキュリティなものしか対応していないパターン ◦ 意識が高い環境など ◦ 例: Apple ATS (iOS)
18. 高セキュリティなものしか対応していないケース
 • Apple は秘匿性の高いCipher Suiteでしか通信させないよう にしている (ATS: App Transfer Security) ◦ ECDHE という鍵交換方式のサポートを必須としている • 「低セキュリティなものを追加してはいけない」というわけでは ない https://developer.apple.com/jp/security/
19. Cipher Suite の選定基準
 • Cipher Suite はサーバ側で優先度を決められる • サーバ負荷の問題ない範囲で、高セキュリティなものを優先 度高く設定 • 脆弱と言われているアルゴリズムは外す ◦ 時代によって変わる… • 広いデバイスに対応するなら、たくさん設定する
20. 結局何を設定したらいいの？
 もうGoogleをパクれ！ https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&s=216.58.194.196&hideResults=on
21. 結局何を設定したらいいの？
 
 • Google で採用している Cipher Suite を基準にする • Google はかなり広い環境に対応するような Cipher Suite を 設定している • よく考えると広い環境に対応しないといけないのは大体 Google が悪い気がするし一番 Google が困ってる ◦ Android のあらゆるバージョンが世の中にはびこっているため
22. 証明書の種類

23. RSA/ECDSA証明書
 • デジタル署名を実現するアルゴリズムが違う ◦ 環境によっては ECDSA のほうがサーバ負荷が少なかったりする • RSAに対応していない環境はない (たぶん) • ECDSAを選択するならそれなりの覚悟で選ぶ ◦ RSA証明書も同時に調達し、2つ設定するなどの対応が必要 ◦ 周りは誰も助けてくれません • 詳しくないなら絶対に RSA を選択する
24. (参考) 証明書の持つ機能
 ↓このあたりは環境によるトラブルを聞いたことはないです • ワイルドカード証明書 • SANs証明書 (マルチドメイン証明書) • SANsワイルドカード証明書 ※ガラケーは不明
25. ルート証明書と
 証明書ベンダー

26. 証明書の中身
 こんなことが書いてある • どのFQDNを認証したのか • 誰によって認証されたのか (発行者)
27. SSL証明書の構造 (信頼チェーン)
 OSにプリインストールされている ルート証明書 中間証明書 サーバ証明書 署名 クライアントに送信する必要がある 署名
28. SSL証明書の構造 (信頼チェーン)
 GlobalSign Root CA GlobalSign Organization Validation CA サーバ証明書 署名 この組み合わせをクライアント(ブラ ウザ等)に送信する 署名 ブラウザは GlobalSign Root CA を信 頼している ので サーバ証明書を信用す る
29. 中間証明書の設定忘れ
 中間証明書 サーバ証明書 ここだけをクライアントに送ると…？ 署名 ブラウザからすると知らない人に署名されている サーバ証明書となり 信頼できない証明書として拒絶してしまう※
30. 環境によってプリインストール内容は異なる
 ルート証明書をプリインストールするかしないかはそれぞれのOS/ ブラウザベンダーが独自のポリシーで判断している ルート証明書の例 Windows 10 macOS 10.13 Android 4.x Android 5.x Baltimore CyberTrust Root ◦ ◦ ◦ ◦ Cybertrust Global Root ◦ ☓ ◦ ◦ DigiCert Global Root CA ◦ ◦ ◦ ◦ Security Communication RootCA1 ◦ ◦ ◦ ◦ GlobalSign Root CA1 ◦ ◦ ◦ ◦ GlobalSign Root CA5 ◦ ◦ ☓ ◦
31. ルート証明書を信頼するかどうか
 • OSで管理するパターン (だいたいこっち) ◦ Safari, IE, Chrome • アプリケーションで独自に管理するパターン ◦ Firefox, Java
32. 一部の環境のみ対応したルート証明書を利用する場合
 macOS上では ルート証明書A を信頼していないため オレオレ証明書と同じ状態となる (拒絶する) ルート証明書A Windows OK, macOS NG サーバ証明書 中間証明書 Windows OK, macOS NG クライアントに送信
33. クロスルート
 幅広い環境に対応するためにさらに別のルート証明書に署名 してもらった証明書を送信する ルート証明書A Windows OK, macOS NG サーバ証明書 中間証明書 ルート証明書B Windows OK, macOS OK 署名 署名 署名 クライアントに送信
34. クロスルートの具体例
 (社内のみ)
35. ルート証明書は当たり前のように変わる
 なぜ？ • 計算能力の向上や暗号技術の進化 ◦ 例) SHA-1 の危殆化、SHA-256 への移行 ◦ 例) RSA 1024bit の危殆化 ◦ 例) ECDSA の導入 • ルート認証局が信頼できなくなった • 鍵の危殆化防止 • 業界内でのいざこざ ルート証明書は長期に渡り入れ替わっていくことを前提としている。 永久に利用できるルート証明書は存在しない。
36. ルート証明書更改の具体例
 (社内のみ)
37. ルート証明書のインストール状況
 親切なところはリストを公開している • List of available trusted root certificates in iOS 13, iPadOS 13, macOS 10.15, watchOS 6, and tvOS 13 - Apple Support : https://support.apple.com/en-us/HT210770 • Microsoft : https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT • EZwebブラウザに搭載されているルート証明書 https://www.au.com/ezfactory/web/
38. クロスルートによる更改リスクの回避
 • 証明書ベンダーがルート証明書を更改するとき、互換性を維 持するための通常クロスルートがなされる • 「ルート証明書が変わって対応デバイスが変わった！」という ときは、まずはクロスルート証明書を探す
39. SSL証明書は既得権益
 • 広いデバイスで採用されているルート証明書を持っている会 社が圧倒的に強い • そもそもSSL証明書はどのように販売されているのか？
40. A社の証明書
 サーバ証明書 中間: A社の中間証明書 ルート: A社のルート証明書 サーバ証明書 サーバ証明書 A 社の管理 自社でルート証明書および秘密鍵を保持 しており、自社でサーバ証明書を発行する
41. B社の証明書
 サーバ証明書 中間: B社の中間証明書 ルート: C社の証明書 サーバ証明書 サーバ証明書 C社 (他社) の管理 B社の管理 B社は自身で中間証明書と秘密鍵を持っており、 自身のシステムで証明書を発行できる。 ただしルート証明書はC社が持っている
42. D社の証明書
 サーバ証明書 中間: E社の中間証明書 ルート: E社のルート証明書 サーバ証明書 サーバ証明書 E社の管理 D社は E社のシステムを使って サーバ証明書を代理で発行し、顧客に提供する
43. Google社の証明書
 サーバ証明書 中間: GTS CA 1O1 ルート: GlobalSign Root CA (R2) サーバ証明書 サーバ証明書 Google 社の管理 (Google Trust Services) 自社でルート証明書および秘密鍵を保持しており、自社でサーバ証明書を発行する GlobalSign社からルート証明書を買収しサービス開始を実現 Google、自社向けのルート認証局「 Google Trust Services」を開設 -INTERNET Watch : https://internet.watch.impress.co.jp/docs/news/1041198.html
44. 業界動向のあれこれ
 (社内のみ)
45. 動作確認

46. SSLの「正しい設定」とは
 • 正しく設定しているか ◦ 中間証明書を設定しているかどうか ◦ 脆弱性がある設定になっていないか • 非対応端末が発生していないか ◦ ルート証明書をサポートしているか ▪ 必要に応じてクロスルート証明書を設定しているか ◦ TLS Version, Cipher Suiteをサポートしているか → 1端末で動作確認をしても意味がない
47. ややこしいブラウザ実装
 • 中間証明書の設定を忘れていてもブラウザによっては自動で ダウンロードする機能がある (らしい) ◦ キャッシュ機能もある？（らしい） • 「1ブラウザでの動作確認」は全く意味なし
48. 中間証明書を忘れた例 (再)
 (社内のみ)
49. Windows 10 Firefox
 (社内のみ)
50. Windows 10 Chrome
 (社内のみ) 正常動作
51. macOS 10.13 Firefox
 (社内のみ)
52. macOS 10.13 Chrome
 (社内のみ)
53. どうしてこうなったか
 環境 ルート対応 自動解決 (推測) 表示結果 macOS Chrome No Yes → NG macOS Firefox Yes No → NG Windows Chrome Yes Yes → OK Windows Firefox Yes No → NG ルート Windows/Firefoxのみ対応ルート サーバ サーバ証明書 中間 中間証明書 ルート 全環境サポートルート 署名 署名 署名 (クロスルート)
54. SSL Labs
 https://www.ssllabs.com/ssltest/analyze.html オンラインで SSL設定状況を確認できる
55. SSL Labs
 • 網羅的に確認可能 ◦ 脆弱性 ◦ 動作環境 • セキュリティレベルを「レー ティング」という形でわかりや すく提供 ◦ 時代にあわせてレーティングが 変わる
56. レーティングが高ければいいわけではない
 • 「安全に通信できる」という観点ではレーティングが高ければ 高いほど良い • ただ高くなるようにすると対応環境が減ることも
57. なんのためにSSL化するのか
 • 機密性のある情報をやりとりするため？ ◦ 漏れたときのリスクは？ • ブラウザ/業界の圧力に対応するため？ ◦ httpsでないと使えない拡張が増えてきたから？ • ユーザーイメージのため？ ◦ まだhttpsでないと笑われるから？ 総合的に考えてちょうどいい塩梅を探す (面倒ならGoogleをパクろう)
58. testssl.sh
 • SSL Labs はインターネットに露出しているサイトでないと使え ない • testssl.sh というローカルで実行できるものをおすすめ ◦ https://testssl.sh/
60. SSLLabs / testssl.sh の注意点
 • ルート証明書の確認は「最新環境」でしかなされない ◦ “Trusted: Apple” となっていても古い環境で信頼されていないケース も (例: https://good.r1demo.pki.goog/ ) • 逆にいうと 1個でも Not OK がある場合、ヤバい ルート証明書をサポートしているかは 対応したい環境で個別に確認するしかない
61. 体制

62. SSLはしくじれない
 • よくある「対応環境外」 ◦ 対応していなくても、デザインが崩れながらもサイトが見られる ◦ ユーザーへの告知をなんとか見せられる • SSLの「対応環境外」 ◦ ユーザーはそもそも一切接続できない ◦ 障害と同じ状態
63. なにに対応したいか？
 
 • いわゆる普通で新しいOS/ブラウザ/端末だけをサポートした い ◦ testssl.sh, SSL Labs に頼ればいい • 古いOS/ブラウザ/端末や特殊な環境もサポートしたい ◦ 十分な体制を組むべき
64. 古い環境でも対応する場合に組むべき体制
 複数のルート証明書で動作を事前に確認しておく 一方で対応できない場合はもう一方の候補に切り替える
65. 複数のルート証明書を候補にしておく
 いわゆるマルチベンダー的な話だけではない ルート証明書は必ず変わり続けるため対応は必ず発生する ある日突然革命が起きることも (社内のみ)
66. SSL証明書調達時
 • SSL証明書調達時には現在のルートが何かを確認する ◦ 公式サイトにのっている • RSA / ECDSA で異なることが多いので注意 ◦ 特に ECDSA は誰も使ってないため地雷になりがちなので注意
67. リスクを下げるために調達頻度を下げる？
 • SSL証明書の有効期限の長いものを変えばリスク発生頻度は 下がる • が、近年有効期限を短くしようとする動きがあるので 1年に1回は入れ替えられる体制を推奨 ◦ 技術上は有効期限はいくらでも伸ばせるが業界の動きで変わる ◦ 3年強 -> 2年強 (2018/03〜) -> 1年強案 (否決)
68. まとめ

69. まとめ
 • SSLは単純な「技術的なもの」ではない • 証明書の構造のとおり信頼の連鎖で成り立っている ◦ 信頼は人間的なもの • 対応環境を絞れないならそれなりの体制が必要 • ただしSSLにした時点で世の中の波に突っ込まれることは覚 悟する ◦ 古い環境を切り捨てる覚悟が必要
71. Appendix: 中間証明書の存在理由 (1)
 もちろんこの状態で発行してくれればサーバ 証明書だけ送信すれば信頼できる ルート証明書 サーバ証明書 署名
72. Appendix: 中間証明書の存在理由 (2)
 
 ルート証明書 有効期限: 〜20年 中間証明書 有効期限: 〜10年 サーバ証明書 有効期限: 〜2年 署名 署名 サーバ証明書の利用者が管理 ルート証明書の 秘密鍵 中間証明書の 秘密鍵 サーバ証明書の 秘密鍵 オフラインで保管する 極めて厳重に管理 (インターネットに接続した環境に置かない ) 証明書発行事業者のシステム内に管理 Web上でSSL証明書を発行できるようにする
73. Appendix: サーバ負荷 (1)
 チップの特性によって負荷傾向が大きく異なるため一概に言えない • 例: あるCPUでは性能は RSA < ECDSA となった • 例: ハードウェアロードバランサに高性能RSA処理チップを搭 載しているため、性能は RSA > ECDSA となった 試験をしない限り明確なことは言えない
74. Appendix: サーバ負荷 (2)
 
 TLSはネゴシエーション時に大きな負荷がかかる ネゴシエーション後はAESを紐解くだけのため軽い 2回目以降にネゴシエーションを避ける技術も (TLS Session Resumption) • TLS Session Id • TLS Session Ticket
75. Appendix: サーバ負荷 (3)
 HTTP 1 req = 1ネゴシエーション は最悪中の最悪ケース エンドユーザー向けでは絶対にありえないシチュエーション => 絶対に無駄な投資になる