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

by mashijp

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

おことわり  ● このスライドは社内で発表したものを再編集したものです ● 当たり障りのないスライドのみ残しているためチグハグになっています

Slide 3

Slide 3 text

想定聴者  ● 応用情報技術者ぐらいの知識を持っている人 ○ 共通鍵暗号、公開鍵暗号、デジタル署名、デジタル証明書の雰囲気を知っている ● SSL証明書を何かしら使ったことがある人

Slide 4

Slide 4 text

今回の勉強会のテーマ  ● SSL関連の障害がなぜ起きてしまうのか？ ○ 何で対応端末が変わるのか ● 何をすれば障害を防げるのか？ ● SSL対応するためにどういう体制を組んでいたらいいのか？今日はググっても出てこない話を中心にします

Slide 5

Slide 5 text

何が対応端末を左右するのか  ● 技術的な話 ○ 証明書の種類 (RSA/ECDSA) ○ TLSのバージョン Cipher Suite (暗号通信のやり方) ○ SNI ● 人間的な話 ○ ルート証明書 (証明書の調達先) ググったら出てくる

Slide 6

Slide 6 text

技術的な話  ● だいたい定石があります ● いつも同じことをしていたらあまりトラブルにはなりません ● 他人のマネも容易です ○ RSA/ECDSA ○ TLS Version, Cipher Suite ○ SNI

Slide 7

Slide 7 text

人間的な話  ● 業界動向で世界が一変します ○ 極端な話「好き」とか「嫌い」とかで決まります ● 証明書は定期的に変えなければならないため強制的に追従させられます ○ ルート証明書

Slide 8

Slide 8 text

技術的な話 

Slide 9

Slide 9 text

TLSのネゴシエーション概要  TLS(SSL)のネゴシエーションで、通信先の認証と暗号通信のやり方の決定が行われる Client Server サーバ証明書, TLS Version, Cipher Suite 決定接続開始要求 TLS Version, 対応Cipher Suites 一覧暗号鍵交換交換した鍵で暗号通信 (例: HTTP) (共通鍵暗号... AESなど) ネゴシエーション TLS HTTP IP, TCP

Slide 10

Slide 10 text

TLSネゴシエーション時にホストは分からない  ● TLSのネゴシエーション時にはホスト名が分からない ● TLSネゴシエーション後、HTTP通信をしはじめて初めて HTTP Host ヘッダとしてサーバに渡される TLS HTTP IP, TCP

Slide 11

Slide 11 text

https://www.google.com/ にアクセスするときの例  クライアント(ブラウザ)から見ると… 1. www.google.com をDNS解決する 2. (1) の IPアドレスに対し TLSネゴシエーション要求 3. サーバからSSLサーバ証明書が送られてくる a. “*.google.com” を名乗るサーバ証明書が来る 4. 接続しようとしているのは www.google.com で証明書と一致しているので OK

Slide 12

Slide 12 text

1つのIPアドレスで2つ以上の証明書を使うときに困る  ● 1つのIPアドレスには複数の証明書を使うことはできない ● どの証明書を返せばいいか分からないためサーバ証明書1 *.aaa.example 証明書2 *.bbb.example クライアント接続要求？？？ SSL証明書1つに対し最低1つIPアドレスが必要

Slide 13

Slide 13 text

SNI拡張  ● 接続要求時にホスト名を送信する拡張仕様 ● サーバはホスト名がわかるので適切な証明書を送ることができる IPアドレスを節約できるサーバ証明書1 *.aaa.example 証明書2 *.bbb.example クライアント接続要求 + ホスト名ホスト名にあった証明書を送るただし拡張のため対応していない環境があることに注意 (例: Android 2.3未満, 旧バージョンのScala Play WSなど) 意外と対応していないクライアントは多い

Slide 14

Slide 14 text

TLSバージョン  ● TLS1.0, 1.1 はオワコンにさせようという動きがある ● が、気にせず TLS1.0〜1.2 をサポートしていたら良い ○ 中間者により低いバージョンを使わせる攻撃を回避する拡張がある (TLS_FALLBACK_SCSV) ○ 極めて秘匿性の高い情報をやり取りする場合は別途検討 ● TLS1.2 only にすると Android 4.xの一部等がサポート外になる可能性がある ○ あくまで 1.0, 1.1 は deprecated な扱いで運用する

Slide 15

Slide 15 text

Cipher Suite (暗号通信のやり方)  以下の組み合わせ。暗号通信の技術的安全性を左右するネゴシエーション時のサーバ負荷も変わる ● どうやって鍵を交換するか (鍵交換アルゴリズム) ○ RSA, DHE_RSA, ECDHE_RSA 等 ● 共通鍵暗号に何を使うか ○ AES-128-GCM 等 ● メッセージ認証アルゴリズムに何を使うか ○ HMAC-SHA-256 等

Slide 16

Slide 16 text

Cipher Suite の詳細を知りたい  語り始めるとそこだけで2時間かかるので割愛！次の本 (無料でPDFあり) を読むのがおすすめ『クラウドを支えるこれからの暗号技術』 https://herumi.github.io/ango/ Cipher Suite の意味を知るには第1部で十分です

Slide 17

Slide 17 text

Cipher Suite を決める上で注意すること  ● 低セキュリティなものしか対応していないパターン ○ 古い環境など ○ 例: Windows XP IE8, Java7, ... ● 高セキュリティなものしか対応していないパターン ○ 意識が高い環境など ○ 例: Apple ATS (iOS)

Slide 18

Slide 18 text

高セキュリティなものしか対応していないケース  ● Apple は秘匿性の高いCipher Suiteでしか通信させないようにしている (ATS: App Transfer Security) ○ ECDHE という鍵交換方式のサポートを必須としている ● 「低セキュリティなものを追加してはいけない」というわけではない https://developer.apple.com/jp/security/

Slide 19

Slide 19 text

Cipher Suite の選定基準  ● Cipher Suite はサーバ側で優先度を決められる ● サーバ負荷の問題ない範囲で、高セキュリティなものを優先度高く設定 ● 脆弱と言われているアルゴリズムは外す ○ 時代によって変わる… ● 広いデバイスに対応するなら、たくさん設定する

Slide 20

Slide 20 text

結局何を設定したらいいの？  もうGoogleをパクれ！ https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&s=216.58.194.196&hideResults=on

Slide 21

Slide 21 text

結局何を設定したらいいの？    ● Google で採用している Cipher Suite を基準にする ● Google はかなり広い環境に対応するような Cipher Suite を設定している ● よく考えると広い環境に対応しないといけないのは大体 Google が悪い気がするし一番 Google が困ってる ○ Android のあらゆるバージョンが世の中にはびこっているため

Slide 22

Slide 22 text

証明書の種類 

Slide 23

Slide 23 text

RSA/ECDSA証明書  ● デジタル署名を実現するアルゴリズムが違う ○ 環境によっては ECDSA のほうがサーバ負荷が少なかったりする ● RSAに対応していない環境はない (たぶん) ● ECDSAを選択するならそれなりの覚悟で選ぶ ○ RSA証明書も同時に調達し、2つ設定するなどの対応が必要 ○ 周りは誰も助けてくれません ● 詳しくないなら絶対に RSA を選択する

Slide 24

Slide 24 text

(参考) 証明書の持つ機能  ↓このあたりは環境によるトラブルを聞いたことはないです ● ワイルドカード証明書 ● SANs証明書 (マルチドメイン証明書) ● SANsワイルドカード証明書 ※ガラケーは不明

Slide 25

Slide 25 text

ルート証明書と  証明書ベンダー 

Slide 26

Slide 26 text

証明書の中身  こんなことが書いてある ● どのFQDNを認証したのか ● 誰によって認証されたのか (発行者)

Slide 27

Slide 27 text

SSL証明書の構造 (信頼チェーン)  OSにプリインストールされているルート証明書中間証明書サーバ証明書署名クライアントに送信する必要がある署名

Slide 28

Slide 28 text

SSL証明書の構造 (信頼チェーン)  GlobalSign Root CA GlobalSign Organization Validation CA サーバ証明書署名この組み合わせをクライアント(ブラウザ等)に送信する署名ブラウザは GlobalSign Root CA を信頼しているのでサーバ証明書を信用する

Slide 29

Slide 29 text

中間証明書の設定忘れ  中間証明書サーバ証明書ここだけをクライアントに送ると…？署名ブラウザからすると知らない人に署名されているサーバ証明書となり信頼できない証明書として拒絶してしまう※

Slide 30

Slide 30 text

環境によってプリインストール内容は異なる  ルート証明書をプリインストールするかしないかはそれぞれの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 ○ ○ ☓ ○

Slide 31

Slide 31 text

ルート証明書を信頼するかどうか  ● OSで管理するパターン (だいたいこっち) ○ Safari, IE, Chrome ● アプリケーションで独自に管理するパターン ○ Firefox, Java

Slide 32

Slide 32 text

一部の環境のみ対応したルート証明書を利用する場合  macOS上ではルート証明書A を信頼していないためオレオレ証明書と同じ状態となる (拒絶する) ルート証明書A Windows OK, macOS NG サーバ証明書中間証明書 Windows OK, macOS NG クライアントに送信

Slide 33

Slide 33 text

クロスルート  幅広い環境に対応するためにさらに別のルート証明書に署名してもらった証明書を送信するルート証明書A Windows OK, macOS NG サーバ証明書中間証明書ルート証明書B Windows OK, macOS OK 署名署名署名クライアントに送信

Slide 34

Slide 34 text

クロスルートの具体例  (社内のみ)

Slide 35

Slide 35 text

ルート証明書は当たり前のように変わる  なぜ？ ● 計算能力の向上や暗号技術の進化 ○ 例) SHA-1 の危殆化、SHA-256 への移行 ○ 例) RSA 1024bit の危殆化 ○ 例) ECDSA の導入 ● ルート認証局が信頼できなくなった ● 鍵の危殆化防止 ● 業界内でのいざこざルート証明書は長期に渡り入れ替わっていくことを前提としている。永久に利用できるルート証明書は存在しない。

Slide 36

Slide 36 text

ルート証明書更改の具体例  (社内のみ)

Slide 37

Slide 37 text

ルート証明書のインストール状況  親切なところはリストを公開している ● 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/

Slide 38

Slide 38 text

クロスルートによる更改リスクの回避  ● 証明書ベンダーがルート証明書を更改するとき、互換性を維持するための通常クロスルートがなされる ● 「ルート証明書が変わって対応デバイスが変わった！」というときは、まずはクロスルート証明書を探す

Slide 39

Slide 39 text

SSL証明書は既得権益  ● 広いデバイスで採用されているルート証明書を持っている会社が圧倒的に強い ● そもそもSSL証明書はどのように販売されているのか？

Slide 40

Slide 40 text

A社の証明書  サーバ証明書中間: A社の中間証明書ルート: A社のルート証明書サーバ証明書サーバ証明書 A 社の管理自社でルート証明書および秘密鍵を保持しており、自社でサーバ証明書を発行する

Slide 41

Slide 41 text

B社の証明書  サーバ証明書中間: B社の中間証明書ルート: C社の証明書サーバ証明書サーバ証明書 C社 (他社) の管理 B社の管理 B社は自身で中間証明書と秘密鍵を持っており、自身のシステムで証明書を発行できる。ただしルート証明書はC社が持っている

Slide 42

Slide 42 text

D社の証明書  サーバ証明書中間: E社の中間証明書ルート: E社のルート証明書サーバ証明書サーバ証明書 E社の管理 D社は E社のシステムを使ってサーバ証明書を代理で発行し、顧客に提供する

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

業界動向のあれこれ  (社内のみ)

Slide 45

Slide 45 text

動作確認 

Slide 46

Slide 46 text

SSLの「正しい設定」とは  ● 正しく設定しているか ○ 中間証明書を設定しているかどうか ○ 脆弱性がある設定になっていないか ● 非対応端末が発生していないか ○ ルート証明書をサポートしているか ■ 必要に応じてクロスルート証明書を設定しているか ○ TLS Version, Cipher Suiteをサポートしているか → 1端末で動作確認をしても意味がない

Slide 47

Slide 47 text

ややこしいブラウザ実装  ● 中間証明書の設定を忘れていてもブラウザによっては自動でダウンロードする機能がある (らしい) ○ キャッシュ機能もある？（らしい） ● 「1ブラウザでの動作確認」は全く意味なし

Slide 48

Slide 48 text

中間証明書を忘れた例 (再)  (社内のみ)

Slide 49

Slide 49 text

Windows 10 Firefox  (社内のみ)

Slide 50

Slide 50 text

Windows 10 Chrome  (社内のみ) 正常動作

Slide 51

Slide 51 text

macOS 10.13 Firefox  (社内のみ)

Slide 52

Slide 52 text

macOS 10.13 Chrome  (社内のみ)

Slide 53

Slide 53 text

どうしてこうなったか  環境ルート対応自動解決 (推測) 表示結果 macOS Chrome No Yes → NG macOS Firefox Yes No → NG Windows Chrome Yes Yes → OK Windows Firefox Yes No → NG ルート Windows/Firefoxのみ対応ルートサーバサーバ証明書中間中間証明書ルート全環境サポートルート署名署名署名 (クロスルート)

Slide 54

Slide 54 text

SSL Labs  https://www.ssllabs.com/ssltest/analyze.html オンラインで SSL設定状況を確認できる

Slide 55

Slide 55 text

SSL Labs  ● 網羅的に確認可能 ○ 脆弱性 ○ 動作環境 ● セキュリティレベルを「レーティング」という形でわかりやすく提供 ○ 時代にあわせてレーティングが変わる

Slide 56

Slide 56 text

レーティングが高ければいいわけではない  ● 「安全に通信できる」という観点ではレーティングが高ければ高いほど良い ● ただ高くなるようにすると対応環境が減ることも

Slide 57

Slide 57 text

なんのためにSSL化するのか  ● 機密性のある情報をやりとりするため？ ○ 漏れたときのリスクは？ ● ブラウザ/業界の圧力に対応するため？ ○ httpsでないと使えない拡張が増えてきたから？ ● ユーザーイメージのため？ ○ まだhttpsでないと笑われるから？総合的に考えてちょうどいい塩梅を探す (面倒ならGoogleをパクろう)

Slide 58

Slide 58 text

testssl.sh  ● SSL Labs はインターネットに露出しているサイトでないと使えない ● testssl.sh というローカルで実行できるものをおすすめ ○ https://testssl.sh/

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

SSLLabs / testssl.sh の注意点  ● ルート証明書の確認は「最新環境」でしかなされない ○ “Trusted: Apple” となっていても古い環境で信頼されていないケースも (例: https://good.r1demo.pki.goog/ ) ● 逆にいうと 1個でも Not OK がある場合、ヤバいルート証明書をサポートしているかは対応したい環境で個別に確認するしかない

Slide 61

Slide 61 text

体制 

Slide 62

Slide 62 text

SSLはしくじれない  ● よくある「対応環境外」 ○ 対応していなくても、デザインが崩れながらもサイトが見られる ○ ユーザーへの告知をなんとか見せられる ● SSLの「対応環境外」 ○ ユーザーはそもそも一切接続できない ○ 障害と同じ状態

Slide 63

Slide 63 text

なにに対応したいか？    ● いわゆる普通で新しいOS/ブラウザ/端末だけをサポートしたい ○ testssl.sh, SSL Labs に頼ればいい ● 古いOS/ブラウザ/端末や特殊な環境もサポートしたい ○ 十分な体制を組むべき

Slide 64

Slide 64 text

古い環境でも対応する場合に組むべき体制  複数のルート証明書で動作を事前に確認しておく一方で対応できない場合はもう一方の候補に切り替える

Slide 65

Slide 65 text

複数のルート証明書を候補にしておく  いわゆるマルチベンダー的な話だけではないルート証明書は必ず変わり続けるため対応は必ず発生するある日突然革命が起きることも (社内のみ)

Slide 66

Slide 66 text

SSL証明書調達時  ● SSL証明書調達時には現在のルートが何かを確認する ○ 公式サイトにのっている ● RSA / ECDSA で異なることが多いので注意 ○ 特に ECDSA は誰も使ってないため地雷になりがちなので注意

Slide 67

Slide 67 text

リスクを下げるために調達頻度を下げる？  ● SSL証明書の有効期限の長いものを変えばリスク発生頻度は下がる ● が、近年有効期限を短くしようとする動きがあるので 1年に1回は入れ替えられる体制を推奨 ○ 技術上は有効期限はいくらでも伸ばせるが業界の動きで変わる ○ 3年強 -> 2年強 (2018/03〜) -> 1年強案 (否決)

Slide 68

Slide 68 text

まとめ 

Slide 69

Slide 69 text

まとめ  ● SSLは単純な「技術的なもの」ではない ● 証明書の構造のとおり信頼の連鎖で成り立っている ○ 信頼は人間的なもの ● 対応環境を絞れないならそれなりの体制が必要 ● ただしSSLにした時点で世の中の波に突っ込まれることは覚悟する ○ 古い環境を切り捨てる覚悟が必要

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

Appendix: 中間証明書の存在理由 (1)  もちろんこの状態で発行してくれればサーバ証明書だけ送信すれば信頼できるルート証明書サーバ証明書署名

Slide 72

Slide 72 text

Appendix: 中間証明書の存在理由 (2)    ルート証明書有効期限: 〜20年中間証明書有効期限: 〜10年サーバ証明書有効期限: 〜2年署名署名サーバ証明書の利用者が管理ルート証明書の秘密鍵中間証明書の秘密鍵サーバ証明書の秘密鍵オフラインで保管する極めて厳重に管理 (インターネットに接続した環境に置かない ) 証明書発行事業者のシステム内に管理 Web上でSSL証明書を発行できるようにする

Slide 73

Slide 73 text

Appendix: サーバ負荷 (1)  チップの特性によって負荷傾向が大きく異なるため一概に言えない ● 例: あるCPUでは性能は RSA < ECDSA となった ● 例: ハードウェアロードバランサに高性能RSA処理チップを搭載しているため、性能は RSA > ECDSA となった試験をしない限り明確なことは言えない

Slide 74

Slide 74 text

Appendix: サーバ負荷 (2)    TLSはネゴシエーション時に大きな負荷がかかるネゴシエーション後はAESを紐解くだけのため軽い 2回目以降にネゴシエーションを避ける技術も (TLS Session Resumption) ● TLS Session Id ● TLS Session Ticket

Slide 75

Slide 75 text

Appendix: サーバ負荷 (3)  HTTP 1 req = 1ネゴシエーションは最悪中の最悪ケースエンドユーザー向けでは絶対にありえないシチュエーション => 絶対に無駄な投資になる