HTTP 厳格なトランスポートセキュリティ

HTTP Strict Transport Security ( HSTS ) は、プロトコルダウングレード攻撃^[1]やCookie ハイジャックなどの中間者攻撃から Web サイトを保護するためのポリシーメカニズムです。これにより、Web サーバーは、Web ブラウザー (またはその他の準拠したユーザーエージェント) が、安全でない HTTP のみを使用する場合とは異なり、トランスポート層セキュリティ(TLS/SSL)を提供するHTTPS接続のみを使用して自動的に対話することを宣言できます。HSTS はIETF 標準化過程プロトコルであり、 RFC 6797 で指定されています。

HSTS ポリシーは、という HTTP 応答ヘッダーフィールドを介してサーバーからユーザーエージェントに伝達されます。HSTS ポリシーは、ユーザーエージェントが安全な方法でのみサーバーにアクセスすべきStrict-Transport-Security期間を指定します。 ^[2]^{: §5.2} HSTS を使用する Web サイトは、HTTP 経由の接続を拒否するか、ユーザーを体系的に HTTPS にリダイレクトすることによって、クリアテキストの HTTP を受け入れないことがよくあります (ただし、これは仕様で必須ではありません)。その結果、TLS を実行できないユーザーエージェントはサイトに接続できなくなります。

この保護は、ユーザーがサイトに少なくとも 1 回アクセスした後にのみ適用され、「初回使用時の信頼」の原則に従います。この保護は、ユーザーがサイトに HTTP (HTTPS ではない) URL を入力または選択すると、Web ブラウザーなどのクライアントが HTTP 要求を行わずに自動的に HTTPS にアップグレードし、HTTP 中間者攻撃の発生を防ぎます。

仕様履歴

HSTS仕様は、2012年10月2日にIESGによって提案標準 RFCとして公開が承認された後、2012年11月19日にRFC 6797として公開されました。^[3]著者は、当初2010年6月17日にインターネットドラフトとして提出しました。インターネットドラフトへの変換に伴い、仕様名は「Strict Transport Security」（STS）から「HTTP Strict Transport Security」に変更されました。これは、仕様がHTTPにのみ適用されるためです。^[4]ただし、HSTS仕様で定義されているHTTP応答ヘッダーフィールドの名前は「Strict-Transport-Security」のままです。

当時「STS」と呼ばれていた仕様の最後のいわゆる「コミュニティバージョン」は、コミュニティのフィードバックに基づいて改訂され、2009年12月18日に公開されました。^[5]

PayPalのJeff Hodges 、Collin Jackson、Adam Barthによる最初のドラフト仕様は2009年9月18日に公開されました^。[6]

HSTS仕様は、ジャクソンとバースの論文「ForceHTTPS: ネットワーク攻撃からの高セキュリティWebサイトの保護」に記載されているオリジナルの研究に基づいています。^[7]

さらに、HSTSは、ジェフ・ホッジスとアンディ・スタイングルーブルが2010年の論文「一貫したWebセキュリティポリシーフレームワークの必要性」で提唱した、Webセキュリティを改善するための全体的なビジョンの一側面を実現したものです。^[8]

HSTS メカニズムの概要

サーバーは、HTTPS接続でヘッダーを提供することでHSTSポリシーを実装します（HTTP経由のHSTSヘッダーは無視されます）。^[1]たとえば、サーバーは、今後1年間のドメインへのリクエスト（max-ageは秒単位で指定され、31,536,000はうるう年以外の1年に相当します）ではHTTPSのみを使用するようにヘッダーを送信できますStrict-Transport-Security: max-age=31536000。

ウェブアプリケーションがユーザーエージェントにHSTSポリシーを発行すると、準拠したユーザーエージェントは次のように動作します。^[2]^{: §5}

Web アプリケーションを参照する安全でないリンクを安全なリンクに自動的に変換します (たとえば、サーバーにアクセスする前にhttp://example.com/some/page/に変更されます)。https://example.com/some/page/
接続のセキュリティが保証できない場合（例えば、サーバーのTLS 証明書が信頼されていない場合）、ユーザーエージェントは接続を終了する必要があり^[2]^：§8.4、ユーザーがWebアプリケーションにアクセスすることを許可すべきではない。^[2]^：§12.1

HSTSポリシーは、Webアプリケーションユーザーを一部の受動的な（盗聴）および能動的なネットワーク攻撃から保護するのに役立ちます。^[2]^：§2.4中間者攻撃者は、ユーザーのブラウザでそのWebアプリケーションに対してHSTSポリシーが有効になっている間、ユーザーとWebアプリケーションサーバー間の要求と応答を傍受する能力が大幅に低下します。

適用範囲

HSTS が修正できる最も重要なセキュリティ脆弱性は、SSL ストリッピング中間者攻撃です。これは、 Moxie Marlinspike氏が2009 年の BlackHat Federal 講演「実践的に SSL を打ち破る新しいトリック」で初めて公開しました。 ^[9]^[10] SSL (およびTLS ) ストリッピング攻撃は、安全なHTTPS接続をプレーン HTTP 接続に透過的に変換することによって機能します。ユーザーは接続が安全でないことがわかりますが、重要なことに、接続が安全であるかどうかを知る方法はありません。Marlinspike 氏の講演の時点では、多くの Web サイトが TLS/SSL を使用していなかったため、プレーン HTTP の使用が攻撃によるものなのか、単に Web サイトが TLS/SSL を実装していなかったためなのかを知る方法がありませんでした (事前の知識がなければ)。さらに、ダウングレードプロセス中にユーザーに警告が提示されないため、最も用心深いユーザー以外にはこの攻撃はかなり巧妙なものになります。Marlinspike 氏の sslstrip ツールは、この攻撃を完全に自動化します。^[要出典]

HSTSはこの問題に対処します^[2]^：§2.4、サイトへの接続には常にTLS/SSLを使用するようにブラウザに通知します。これがユーザーの初めての訪問である場合、攻撃者はHSTSヘッダーを削除することができます。Google Chrome、Mozilla Firefox、Internet Explorer、およびMicrosoft Edgeは、HSTSサイトの「プリロード」リストを含めることでこの問題を制限しようとします。^[11]^[12]^[13]残念ながら、このソリューションはインターネット上のすべてのWebサイトを含めるように拡張できません。以下の制限を参照してください。

HSTSは、 Firesheepなどの広く利用可能なツールによってCookieベースのWebサイトのログイン資格情報が盗まれるのを防ぐのにも役立ちます。^[14]

HSTSは時間制限があるため、偽のNTPパケットなどを使用して被害者のコンピュータの時間をずらす攻撃に対して敏感です。^[15]

制限事項

最初のリクエストは、プレーンHTTPなどの安全でないプロトコルを使用している場合、または最初のリクエストのURIが安全でないチャネルを介して取得された場合、アクティブな攻撃から保護されません。^[2]^：§14.6同じことが、アドバタイズされたHSTSポリシーで指定されたアクティビティ期間後の最初のリクエストに適用されますmax-age（サイトは、ユーザーのアクティビティと動作に応じて数日または数か月の期間を設定する必要があります）。

プリロードリストを使用したソリューション

Google Chrome、Mozilla Firefox、Internet Explorer / Microsoft Edgeは、HSTSをサポートする既知のサイトを含むリストである「HSTSプリロードリスト」を実装することでこの制限に対処しています。^[16]^[11]^[12]^[13]このリストはブラウザとともに配布されるため、リストされたサイトへの最初のリクエストにもHTTPSが使用されます。前述のように、これらのプリロードリストはWeb全体をカバーすることはできません。潜在的な解決策は、DNSレコードを使用してHSTSポリシーを宣言し、DNSSEC経由で安全にアクセスし、オプションで証明書のフィンガープリントを使用して有効性を保証することです（ラストマイルの問題を回避するために検証リゾルバを実行する必要があります）。^[17]

Junade Aliは、HSTSは偽のドメインの使用に対しては効果がないと述べています。DNSベースの攻撃を使用すると、中間者インターセプターがHSTSプリロードリストにない人工ドメインからのトラフィックを処理することが可能になり、^{[18] DNSスプーフィング攻撃}^[19]によって可能になるか、または単にwww.example.comではなくwww.example.orgのように実際のドメイン名に誤解を招くようなドメイン名を使用することになります。

HSTS プリロードリストを使用しても、HSTS は、Juliano Rizzo と Thai Duong によってもたらされたBEAST攻撃やCRIME攻撃など、TLS 自体に対する高度な攻撃を防ぐことはできません。TLS 自体に対する攻撃は、HSTS ポリシーの適用とは直交しています。サーバーへの攻撃から保護することもできません。誰かがサーバーを侵害した場合、サーバーは TLS 経由であらゆるコンテンツを提供します。

プライバシーの問題

HSTS は、ブラウザの「シークレット」プライバシーモードのオン/オフに関係なく存続できる回復可能な識別データ (スーパークッキー) を使用して、訪問中のブラウザにほぼ消えないタグを付けるために使用されます。たとえば、選択したドメインに複数の HTTP リクエストを送信する Web ページを作成すると、20 の異なるドメインに 20 のブラウザリクエストが使用される場合、理論的には 100 万人を超える訪問者を区別できます (2 ²⁰ )。これは、結果として生じるリクエストが HTTP 経由か HTTPS 経由かによって決まります。後者は、以前に HSTS ヘッダー経由で確立された、以前に記録されたバイナリ「ビット」です。^[20]

ブラウザのサポート

ChromiumとGoogle Chromeバージョン4.0.211.0以降^[21]^[22]
Firefoxバージョン4以降。^[1] Firefox 17では、MozillaはHSTSをサポートするウェブサイトのリストを統合しています。^[12]
Operaバージョン12以降^[23]
OS X Mavericks以降のSafari（バージョン10.9、2013年後半）^[24]
KB3058515がインストールされたWindows 8.1およびWindows 7上のInternet Explorer 11（2015年6月にWindows Updateとしてリリース）^[25]
Windows 10上のMicrosoft EdgeとInternet Explorer 11 ^[26]^[27]
BlackBerry OS 10.3.3 以降のBlackBerry 10ブラウザおよび WebView。

導入のベストプラクティス

実際の展開によっては、ベストプラクティスに従うことで回避できる特定の脅威 (Cookie インジェクション攻撃など) が存在します。

HSTSホストは、トップレベルドメイン名でHSTSポリシーを宣言する必要があります。たとえば、https://sub.example.comのHSTSホストは、https://example.comのHSTSヘッダーで応答する必要があります。ヘッダーにはincludeSubDomainsディレクティブを指定する必要があります。^[2]^：§6.1.2
HSTSの展開に加えて、https://www.example.comのホストは、https://example.comからのリソースへのリクエストを含め、親ドメインのHSTSが設定されていることを確認して、攻撃者が応答する親ドメイン（またはhttp://nonexistentpeer.example.com）への参照を挿入する中間者による潜在的なCookieインジェクション攻撃からユーザーを保護する必要があります。^[2]^：§11.4

参照

RFC 6797 - HSTS のセキュリティに関する全体的な考慮事項についての議論
コンテンツセキュリティポリシー
.dev TLD – HSTS プリロードリストにデフォルトで含まれる Google が運営する TLD
HTTP 公開鍵のピン留め

参考文献

^ abc "Strict-Transport-Security". MDN Web Docs . Mozilla . 2020年3月20日時点のオリジナルよりアーカイブ。 2018年1月31日閲覧。
^ abcdefghi J. Hodges、C. Jackson、A. Barth (2012 年 11 月)。HTTP Strict Transport Security (HSTS)。インターネットエンジニアリングタスクフォース。doi : 10.17487/ RFC6797。ISSN 2070-1721。RFC 6797 。 提案された標準。
^ 「[websec] プロトコルアクション: 'HTTP Strict Transport Security (HSTS)' から Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)」。2012年10月2日。2017年1月29日時点のオリジナルよりアーカイブ。 2012年10月2日閲覧。
^ Hodges, Jeff (2010年6月30日). 「Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)」。2017年2月2日時点のオリジナルよりアーカイブ。2010年7月22日閲覧。
^ “Strict Transport Security -06”. 2009年12月18日. 2017年2月21日時点のオリジナルよりアーカイブ。 2009年12月23日閲覧。
^ “Strict Transport Security -05”. 2009年9月18日. 2020年2月24日時点のオリジナルよりアーカイブ。 2009年11月19日閲覧。
^ 「ForceHTTPS: ネットワーク攻撃から高セキュリティ Web サイトを保護する」。2008 年 4 月。2020 年 2 月 28 日時点のオリジナルよりアーカイブ。2009年11 月 19 日閲覧。
^ Hodges, Jeff; Steinguebl, Andy (2010 年 10 月 29 日). 「一貫性のある Web セキュリティポリシーフレームワークの必要性」。2017 年 8 月 14 日時点のオリジナルよりアーカイブ。2012 年11 月 21 日閲覧。
^ Marlinspike, Moxie (2009). 実践的に SSL を破るための新しいトリック(PDF)。Black Hat Briefings。ワシントン DC。2014年 12 月 30 日時点のオリジナルからアーカイブ(PDF) 。2012 年3 月 15 日閲覧。
^ YouTubeの Sslstrip を使用して SSL を無効にする
^ ab Langley, Adam (2010年7月8日). 「Strict Transport Security」. The Chromium Projects . 2019年9月1日時点のオリジナルよりアーカイブ。2010年7月22日閲覧。
^ abc Keeler, David (2012年11月1日). 「HSTSのプリロード」。Mozillaセキュリティブログ。2020年2月24日時点のオリジナルよりアーカイブ。 2014年2月6日閲覧。
^ ab Bell, Mike; Walp, David (2015年2月16日). 「HTTP Strict Transport Security が Internet Explorer に導入」。2015年11月15日時点のオリジナルよりアーカイブ。 2015年2月16日閲覧。
^ Hodges, Jeff (2010年10月31日). 「FiresheepとHSTS (HTTP Strict Transport Security)」。2016年6月23日時点のオリジナルよりアーカイブ。2011年3月8日閲覧。
^ Selvi, Jose (2014 年 10 月 17 日). HTTP Strict Transport Security のバイパス(PDF) . Black Hat Briefings . アムステルダム. 2014 年 10 月 22 日時点のオリジナルよりアーカイブ(PDF) . 2014 年10 月 22 日閲覧。
^ 「Chromium HSTS プリロードリスト」。cs.chromium.org。2020年 2 月 18 日時点のオリジナルよりアーカイブ。2019 年7 月 10 日閲覧。
^ Butcher, Simon (2011年9月11日). 「HTTP Strict Transport Security」。2019年4月26日時点のオリジナルよりアーカイブ。 2012年3月27日閲覧。
^ Ali, Junade (2017 年 10 月 20 日). 「SSL ストリッピングの実行と防止: わかりやすい英語の入門書」。Cloudflare ブログ。2019 年 12 月 14 日時点のオリジナルよりアーカイブ。2017 年12 月 7 日閲覧。
^ Maksutov, AA; Cherepanov, IA; Alekseev, MS (2017). DNS スプーフィング攻撃の検出と防止。2017 シベリアデータサイエンスエンジニアリングシンポジウム (SSDSE)。pp. 84–87。doi : 10.1109 / SSDSE.2017.8071970。ISBN 978-1-5386-1593-5. S2CID 44866769。
^ 「HSTS スーパー Cookie がユーザーに選択を迫る:「プライバシーかセキュリティか?」 -」sophos.com 2015 年 2 月 2 日。2020 年 2 月 11 日時点のオリジナルよりアーカイブ。2015年12 月 1 日閲覧。
^ The Chromium Developers (2010年11月17日). 「Strict Transport Security - The Chromium Projects」。2020年3月20日時点のオリジナルよりアーカイブ。2010年11月17日閲覧。
^ Hodges, Jeff (2009年9月18日). 「fyi: Strict Transport Security仕様」。2020年2月29日時点のオリジナルよりアーカイブ。2009年11月19日閲覧。
^ Opera Software ASA (2012年4月23日). 「Opera Presto 2.10 での Web 仕様のサポート」。2018年6月20日時点のオリジナルよりアーカイブ。2012年5月8日閲覧。
^ Langley, Adam [@agl__] (2013年12月20日). 「確認しました。~/Library/Cookies/HSTS.plistを参照してください。ある日付のChromiumプリロードを含み、HSTSヘッダーを処理します」（ツイート）。2019年5月9日時点のオリジナルよりアーカイブ。 2013年12月20日閲覧– Twitter経由。
^ 「HTTP Strict Transport Security が Windows 8.1 および Windows 7 上の Internet Explorer 11 に導入」。windows.com。2019年 11 月 27 日時点のオリジナルよりアーカイブ。2015 年6 月 12 日閲覧。
^ 「Internet Explorer Web プラットフォームの現状とロードマップ」。2015 年 6 月 29 日時点のオリジナルよりアーカイブ。2014 年4 月 14 日閲覧。
^ “Project Spartan と Windows 10 January Preview Build - IEBlog”. 2015年1月22日. 2019年11月29日時点のオリジナルよりアーカイブ。 2015年1月23日閲覧。

外部リンク

IETF WebSecワーキンググループ
セキュリティナウ262: 厳格な輸送セキュリティ
オープン Web アプリケーションセキュリティプロジェクト (OWASP): HSTS の説明
オンラインブラウザ HSTS および公開鍵ピンニングテスト
Google Chrome、Mozilla Firefox、Safari、IE 11、Edge 向け HSTS プリロード送信
Chromium HSTS プリロードリスト
MDN Web Docsの Strict-Transport-Security

[mdn-security-1] "Strict-Transport-Security". MDN Web Docs . Mozilla . 2020年3月20日時点のオリジナルよりアーカイブ。 2018年1月31日閲覧。

[rfc6797-2] J. Hodges、C. Jackson、A. Barth (2012 年 11 月)。HTTP Strict Transport Security (HSTS)。インターネットエンジニアリングタスクフォース。doi : 10.17487/ RFC6797。ISSN 2070-1721。RFC 6797 。 提案された標準。

[hsts-ps-rfc-approval-iesg-msg-3] 「[websec] プロトコルアクション: 'HTTP Strict Transport Security (HSTS)' から Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)」。2012年10月2日。2017年1月29日時点のオリジナルよりアーカイブ。 2012年10月2日閲覧。

[4] Hodges, Jeff (2010年6月30日). 「Re: [HASMAT] "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)」。2017年2月2日時点のオリジナルよりアーカイブ。2010年7月22日閲覧。

[STS-draft-spec-2-5] “Strict Transport Security -06”. 2009年12月18日. 2017年2月21日時点のオリジナルよりアーカイブ。 2009年12月23日閲覧。

[draft-spec-6] “Strict Transport Security -05”. 2009年9月18日. 2020年2月24日時点のオリジナルよりアーカイブ。 2009年11月19日閲覧。

[forcehttps-paper-7] 「ForceHTTPS: ネットワーク攻撃から高セキュリティ Web サイトを保護する」。2008 年 4 月。2020 年 2 月 28 日時点のオリジナルよりアーカイブ。2009年11 月 19 日閲覧。

[web-sec-policy-frmwk-8] Hodges, Jeff; Steinguebl, Andy (2010 年 10 月 29 日). 「一貫性のある Web セキュリティポリシーフレームワークの必要性」。2017 年 8 月 14 日時点のオリジナルよりアーカイブ。2012 年11 月 21 日閲覧。

[9] Marlinspike, Moxie (2009). 実践的に SSL を破るための新しいトリック(PDF)。Black Hat Briefings。ワシントン DC。2014年 12 月 30 日時点のオリジナルからアーカイブ(PDF) 。2012 年3 月 15 日閲覧。

[10] YouTubeの Sslstrip を使用して SSL を無効にする

[preloading_hsts_chromium-11] Langley, Adam (2010年7月8日). 「Strict Transport Security」. The Chromium Projects . 2019年9月1日時点のオリジナルよりアーカイブ。2010年7月22日閲覧。

[preloading_hsts_mozillla-12] Keeler, David (2012年11月1日). 「HSTSのプリロード」。Mozillaセキュリティブログ。2020年2月24日時点のオリジナルよりアーカイブ。 2014年2月6日閲覧。

[iepreload-13] Bell, Mike; Walp, David (2015年2月16日). 「HTTP Strict Transport Security が Internet Explorer に導入」。2015年11月15日時点のオリジナルよりアーカイブ。 2015年2月16日閲覧。

[14] Hodges, Jeff (2010年10月31日). 「FiresheepとHSTS (HTTP Strict Transport Security)」。2016年6月23日時点のオリジナルよりアーカイブ。2011年3月8日閲覧。

[15] Selvi, Jose (2014 年 10 月 17 日). HTTP Strict Transport Security のバイパス(PDF) . Black Hat Briefings . アムステルダム. 2014 年 10 月 22 日時点のオリジナルよりアーカイブ(PDF) . 2014 年10 月 22 日閲覧。

[16] 「Chromium HSTS プリロードリスト」。cs.chromium.org。2020年 2 月 18 日時点のオリジナルよりアーカイブ。2019 年7 月 10 日閲覧。

[17] Butcher, Simon (2011年9月11日). 「HTTP Strict Transport Security」。2019年4月26日時点のオリジナルよりアーカイブ。 2012年3月27日閲覧。

[auto-18] Ali, Junade (2017 年 10 月 20 日). 「SSL ストリッピングの実行と防止: わかりやすい英語の入門書」。Cloudflare ブログ。2019 年 12 月 14 日時点のオリジナルよりアーカイブ。2017 年12 月 7 日閲覧。

[19] Maksutov, AA; Cherepanov, IA; Alekseev, MS (2017). DNS スプーフィング攻撃の検出と防止。2017 シベリアデータサイエンスエンジニアリングシンポジウム (SSDSE)。pp. 84–87。doi : 10.1109 / SSDSE.2017.8071970。ISBN 978-1-5386-1593-5. S2CID 44866769。

[20] 「HSTS スーパー Cookie がユーザーに選択を迫る:「プライバシーかセキュリティか?」 -」sophos.com 2015 年 2 月 2 日。2020 年 2 月 11 日時点のオリジナルよりアーカイブ。2015年12 月 1 日閲覧。

[chromium_sts-21] The Chromium Developers (2010年11月17日). 「Strict Transport Security - The Chromium Projects」。2020年3月20日時点のオリジナルよりアーカイブ。2010年11月17日閲覧。

[22] Hodges, Jeff (2009年9月18日). 「fyi: Strict Transport Security仕様」。2020年2月29日時点のオリジナルよりアーカイブ。2009年11月19日閲覧。

[opera_presto-23] Opera Software ASA (2012年4月23日). 「Opera Presto 2.10 での Web 仕様のサポート」。2018年6月20日時点のオリジナルよりアーカイブ。2012年5月8日閲覧。

[24] Langley, Adam [@agl__] (2013年12月20日). 「確認しました。~/Library/Cookies/HSTS.plistを参照してください。ある日付のChromiumプリロードを含み、HSTSヘッダーを処理します」（ツイート）。2019年5月9日時点のオリジナルよりアーカイブ。 2013年12月20日閲覧– Twitter経由。

[25] 「HTTP Strict Transport Security が Windows 8.1 および Windows 7 上の Internet Explorer 11 に導入」。windows.com。2019年 11 月 27 日時点のオリジナルよりアーカイブ。2015 年6 月 12 日閲覧。

[26] 「Internet Explorer Web プラットフォームの現状とロードマップ」。2015 年 6 月 29 日時点のオリジナルよりアーカイブ。2014 年4 月 14 日閲覧。

[27] “Project Spartan と Windows 10 January Preview Build - IEBlog”. 2015年1月22日. 2019年11月29日時点のオリジナルよりアーカイブ。 2015年1月23日閲覧。