【RFC 6797】HTTP Strict Transport Security

2024年1月11日のセキュリティエンジニアリング特論にて発表した資料

Transcript

1. 【RFC 6797】 HTTP Strict Transport Security ふたばと 2024年1月11日
2. 2 目次 1. HSTS の概要 2. 歴史的背景 3. HSTS の導入ことはじめ 4. HSTS の効果 5. HSTS 周りの留意事項 6. まとめ 【RFC 6797】HTTP Strict Transport Security
3. 3 https://www.sc-siken.com/kakomon/03_haru/am2_15.html
4. 4 https://www.sc-siken.com/kakomon/03_haru/am2_15.html
5. 5 【RFC 6797】HTTP Strict Transport Security HSTS は以下のメカニズムを提供できる仕組みを提供する • Web サイトが安全な接続を介してのみ アクセスできることを宣言できる • ユーザーが安全な接続を介してのみ 特定のサイトとやり取りできるように UA に指示できる 2012 年 11 月 に RFC 6797 として公開された 端的な説明をすれば、 HSTS とは、HTTP 接続してきたリクエストに対し、透過的に HTTPS へ 変換して、強制的に安全なリソースを取得させる仕組みである HSTS の概要
6. 6 Strict-Transport-Security ヘッダ HSTS を適用させるには、Web サイトからブラウザに送信する HTTPS レスポンスヘッダに例えば以下のヘッダを追加する HSTS の概要 ディレクティブ • max-age: 指定された秒数だけ HSTS を有効にする • includeSubDomains: サイトのすべてのサブドメインにも適用される • preload: 「HSTS に対応している Web サイトである」ことの宣言 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
8. 8 HSTS の対応状況 • SSL Pulse によると 34.9 %のサイトに HSTS が普及している • モダンなデスクトップブラウザであれば実装済み ◦ 事実上必須の機能で、出荷時に HSTS に対応していることが 判明しているサイトの一覧が組み込まれている（HSTS Preload） HSTS の概要 https://www.ssllabs.com/ssl-pulse/ (2024 年１月８日閲覧) https://caniuse.com/stricttransportsecurity (2024 年１月８日閲覧)
9. 9 HSTS の対応状況 IPA 発行『SSL/TLS 暗号設定ガイドライン』には ”さらに安全性を高めるもの”として HSTS の言及がある HSTS は普及しているとはまだまだ言えない • 金銭的なコストをかけずに Web サイトをセキュアにできる • 脆弱性診断では Info レベルでの指摘になる • 日本のオンラインバンキングではほとんど見られない 積極的な対応を勧める HSTS の概要
10. 10 常時 SSL 化 歴史的背景 ~ 2015 2015 ~ 基本は HTTP 常時 SSL 化 機密情報を扱うページのみを HTTPS にする慣習 Web の全 HTTPS 化へ SSL/TLS はセキュアチャネルを提供 • 通信相手の認証 • 通信の機密性 • 通信の安全性 “HTTPSだから安全” から “HTTPだから危険” へ
11. 11 常時 SSL 化に向けた留意事項 • 混在コンテンツ(Mixed-Contents)の問題 ◦ 暗号化されている HTTPS のページの中に平文で HTTP で送られてくる コンテンツが含まれている場合、それらを混在コンテンツとよぶ ◦ 常時 SSL 化が叫ばれて久しいので多くは対応されているが、 自分がオーナーでないリソースである場合には暗号化の対応は難しい ▪ Google Chrome は”安全でないコンテンツ”をデフォルトでブロックする • chrome://settings/content/insecureContent • https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html • Cookie の Secure 属性の追加 • 異オリジンへの移行 ◦ HTTP と HTTPS とではストレージが共有されない 歴史的背景
12. 12 TLS の弱点: 証明書の問題に寛容 歴史的背景 ブラウザは、不正な証明書を提示しているサイトへの接続に対して接続を 破棄するのでなく、 “ユーザがクリックして回避できてしまう警告”を表示する アクセスできるなら ヨシ！ サーバ証明書 なんかおかしいやで 😈
17. 17 TLS の弱点: 証明書の問題に寛容 歴史的背景 “ユーザがクリックして回避できてしまう警告”を無視すると、 ユーザは能動的に攻撃に身を晒すことになる（クリックスルー） 証明書の問題はサーバエラーと同様に扱われるべきだ というのが HSTS の立場 (RFC6797) アクセスできるなら ヨシ！ サーバ証明書 なんかおかしいやで 😈
18. 18 サイト HTTPS に限るため、一般的な実装では HTTP アクセスを HTTPS にリダイレクトさせるが、 最初の HTTP 通信は中間者によって改ざんされる可能性がある 301 Moved Permanently Request to https://futabato.bank:443 200 OK 中間者攻撃の存在 歴史的背景 Request to http://futabato.bank:80 Location ヘッダを 弄ればリダイレクト先 を制御できる 😈
19. 19 偽のアクセスポイントに接続してもらい HTTPS へのリダイレクトを防ぎつつ、正規のサイトのように振舞う 😈 301 Moved Permanently Request to https://futabato.bank:443 200 OK SSL Strip 歴史的背景 Request to http://futabato.bank:80 HTTP Insecure CONNECTION HTTPS Secure CONNECTION https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
20. 20 ForceHTTPS 2008 年 Jackson と Barth によって ForceHTTPS が設計された ★ ブラウザが透過的にセキュリティを後付けする ◦ クリックスルーの不安を防ぐ • Cookie を利用してポリシーの伝達を行う HSTS は ForceHTTPS で提案されたアプローチを改善 ➔ HTTPS レスポンスヘッダ フィールドを定義 歴史的背景 https://crypto.stanford.edu/forcehttps/
21. 21 背景まとめ • 常時 SSL 化に向けた留意事項への対応 • 安全でないクリックスルーの問題を解消したい ◦ 証明書の問題はサーバエラーと同様に扱われるべき ◦ ブラウザが透過的にセキュアにする HSTS で強制的に安全なリソースを取得させることで、 中間者攻撃 + α を緩和する ★ HTTP 接続してきたリクエストを透過的に HTTPS へ変換 ★ 証明書の問題を提示してアクセスできなくさせる 歴史的背景
22. 22 HSTS 設定方法 レスポンスヘッダに Strict-Tranport-Security ヘッダを追加する HSTS の導入ことはじめ Header set Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload" Nginx add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload'; Apache ディレクティブ • max-age: 指定された秒数だけ HSTS を有効にする • includeSubDomains: サイトのすべてのサブドメインにも適用される • preload: 「HSTS に対応している Web サイトである」ことの宣言
23. 23 ディレクティブ • max-age ディレクティブ ◦ 指定された秒数だけ HSTS を有効にする ◦ 必須, デフォルト値は 0, 秒単位の指定 ◦ HSTS の情報はブラウザにキャッシュされ、 有効期限内に再度ブラウザに送られると有効期限は更新される ◦ max-age=0 にすることで Strict-Transport Security ヘッダを失効させられる • includeSubDomains ディレクティブ ◦ ホストのすべてのサブドメインにも適用される ◦ デフォルト値は false, 引数の指定によって適用される • preload ディレクティブ ◦ 「HSTS に対応している Web サイトである」ことの宣言 ◦ RFC で定義されているものではない ▪ preload ディレクティブを付与してもサイトの挙動に変更は無い ◦ デフォルト値は false, 引数の指定によって宣言される HSTS の導入ことはじめ
24. 24 SSL Server Test ドメインを入力すれば HSTS が有効になっているかの確認ができる HSTS の導入ことはじめ
25. 25 HSTS の効果 HTTPS へ透過的に変換して強制的に安全なリソースを取得させる ブラウザでの扱いは以下の通り 1. HTTPS のレスポンスヘッダに Strict-Transport-Security ヘッダが付与される 2. ブラウザはサイトに HSTS の情報を記録する 3. 以降 HTTP でアクセス時に HTTPS へ透過的に変換する ★ 証明書の問題が出ているとユーザは回避ができなくなる HSTS の効果 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
26. 26 HTTPS への透過的な変換の体験 以下のような HTML を用意して、 ３秒後に http://www.amazon.co.jp へリダイレクトさせる ※ Google Chrome で検証, URL 直打ちでは挙動が変わるかもしれない HSTS の効果 <head> <meta http-equiv="refresh" content="3; url=http://www.amazon.co.jp" /> </head> <body> <p>3秒後にリダイレクトします</p> </body>
30. 30 https://www.pa-solution.net/daj/bs/faq/detail.aspx?id=3334&a=102&isCrawler=1
31. 31 HSTS の効果 https://youtu.be/k0xBCjWPqcU
32. 32 HSTS の副次的効果 副次的な効果として、HSTS には Cookie の盗取・改竄や セッションの固定化(Session Fixation)攻撃への緩和策になる ※ あくまで緩和策であるため根本的解決をするべきである • Cookie の盗取・改竄: Secure 属性を付与する • セッションの固定化攻撃: ログイン直後に Session ID を変更する HSTS の効果
33. 33 混在コンテンツの問題 • HSTS は混在コンテンツの問題を直接的に解決しない ◦ HSTS が有効なホストへの HTTP リクエストが許可されなくなる という意味では、混在コンテンツの問題を部分的には解決している • サードパーティの混在コンテンツの問題を解決したければ、 CSP(Contents-Security-Policy) を導入するとよい ◦ あるページからのリクエストに対して HTTPS のみを許可することで コンテンツの出どころを制御する ◦ Content-Security-Policy: upgrade-insecure-requests HSTS の効果
34. 34 ブラウザでの扱いの確認 1. HTTPS のレスポンスヘッダに Strict-Transport-Security ヘッダが付与される 2. ブラウザはサイトに HSTS の情報を記録する 3. 以降 HTTP でアクセス時に HTTPS へ透過的に変換する HSTS 周りの留意事項 200 OK + Strict-Transport-Security Request to https://futabato.bank:443 200 OK + Strict-Transport-Security Request to https://futabato.bank:443
35. 35 初回アクセス時には、 HSTS の情報が無いので HTTP でアクセスできてしまう ➔ 中間者攻撃の問題は解決していない 301 Moved Permanently Request to https://futabato.bank:443 200 OK + Strict-Transport-Security 初回アクセス時 HSTS 周りの留意事項 Request to http://futabato.bank:80 Location ヘッダを 弄ればリダイレクト先 を制御できる 😈
36. 36 Preload HSTS ブラウザに HSTS のリストを組み込む (Preloadさせる) ことで 初回アクセス時から HTTPS を強制させる • 登録されているドメインは参照可能 ◦ Google Chrome: chrome://net-internals/#hsts ◦ Chromium: src/net/http/transport_security_state_static.json ◦ Firefox: security/manager/ssl/nsSTSPreloadList.inc • Preload HSTS の登録申請は https://hstspreload.org/ にて行う HSTS 周りの留意事項
38. 38 Preload HSTS の申請 https://hstspreload.org/ を通じて Preload HSTS の申請を行うことができる 申請条件 (一部) • 有効な証明書を発行していること • ポート 80 で listen している場合、 同ホスト上で HTTP から HTTPS へリダイレクトする • すべてのサブドメインを HTTPS で提供する • ベースドメインで Strict-Transport-Security ヘッダの付与する ◦ max-age は少なくとも 31536000 Sec (=１Year) でなければならない ◦ includeSubDomains ディレクティブが指定されていること ◦ preload ディレクティブが指定されていること ◦ HTTPS サイトから追加のリダイレクトを提供する場合、 そのリダイレクトは Strict-Transport-Security ヘッダを持つ必要がある HSTS 周りの留意事項
41. 41 その他留意事項 • ドメイン全体で HSTS を有効にできない ◦ できることから始めよう ◦ 導入時は慎重に作業したほうがいい • HSTS キャッシュの追い出し ◦ Firefox 91 までは 1,024 エントリーしか保持されなかった ◦ Breaking Out HSTS (and HPKP) on Firefox,IE/Edge and (Possibly) Chrome • max-age ディレクティブの短さに起因する問題 ◦ 再訪時の初回リクエストが HTTPS に強制されない可能性 • ポートの共有 ◦ HSTS は全ポートで有効化される HSTS 周りの留意事項
42. 42 【RFC 6797】 HTTP Strict Transport Security • HSTS は Web サイトが安全な接続を介してのみ アクセスできることを宣言できる仕組みである • レスポンスヘッダに埋め込むことでブラウザが透過的に変換する • Preload HSTS によって初回アクセス時にも適用可能 • HSTS は中間者攻撃から守る効果があるだけでなく Cookie やセッションの問題を緩和する保険的対策にもなる • 金銭的なコストをかけずにセキュアにできる ◦ 導入時は慎重に作業したほうがいい まとめ
43. 43 参考文献 • RFC 6797: HTTP Strict Transport Security (HSTS) • プロフェッショナルTLS＆PKI 改題第2版 • ネットワークセキュリティ詳説 PKI/TLSプロトコル | コロナ社 • TLS 暗号設定 ガイドライン • 徳丸浩の日記 • 安全なWebアプリケーションの作り方 第2版 • What is an SSL Stripping Attack — Explained by SSL Experts • Strict-Transport-Security - HTTP | MDN