【RFC 6797】HTTP Strict Transport Security

Slide 1

Slide 1 text

【RFC 6797】 HTTP Strict Transport Security ふたばと 2024年1月11日

Slide 2

Slide 2 text

2 目次 1. HSTS の概要 2. 歴史的背景 3. HSTS の導入ことはじめ 4. HSTS の効果 5. HSTS 周りの留意事項 6. まとめ【RFC 6797】HTTP Strict Transport Security

Slide 3

Slide 3 text

3 https://www.sc-siken.com/kakomon/03_haru/am2_15.html

Slide 4

Slide 4 text

4 https://www.sc-siken.com/kakomon/03_haru/am2_15.html

Slide 5

Slide 5 text

5 【RFC 6797】HTTP Strict Transport Security HSTS は以下のメカニズムを提供できる仕組みを提供する ● Web サイトが安全な接続を介してのみアクセスできることを宣言できる ● ユーザーが安全な接続を介してのみ特定のサイトとやり取りできるように UA に指示できる 2012 年 11 月に RFC 6797 として公開された端的な説明をすれば、 HSTS とは、HTTP 接続してきたリクエストに対し、透過的に HTTPS へ変換して、強制的に安全なリソースを取得させる仕組みである HSTS の概要

Slide 6

Slide 6 text

6 Strict-Transport-Security ヘッダ HSTS を適用させるには、Web サイトからブラウザに送信する HTTPS レスポンスヘッダに例えば以下のヘッダを追加する HSTS の概要ディレクティブ ● max-age: 指定された秒数だけ HSTS を有効にする ● includeSubDomains: サイトのすべてのサブドメインにも適用される ● preload: 「HSTS に対応している Web サイトである」ことの宣言 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 HSTS の対応状況 ● SSL Pulse によると 34.9 %のサイトに HSTS が普及している ● モダンなデスクトップブラウザであれば実装済み ○ 事実上必須の機能で、出荷時に HSTS に対応していることが判明しているサイトの一覧が組み込まれている（HSTS Preload） HSTS の概要 https://www.ssllabs.com/ssl-pulse/ (2024 年１月８日閲覧) https://caniuse.com/stricttransportsecurity (2024 年１月８日閲覧)

Slide 9

Slide 9 text

9 HSTS の対応状況 IPA 発行『SSL/TLS 暗号設定ガイドライン』には ”さらに安全性を高めるもの”として HSTS の言及がある HSTS は普及しているとはまだまだ言えない ● 金銭的なコストをかけずに Web サイトをセキュアにできる ● 脆弱性診断では Info レベルでの指摘になる ● 日本のオンラインバンキングではほとんど見られない積極的な対応を勧める HSTS の概要

Slide 10

Slide 10 text

10 常時 SSL 化歴史的背景 ~ 2015 2015 ~ 基本は HTTP 常時 SSL 化機密情報を扱うページのみを HTTPS にする慣習 Web の全 HTTPS 化へ SSL/TLS はセキュアチャネルを提供 ● 通信相手の認証 ● 通信の機密性 ● 通信の安全性 “HTTPSだから安全” から “HTTPだから危険” へ

Slide 11

Slide 11 text

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 とではストレージが共有されない歴史的背景

Slide 12

Slide 12 text

12 TLS の弱点: 証明書の問題に寛容歴史的背景ブラウザは、不正な証明書を提示しているサイトへの接続に対して接続を破棄するのでなく、 “ユーザがクリックして回避できてしまう警告”を表示するアクセスできるならヨシ！サーバ証明書なんかおかしいやで 😈

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 TLS の弱点: 証明書の問題に寛容歴史的背景 “ユーザがクリックして回避できてしまう警告”を無視すると、ユーザは能動的に攻撃に身を晒すことになる（クリックスルー）証明書の問題はサーバエラーと同様に扱われるべきだというのが HSTS の立場 (RFC6797) アクセスできるならヨシ！サーバ証明書なんかおかしいやで 😈

Slide 18

Slide 18 text

18 サイト HTTPS に限るため、一般的な実装では HTTP アクセスを HTTPS にリダイレクトさせるが、最初の HTTP 通信は中間者によって改ざんされる可能性がある 301 Moved Permanently Request to https://futabato.bank:443 200 OK 中間者攻撃の存在歴史的背景 Request to http://futabato.bank:80 Location ヘッダを弄ればリダイレクト先を制御できる 😈

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20 ForceHTTPS 2008 年 Jackson と Barth によって ForceHTTPS が設計された ★ ブラウザが透過的にセキュリティを後付けする ○ クリックスルーの不安を防ぐ ● Cookie を利用してポリシーの伝達を行う HSTS は ForceHTTPS で提案されたアプローチを改善 ➔ HTTPS レスポンスヘッダフィールドを定義歴史的背景 https://crypto.stanford.edu/forcehttps/

Slide 21

Slide 21 text

21 背景まとめ ● 常時 SSL 化に向けた留意事項への対応 ● 安全でないクリックスルーの問題を解消したい ○ 証明書の問題はサーバエラーと同様に扱われるべき ○ ブラウザが透過的にセキュアにする HSTS で強制的に安全なリソースを取得させることで、中間者攻撃 + α を緩和する ★ HTTP 接続してきたリクエストを透過的に HTTPS へ変換 ★ 証明書の問題を提示してアクセスできなくさせる歴史的背景

Slide 22

Slide 22 text

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 サイトである」ことの宣言

Slide 23

Slide 23 text

23 ディレクティブ ● max-age ディレクティブ ○ 指定された秒数だけ HSTS を有効にする ○ 必須, デフォルト値は 0, 秒単位の指定 ○ HSTS の情報はブラウザにキャッシュされ、有効期限内に再度ブラウザに送られると有効期限は更新される ○ max-age=0 にすることで Strict-Transport Security ヘッダを失効させられる ● includeSubDomains ディレクティブ ○ ホストのすべてのサブドメインにも適用される ○ デフォルト値は false, 引数の指定によって適用される ● preload ディレクティブ ○ 「HSTS に対応している Web サイトである」ことの宣言 ○ RFC で定義されているものではない ■ preload ディレクティブを付与してもサイトの挙動に変更は無い ○ デフォルト値は false, 引数の指定によって宣言される HSTS の導入ことはじめ

Slide 24

Slide 24 text

24 SSL Server Test ドメインを入力すれば HSTS が有効になっているかの確認ができる HSTS の導入ことはじめ

Slide 25

Slide 25 text

25 HSTS の効果 HTTPS へ透過的に変換して強制的に安全なリソースを取得させるブラウザでの扱いは以下の通り 1. HTTPS のレスポンスヘッダに Strict-Transport-Security ヘッダが付与される 2. ブラウザはサイトに HSTS の情報を記録する 3. 以降 HTTP でアクセス時に HTTPS へ透過的に変換する ★ 証明書の問題が出ているとユーザは回避ができなくなる HSTS の効果 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Slide 26

Slide 26 text

26 HTTPS への透過的な変換の体験以下のような HTML を用意して、３秒後に http://www.amazon.co.jp へリダイレクトさせる ※ Google Chrome で検証, URL 直打ちでは挙動が変わるかもしれない HSTS の効果

3秒後にリダイレクトします

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 https://www.pa-solution.net/daj/bs/faq/detail.aspx?id=3334&a=102&isCrawler=1

Slide 31

Slide 31 text

31 HSTS の効果 https://youtu.be/k0xBCjWPqcU

Slide 32

Slide 32 text

32 HSTS の副次的効果副次的な効果として、HSTS には Cookie の盗取・改竄やセッションの固定化(Session Fixation)攻撃への緩和策になる ※ あくまで緩和策であるため根本的解決をするべきである ● Cookie の盗取・改竄: Secure 属性を付与する ● セッションの固定化攻撃: ログイン直後に Session ID を変更する HSTS の効果

Slide 33

Slide 33 text

33 混在コンテンツの問題 ● HSTS は混在コンテンツの問題を直接的に解決しない ○ HSTS が有効なホストへの HTTP リクエストが許可されなくなるという意味では、混在コンテンツの問題を部分的には解決している ● サードパーティの混在コンテンツの問題を解決したければ、 CSP(Contents-Security-Policy) を導入するとよい ○ あるページからのリクエストに対して HTTPS のみを許可することでコンテンツの出どころを制御する ○ Content-Security-Policy: upgrade-insecure-requests HSTS の効果

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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 ヘッダを弄ればリダイレクト先を制御できる 😈

Slide 36

Slide 36 text

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 周りの留意事項

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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 周りの留意事項

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

41 その他留意事項 ● ドメイン全体で HSTS を有効にできない ○ できることから始めよう ○ 導入時は慎重に作業したほうがいい ● HSTS キャッシュの追い出し ○ Firefox 91 までは 1,024 エントリーしか保持されなかった ○ Breaking Out HSTS (and HPKP) on Firefox,IE/Edge and (Possibly) Chrome ● max-age ディレクティブの短さに起因する問題 ○ 再訪時の初回リクエストが HTTPS に強制されない可能性 ● ポートの共有 ○ HSTS は全ポートで有効化される HSTS 周りの留意事項

Slide 42

Slide 42 text

42 【RFC 6797】 HTTP Strict Transport Security ● HSTS は Web サイトが安全な接続を介してのみアクセスできることを宣言できる仕組みである ● レスポンスヘッダに埋め込むことでブラウザが透過的に変換する ● Preload HSTS によって初回アクセス時にも適用可能 ● HSTS は中間者攻撃から守る効果があるだけでなく Cookie やセッションの問題を緩和する保険的対策にもなる ● 金銭的なコストをかけずにセキュアにできる ○ 導入時は慎重に作業したほうがいいまとめ

Slide 43

Slide 43 text

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