BBC がセキュリティとパフォーマンスを向上させるために HSTS をどのように展開しているか。

BBC は、セキュリティとパフォーマンスを向上させるために、ウェブサイトに HSTS を展開しています。その意味と HSTS がどのように役立つかをご確認ください。

Jeremy Wagner

HTTPS の採用は近年着実に増加しています。HTTP Archive の 2021 年のウェブ アルマナックによると、パソコンとモバイルの両方で、全リクエストの約 91% が HTTPS で処理されています。HTTPS は存在するだけでなく、Service Worker などの機能や HTTP/2 や HTTP/3 などの最新のプロトコルを使用するうえで必要な前提条件です。

先日、BBC のリード テクニカル アーキテクトである Neil Craig 氏が、bbc.com の HTTP Strict Transport Security（HSTS）が段階的に展開されるというツイートを投稿しました。これが BBC やあなたにとってどのような意味を持つのかを考えてみましょう。

問題

ウェブサーバーは多くの場合、ポート 80 と 443 の両方でリクエストをリッスンします。ポート 80 は安全でない HTTP リクエスト用で、443 は安全な HTTPS 用です。これにより、アドレスバーに https:// プロトコル プレフィックスを付けずにアドレスを入力すると（ほとんどのユーザーがそうであるように）、一部のブラウザでは従来の理由から、サイトの HTTP バージョンにトラフィックが転送されてしまうことがあります（ただし、常にそうとは限りません）。

セキュリティで保護されていないバージョンのウェブサイトにユーザーがアクセスしないようにするための一般的な方法は、すべてのリクエストに HTTP から HTTPS へのリダイレクトを設定することです。これは確かに機能しますが、次の一連のイベントが開始されます。

  1. サーバーが HTTP リクエストを受信します。
  2. サーバーは、要求されたリソースに相当する HTTPS にリダイレクトする。
  3. サーバーは、ブラウザとの安全な接続をネゴシエートする必要があります。
  4. コンテンツは通常どおり読み込まれます。

リダイレクトは問題なく機能しますが、設定が不適切であり、保護されていないバージョンのサイトにアクセスしてしまう可能性があります。すべてが適切に構成されている場合でも、リダイレクト フェーズ中にユーザーが安全でない HTTP 経由で接続するというセキュリティ上の問題があります。これにより、ユーザーは危険な中間者攻撃にさらされることになります。

HSTS を入力

対応ブラウザ

  • 4
  • 12
  • 4
  • 7

ソース

HSTS は、HTTPS リクエストに対する Strict-Transport-Security HTTP レスポンス ヘッダーによって決まります。このポリシーを設定した場合、ウェブサイトに再びアクセスすると、「307 内部リダイレクト」と呼ばれる特別なリダイレクトがトリガーされます。このリダイレクトは、サーバーではなくブラウザがリダイレクト ロジックを処理するときに行われます。これにより、リクエストがブラウザの外部に出ることがないため、インターセプトされず、安全性が高まります。さらに、これらのタイプのリダイレクトは非常に高速であるため、HTTP から HTTPS へのホップの間の顕著なレイテンシは発生しません。

HTTP から HTTPS への 307 内部リダイレクト。HSTS ヘッダーによってトリガーされます。307 リダイレクトにかかる時間はわずか 2 ミリ秒です。

Cache-Control の max-age ディレクティブの構文と同様に、HSTS ヘッダーでは max-age ディレクティブを指定します。このディレクティブは、ポリシーの有効期間を指定する値を秒単位で指定します。

Strict-Transport-Security: max-age=3600

上記の例では、ポリシーは 1 時間のみ有効になります。

HSTS のデプロイ

HSTS をデプロイする主なデメリットは、送信元を厳密に安全なものとして扱う準備ができていない場合です。たとえば、リソースを提供しているサブドメインがたくさんあるとしても、そのすべてが安全であるとは限らないとします。このシナリオでは、HSTS ヘッダーによってウェブサイトに障害が発生する可能性があります。

BBC は、HSTS の導入において適切なアプローチを採用しました。Neil Craig のツイートで述べたように、bbc.com に設定された初期値は max-age=10 でした。

このアプローチでは、ポリシーが当初有効だったのは 10 秒間だけでした。これによるメリットはあまりありませんが、HSTS の適用にまったく問題がないかどうかを調べることが目的です。時間が経つにつれて、ポリシーを段階的に増やして、問題が発生するかどうかを確認できます。このドキュメントの作成時点で、bbc.com は HSTS ポリシー max-age=86400 を指定していますが、このポリシーは今後ほぼ確実に増加する予定です。

HSTS をデプロイするときに、max-age 値が長くなりすぎないようにしたいものです。ユーザーが問題が発生したときに、急いで問題の解決に追われることもあるでしょう。小さなことから始めて、徐々に増やしていきましょう。問題がないことを確認したら、max-age ディレクティブの期間を長く設定できます。完全にロールアウトされたら、max-age を 1 年または 2 年に設定することをおすすめします。

HSTS プリロード リストを使用して、初期ナビゲーションをより安全かつ迅速に行う

HSTS ポリシーは、ウェブサイトに初めてアクセスした後にのみ有効となるため、サイトへの初回アクセスでは特典が表示されません。この場合も、安全でないリダイレクトが必要になります。ただし、HSTS プリロード リストにウェブサイトを送信することで、HSTS ポリシーをプリロードできます。これは、厳密に HTTPS であるとブラウザが認識しているウェブサイトのハードコード リストです。サイトがプリロード リストに含まれると、初回アクセスも保護され、HTTP から HTTPS へのリダイレクトは即座に行われます。

使ってみる

BBC が HSTS を安心してテストできるのであれば、ウェブサイトでも同様のテストを行うことができるでしょう。ウェブサイトで試してみましょう。改善を検討している場合は、バグがないことが確認できたら、HSTS プリロード リストに追加して、ユーザーに安全で高速なエクスペリエンスを提供します。