『プロフェッショナルSSL/TLS』読書会 第8章 資料

Transcript

1. 発表者： 杉野 透 第8章 デプロイ
2. デプロイとは ▪ 前章まででやってきた落とし穴を踏まないサーバを、実運用環境に 乗せるための具体的な注意点 ▪ 単純に最新のプラットフォームに適用させるだけならそこまで難しく ないが、互換性が必要なサーバを建てると面倒
3. 8.1 鍵 いったいいつから正しく管理できていると錯覚していた？
4. 8.1.1 鍵アルゴリズム ▪ DSA – 安全性に難あり、選択肢にするべきではない ▪ RSA – 現実的にはこれ一択、鍵長は最低でも2048ビット ▪ ECDSA – パフォーマンスに優れ鍵長も短いが、対応プラットフォームが少ない（そもそも 証明書発行してくれるところがない） ▪ 別アルゴリズムの同時発行は鍵管理のコストが上がる
5. 8.1.2 鍵長 ▪ RSAなら2048ビット（112ビット安全性） ▪ ECDSAなら256ビット（128ビット安全性） – RSAで128ビット安全性を確保しようとすると3072ビットの鍵が必要 – パフォーマンスの悪化
6. 8.1.3 鍵の管理 ▪ 秘密鍵は秘密にする – 当たり前だが守られていないことも往々にしてある ▪ RNGの精度を考慮する – リブート直後はエントロピー／人◕‿‿◕人＼が足りないことがある ▪ 鍵にはパスワードをかける – サーバの設定にパスワード書くのが面倒で意外とやっていない
7. 8.1.3 鍵の管理 ▪ 鍵は関係ないサーバで共通のものを使わない ▪ 鍵は頻繁に変更する – パスワードではない（人間が覚えない）のでリスクは少ない – PFSが保たれているなら1年に1回が目安 ▪ 鍵は安全に保管する – HSMが使えるならそれを
8. 8.2 証明書 昨日の証明書は今日の紙クズ
9. 8.2.1 証明書の種類 ▪ OV証明書はブラウザがぱっと分かるようにしてくれず割に合わない ので、お金かけて取るならEV証明書 ▪ DVでいいならLet’s EncryptとかAWS Certificate Managerで無料 で取りましょう
10. 8.2.2 証明書のホスト名 ▪ 意外と、自分が所持しているドメインを網羅していないことによる証 明書エラーがよくある – 例： www.example.com に対して証明書を発行し、 example.com に対応して いない ▪ どのような名前でアクセスされるかは制御できない – セキュアなサイトに向いたDNSに登録されているドメイン全てに証明書を発行 （もしくはワイルドカードで発行）するしかない ▪ CAが全部面倒を見てくれるとは限らない
11. 8.2.3 証明書の共有 8.2.4 署名アルゴリズム ▪ 証明書の共有 – 証明書の共有＝秘密鍵の共有 – 共有すべきでないサーバ同士（異なるチームが管理している等）での証明書の 共有およびセッション情報の共有は避けるべき ▪ 署名アルゴリズム – SHA1で署名した鍵はもう使えません – どうしてもSHA1しか使えない環境向けにサーバを建てる必要があるなら、両方 の鍵を使い分けるようにデプロイするしかない（面倒）
12. 8.2.5 証明書チェーン ▪ チェーンが成立しておらずTLSが無効になっているサイトが意外と 多い ▪ 不完全なチェーンでもクライアントがよしなにしてくれる場合がある が、それに頼ってはいけない – チェーンがキャッシュされている場合 – 欠けている情報を自動で問い合わせてくれる場合 – 順番が入れ違っている場合 ▪ 過不足なくチェーンを構築しないとパフォーマンスにも影響がでる – 例： チェーン構築に不要なルート証明書はチェーンに含めない （必要なルート証明書も存在するので厄介）
13. 8.2.6 失効 8.2.7 CAの選択 ▪ 証明書の失効 – CRLおよびOSCPの情報を必ず証明書に含める ▪ 普通はついてくる – OSCPステープリングは失効情報照合の高速化のためほぼ導入必須 ▪ CAの選択 – サービスの質や技術の早期採用しているところを選ぶべき – 安いからという理由でやばいところから取らないようにしましょう ▪ 例： W◦Sign – ブラウザベンダが名指しで突如CAを信頼リストから外すこともあり得るので動 向は注視しておきましょう ▪ 例： Sym◦ntec
14. 8.3 プロトコルの設定 SSL3.0が許されるのは小学生まで
15. 8.3 プロトコルの設定 ▪ TLS1.0以上は最低限 – IE6はSSL3.0までの対応だが、こればっかりはIEの方を捨てるべき ▪ セキュリティ標準のPCI DSS v3.1では、TLS1.0も新規システムで導 入してはいけないこととなっている – 新規システムではTLS1.2以上が推奨
16. 8.4 暗号スイートの設定 過去と決別せよ（できない）
17. 8.4.1 暗号スイートの提案 8.4.2 暗号の強度 ▪ サーバにおける暗号スイートの提案（ここ誤訳） – サーバからクライアントに暗号スイートを強制することが極めて重要 – サーバから提案する暗号スイートの中に弱いものを含めてはいけない ▪ 攻撃者が一番弱いものを選択できる ▪ 暗号の強度 – 128ビット安全性が得られる暗号 ▪ AESやCAMELLIA – AEADの仕様に対応したもの（GCM暗号利用モード）を選択する
18. 8.4.3 PFS ▪ 鍵交換アルゴリズムにはDHEもしくはECDHEを選択 ▪ ECDHEでは、secp256r1の曲線を使う ▪ DHEでは、DHのパラメータを2048ビットに設定する – # openssl dhparam -out dhparams.pem 2048 ▪ Java6のように1024ビット以上のDHパラメータに対応していない場合 …… – 1024ビットのまま使い続ける – DHEを無効化してECDHEに一本化する
19. 8.4.4 パフォーマンス ▪ GCMは高速なのでとりあえずこれを使っておけば問題ない – CBCは遅い上にセキュリティ上の優位性がゼロ ▪ AESとCAMELLIAでは、ハードウェア実装があるAESの方が高速 – ソフトウェア実装では同じくらい ▪ DH鍵交換は1024ビットでもsecp256r1を使ったECDHEより低速 – 2048ビットだとさらに低速
20. 8.4 相互運用性 ▪ 3DESとRC4しか対応していないプラットフォームは、RC4を切り3DES を使う ▪ Javaのクライアントは256ビットの暗号スイートに対応していないこと を考慮に入れる ▪ Java8未満は1024ビットのDHパラメータに対応していないが、Java7 はECDHEに対応しているのでこちらの優先度を上げる ▪ ECDHE鍵交換においては、secp256r1かsecp384r1の曲線のみを使 う
21. 8.5 サーバの設定と アーキテクチャ インフラから離れては生きられないのよ！
22. 8.5.1 共有環境 ▪ セキュリティを考える上で共有ホストは論外 ▪ 標的サーバに対して高速にアクセスできる（つまり物理的に距離が近 い）ことで攻撃可能になる手段がある（例： Lucky13） ▪ 物理CPUを共有した仮想マシンも攻撃手段がある（例： キャッシュタ イミング攻撃） – 隣の仮想マシンが自分の管理下にないなどの状態も危険 ▪ 本気でセキュリティやるならまずは自分達だけが管理できるサーバを 用意するべき
23. 8.5.2 仮想ホスティング ▪ SNI（Sever Name Indication）に対応していないクライアントを想定 するなら、1ドメイン1IPで運用するしかない ▪ そろそろSNI前提でサイト構築しても良い頃合いかもしれない – XPのサポートは切れました。イイネ？
24. 8.5.3 セッションキャッシュ ▪ セッションキャッシュ（TLSのリサンプション）を無効にするとパフォー マンスが劇的に悪化する可能性があるので、ここはトレードオフ ▪ 通常のサイトの場合は1日以内なら許容範囲内、厳しいサイトならば 短くする ▪ （TLS1.2における）セッションチケットは、チケットの暗号化鍵の管理 が甘いとPFSの意味がなくなるのでおすすめしない – Twitterは頑張っているらしい – TLS1.3ではこの辺はまるっと改善される
25. 8.5.4 複雑なアーキテクチャ ▪ 分散セッションキャッシュ – 例えばL3スイッチによるロードバランシングの場合、セッションキャッシュがある サーバに後続のリクエストが向くとは限らない – 解決策としては ▪ Remote IP などを判断基準にし、同じクライアントからは同じバックエンドへ ▪ セッションキャッシュをバックエンド間で共有する（例えばredisにぶちこむ） – 後者の解決はセキュリティリスクになり得る
26. 8.5.4 複雑なアーキテクチャ ▪ 無関係なアプリケーション間でのセッションキャッシュの共有 – 例えばブログサービスとソーシャルゲームサービス間でのセッション共有？ – ワイルドカード証明書を使ってL7リバースプロキシを手前に挟んでいたら自然と そうなる気もするけれど…… – 証明書の共有と同じレイヤの話
27. 8.5.4 複雑なアーキテクチャ ▪ SSLオフロードとリバースプロキシ – リバースプロキシやSSLアクセラレータから実際の処理をするアプリケーションの 間の通信を信頼してはいけない – 現実としてこれを守っているWebエンジニアそうそういないと思います ▪ アプリ層でその処理するの辛いし遅いし ▪ そもそもなんのための「アクセラレータ」ですかと – 内部に侵入した攻撃者による悪用が可能 ▪ 侵入された時点で既に色々アウトな気もする
28. 8.5.4 複雑なアーキテクチャ ▪ ネットワーク上でのトラフィックのインスペクション – 侵入検知システムやネットワークモニタリングツールでは、秘密鍵を共有して ネットワーク内のトラフィックを復号できるようにするものがある – セキュリティって一体なんだっけ案件 – 当然秘密鍵が漏れてしまえば一瞬でセキュリティが無に帰す
29. 8.5.4 複雑なアーキテクチャ ▪ インフラのアウトソージング – ELBとかを使う場合でも、自分の管理するEC2まできっちり暗号化してパケットを 届けましょう – これも案外やってない人の方が多い気がします ▪ アプリ層で（ｒｙ ▪ というかせっかくELBのCPUで復号してくれるのにそのリソースを使わないんですか ▪ こんなこと気にするならAWS使わないことをまず考えるべきでは – RailsとかPHP系フレームワークとかGoでのHTTPS復号のノウハウがある人は こっそり教えてください
30. 8.6 セキュリティ上の問題の緩 和策 聖闘士に同じ技は二度も通じぬ
31. 8.6.1 Renegotiation ▪ とにかくクライアントからの再ネゴシエーション要求は無効 ▪ どうしても必要な場合でも、安全な再ネゴシエーション拡張を有効化 （renegotiation_info拡張） ▪ 究極的にはTLS1.3を待つ
32. 8.6.2 BEAST 8.6.3 CRIME ▪ BEAST – TLS1.0を有効にする場合、CBCモードの暗号スイートを無効化 – TLS1.1以上に限定 ▪ CRIME – TLSの圧縮は無効化する
33. 8.6.4 Lucky 13 ▪ 対応パッチが当たっているバージョンのサーバ（もしくはライブラリ）を 使う ▪ CBCモードの暗号スイートを無効化する
34. 8.6.5 RC4 ▪ 古いブラウザの事を考えなくていいならとりあえず無効にしましょう ▪ BEAST（TLS1.0）やPOODLE（SSL3.0）に怯えるくらいならRC4の方が まだ安全 – この環境でしか動かないクライアントを対象にしてる場合のみ選択肢に入れるか どうか慎重に考えるべき
35. 8.6.6 TIMEおよびBREACH ▪ TLSの圧縮は無効にしても、HTTP層での圧縮を無効にするのはパ フォーマンスに影響を及ぼす ▪ 抜かれて困る情報（CSRFトークンやセッションクッキーの値）にマス キングを行う – 既存コードの大幅改修が必要になる – というかこれをシュッとやってくれるフレームワークってありますか？ ▪ リファラ情報が不正であったり、リファラが取れない場合は、圧縮を無 効化する – 正常利用の範囲なら圧縮が効くはずなのでパフォーマンスに影響を及ぼさない
36. 8.6.7 トリプルハンドシェイク攻撃 8.6.8 Heartbleed ▪ トリプルハンドシェイク – クライアント証明書を用いる環境でのみ有効な攻撃なので、クライアント側のブ ラウザを最新にして対応するべき ▪ Heartbleed – さすがに影響あった人ももう対応済みですよね？ – OpenSSLのバージョン上げ – 秘密鍵、証明書を新規発行（だいたいのCAは無料サービスしてくれましたね） – セッションチケットを使っている場合はチケット鍵の更新 – サーバ上のユーザパスワードなどの変更
37. 8.7 ピンニング Chaos Orb対策で壁にピン留めされたBlack Lotus
38. 8.7 ピンニング ▪ ここで言うピンニングとは、HPKPに限らない – 例えばアプリに、「APIサーバにアクセスする場合に、期待される証明書の情報」を 埋め込んでおく等も対策になる ▪ 現状公開仕様として、HPKP、DANE（DNSSECがベース）、TACK（TLS 拡張がベース、ドラフトが2013年から更新されていない）などがある ▪ もちろん運用難易度は跳ね上がる ▪ 詳しくは10章にて
39. 8.8 HTTP 私はTeapot
40. 8.8.1 全面的な暗号化の利用 ▪ 暗号化するべきなのに暗号化していないWebサイトがある – Passwordのフォームがあるのに暗号化してないサイトとか ▪ とりあえず自分の管理するコンテンツは全部暗号化しよう – Mixedコンテンツを回避することにも繋がる – 1部分だけ暗号化を導入するのは事実上不可能
41. 8.8.2 クッキーのセキュリティ ▪ secure属性をつけよう ▪ ドメインは絞ろう – 無関係のサブドメインからクッキーを挿入する脆弱性の排除 ▪ クッキーの暗号化や完全性の検証が一番安全 – もちろん手間はかかる
42. 8.8.3 バックエンドにおける証明書とホスト名の検証 ▪ WebViewやAPIをバックエンドに持つアプリで、証明書の検証をすっ 飛ばすコードを書いてしまう脆弱性 – 開発時にオレオレ証明書を通すために書いていた設定を本番で外し忘れるなど ▪ ライブラリを正しく設定して使うべし – 低レベルのAPIを使うべきではない ▪ アプリケーションで証明書のピンニングを行うもの有効
43. 8.8.4 HSTS ▪ ブラウザに「このアドレスは絶対HTTPSでアクセスしろよ」ということを 要求する ▪ これにより – ブックマークがHTTPでもブラウザがよしなにHTTPSでアクセスしてくれる – secure属性のクッキーが抜かれない – HTTPSストリッピング攻撃を受けない – サイト側のミスでMixedコンテンツになっていてもある程度回避できる ▪ HSTSを使った場合、ブラウザは証明書や設定にミスがあった場合に 「無視して続行」ができなくなるので、安全に倒せる ▪ 詳しくは10章にて
44. 8.8.5 CSP ▪ Content Security Policy ▪ 面倒な複雑な設定をすることで、XSSを回避したり、iFrameからペー ジを操作されることを防いだり、ページ内のリソースをhttpsに限定し たりなど、ページ内のコンテンツを限定できる ▪ なお現状は使いにくすぎる – 本当に安全に倒そうとすると、インラインjsやインラインcssが軒並全滅する – CSP Level2が実用範囲内になればnonceやhashが使えるようになるのでまだ なんとかなる？（それでも面倒） ▪ 詳しくは10章にて
45. 8.8.6 プロトコルダウングレード攻撃に対する防御 ▪ ChromeやFirefoxは、中間者攻撃などでTLSのダウングレード時に 「Signaling Cipher Suite Value（SCSV）」によるダウングレード通知 を教えてくれるようになっている – ちなみにこれはRFC7505として標準化されている ▪ OpenSSL1.0.1jからは、SCSVをユーザが意識しないで扱えるように なっている ▪ このバージョン以前のOpenSSLを使っている場合は、ログやパケット を見てSCSVを検出してなんとかしましょう
46. これまで説明した各種設定の大部分を よしなに作ってくれる何か https://mozilla.github.io/server-side-tls/ssl- config-generator/