2019 年 11 月 5 日 Ryan Estes 著

はじめに

HTTP Strict Transport Security (HSTS) とは、HTTP セキュリティメカニズムの一種で、Web サイトがセキュア接続経由でのみアクセスできるように宣言することで、ユーザエージェント（UA）やブラウザが、セキュア接続でのみ Web サイトとやり取りできるようにするものです。この場合の「セキュア接続」とは、SSL/TLS で暗号化された HTTP 接続、すなわち、HTTPS 接続のことです。このメカニズムは、リダイレクトマッピングによって HTTPS を HTTP にダウングレードする sslstrip などのダウングレード攻撃から保護するよう設計されています。詳細の説明に先立ち、HSTS が登場した背景をお話ししておくことにしましょう。

HSTS の起源

HSTS は RFC 6797 に定義されているものですが、これを最初に開発したのは、スタンフォード大学の Adam Barth 氏と Collin Jackson 氏です。第 17 回 International World Wide Web Conference（2008 年）で発表した、「ForceHTTPS : Protecting High-Security Web Sites from Network Attacks（ForceHTTPS：重要 Web サイトのネットワーク攻撃からの保護）」という論文で、Jackson 氏と Barth 氏は、無線 Web ブラウズの急増が Web をブラウズするユーザに対する無線攻撃につながったかを解説しました。彼らが「ForceHTTPS」と呼んだこのメカニズムは、HTTPS の構成ミスを修正するよう設計されており、周知のように、構成ミスは、2019 年初めの Capital One の情報漏洩を始めとする組織への不正侵入の足掛かりとなり、情報漏洩や経済的損失の直接的な原因となっています。ForceHTTPS の導入は簡単で、サイト所有者が ForceHTTPS Cookie を設定するだけで、ブラウザが HTTPS の構成ミスを、単なるミスではなく、攻撃として処理するようになります。ForceHTTPS での攻撃は、HTTP サイトへの接続が HTTPS にリダイレクトされ、すべての TLS エラーによってセッションが終了し、HTTPSweb サイトに埋め込まれた HTTP コンテンツ（HTTP 広告 など）が動作しなくなることを意味します。

他のいくつかの論文も発表されたこともあり、この Adam Barth 氏と Collin Jackson 氏による論文の発表から間もない 2012 年 11 月に、HSTS が公開され、RFC 6797 に定義されました。RFC 6797 によると、「[RFC 6797] は [ForceHTTPS] によって提示されたアプローチを実装し改良するものである」とされており、すなわち HSTS は Barth 氏と Jackson 氏が ForceHTTPS での提案の進化版というわけです。HSTS は、発表が 2012 年の 11 月であったことを考えると、Black Hat DC 2009 での Moxie Marlinspike 氏による sslstrip のデモに対する直接的な対応とも考えられます。しかしながら、HSTS は、「安全でないクリックスルー」、つまり、ブラウザのセキュリティメカニズムがユーザにセキュリティ違反を通知したにもかかわらず、ユーザがプロンプトをクリックしてセキュリティメカニズムを無効にしてしまう状況にも対処しようとしました。

HSTS の仕組み

RFC 6797 は、Web サイトの所有者やブラウザまたはユーザエージェント（UA）が HSTS を満たすための 7 つの中核要件と 2 つの補助要件を提示しています。ドメイン所有者としての義務は以下のとおりです。

• ルート CA による検証が可能な有効な証明書を用意する
• ルート www サブドメインを含むすべてのサブドメインを経由する HTTP を 301 または 302 リダイレクトを使用して HTTPS にリダイレクトする
• HTTPS 要求の有効な HSTS ヘッダで、HSTS エントリがキャッシュされる時間も指定する

有効な HSTS ヘッダは次のようになります。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

解説

• Strict-Transport-Security – 必須。ヘッダの開始に関する RFC 6797 の定義
• max-age – 必須。UA がそのホストを既知の HSTS ホストと見なす秒単位の時間
• includeSubDomains – オプション。UA に対し、ポリシー全体が特定のドメインのサブドメインに適用されることを指示する
• preload – オプション。プリロードされたリストの一部

ヘッダの preload パラメータによって、Web サイトがブラウザに対し、HSTS の要件を満たし、TLS 経由でのみアクセスするよう指定できます。これにより、RFC 6796 で定義された HSTS のある脆弱性、すなわち、有効な HSTS ヘッダが含まれる最初の要求の、HSTS が有効である Web サイトをキャッシュする前の段階での sslstrip などの MitM 攻撃に対する脆弱性を回避できます。プリロードリストは、一般的にはブラウザで実行されるオプトインのみのポリシーです。Google は独自の HSTS プリロードリストを管理しており、他の多くのブラウザもこのマスタリストを使用しています。ただし、Cloudflare、Akamai などのサービスがある場合、このアクションを実行する独自の HSTS オプションがあります。

自らのドメインが HSTS の要件を満たしているかどうかをチェックし、プリロードリストに追加できる Web サイトがいくつかあります。
[以下は外部の Web サイトです]
https://hstspreload.org/
https://securityheaders.com/
https://www.ssllabs.com/ssltest/index.html
https://www.whoishostingthis.com/tools/user-agent/

HSTS が重要である理由

HSTS の重要性は、これを使用して防止しようとする攻撃を見れば明らかです。RFC 6797 では、HSTS を使用して防止する 3 種類の攻撃について説明されており、その 3 つとは、パッシブネットワーク攻撃、アクティブネットワーク攻撃、および Web サイト開発バグです。

パッシブネットワーク攻撃の最も代表的な例は、802.11 ネットワーク経由でパケットをスニッフィングし、不正 AP や悪魔の双子（正規のアクセスポイントを偽装してユーザをだます手法）を使った MitM の実行です。攻撃者は次に、すべての暗号化されていない情報をスニッフィングしたり、最悪の場合、セッションハイジャックなどに使用される可能性のある、暗号化されていない Cookie 情報を不正取得したりします。

アクティブネットワーク攻撃が 802.11 ネットワーク経由で実行される可能性もあり、Web トラフィックの間にプロキシを置いて、HTTPS トラフィックを同等の HTTP にリダイレクトすることで、標的に対する MitM 攻撃を実行できます。HSTS によって防止できるもう 1 つの重要な攻撃は、HTTPS 経由で送信されるセキュア Cookie やその他のコンテンツの不正取得です。攻撃者は、偽の証明書を提示し、すべてのトラフィックを平文で見ることさえできる可能性もあります。

Web サイト開発でバグは発生するものであるため、基本的に回避するのは不可避です。最善の対策は、綿密なソフトウェア開発ライフサイクルによってエラーを防止し、最新のコーディング基準とセキュリティ管理に開発者が確実に従うことです。また、実装しやすい基準と自然な流れで進行する UI を使うことで、開発者によるエラーを減らす工夫をすることも重要です。

さらに RFC 6797 は、ユーザが証明書の警告メッセージを無視してクリックするのを UA が禁止することで、ユーザの過失によるエラーを積極的に防ぐ必要があるとしています。

エクスプロイトの例

HSTS は、2009 年の Black Hat DC でのプレゼンテーションで Moxie Marlinspike 氏が実演した、SSL ストリッピング、あるいは SSL スニッフィングと考えられる、HTTPS に対する MitM 攻撃に対応するものではないかと考えられます。彼はまた、これらの攻撃を自動化する sslstrip と呼ばれるツールも併せて発表しています。

sslstrip2 の前身である sslstrip は、クライアントとサーバの通信の間にプロキシを置くことで HSTS を悪用します。プレゼンテーションでは、次のようなスクリーンショットで説明されています。

SSLStrip

HTTPS トラフィックを Web サーバに送信しようとするユーザが、MitM 攻撃によって、同じサイトの HTTP にリダイレクトされる（たとえば、https://facebook.com を http://facebook.com にリダイレクトされる）可能性もあります。このような脅威は、ドメインだけにとどまらず、sslstrip や sslstrip2 は、セッションキー、一意の識別子、開発者が保存することにしたその他情報などが含まれる、セキュア Cookie のストリッピングも可能です。

https://www.ssllabs.com/ssltest/index.html などの単純なアプリケーションでヘッダをチェックするだけで、Web サイトの簡単なセキュリティ状況を偵察できます。ヘッダをチェックすれば、HSTS が使用されているかどうか、リダイレクトが許可されているかどうか、また、Cookie が使用されている場合は、使用されている SSL のバージョンなどが明らかになります。

まとめ

HSTS は、HTTPS 要求の特定のヘッダによって強制されるセキュリティメカニズムであり、Moxie Marlinspike 氏による SSL スニッフィングと sslstrip のプレゼンテーションにほとんど直接的に対応するもです。HSTS は、HTTPS を採用していない Web サイトの不整合の修正を目的とし、ユーザが警告を無視してクリックするのを防ぎます。通信の間にプロキシを置くことで、攻撃者は、偽の証明書を提示し、正規の HTTP Web サイトへのリダイレクトをすることで、HTTPS トラフィックから SSL 暗号化をストリッピングできます。

これに対応するため、RFC 6797 は、HSTS の実装を比較的簡単にし、Web サイトの所有者がサブドメインを含むすべてのドメインで常に SSL/TLS 暗号化を使用できるようにします。問題が発生するのは、これがオプトインのみのポリシーである場合であり、多くの小規模 Web サイト、あるいは、大規模の Web サイトの所有者であっても、適切にオプトインしていない場合があります。したがって、多くの Web サイトで HSTS が使用されていないと、そのドメインが、ネットワーク、特に無線ネットワークへの攻撃ベクトルとなってしまいます。

これは、小さな問題の小さな修正ですが、大きな意味があります。HTTPS トラフィックを乗っ取られてしまうと、LAN または 802.11 ネットワーク経由で平文の機密データを攻撃者に読み取られてしまう可能性があるからです。

参考資料

Web サイト
https://tools.ietf.org/html/rfc6797
https://crypto.stanford.edu/forcehttps/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
https://https.cio.gov/hsts/
https://www.chromium.org/hsts
https://www.troyhunt.com/understanding-http-strict-transport/
https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols
https://www.globalsign.com/en/blog/what-is-hsts-and-how-do-i-use-it/
https://moxie.org/software/sslstrip
https://blog.cloudflare.com/enforce-web-policy-with-hypertext-strict-transport-security-hsts/

セキュリティチェック
https://hstspreload.org/
https://securityheaders.com/
https://www.ssllabs.com/ssltest/index.html
https://www.whoishostingthis.com/tools/user-agent/

PowerPoint
https://crypto.stanford.edu/forcehttps/forcehttps.ppt

ビデオ