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

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

Jeremy Wagner

HTTPS の導入は近年着実に増加しています。HTTP Archive の 2021 Web Almanac によると、パソコンとモバイルの両方に対する全リクエストの約 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. HTTPS 経由のサーバーは、ブラウザと安全な接続をネゴシエートする必要があります。
  4. コンテンツが通常どおり読み込まれます。

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

HSTS を入力

対応ブラウザ

  • 4
  • 12
  • 4
  • 7

ソース

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

HSTS ヘッダーによってトリガーされる、HTTP から HTTPS への 307 内部リダイレクト。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 は max-age=86400 の HSTS ポリシーを指定していますが、今後この数はほぼ確実に増加します。

HSTS をデプロイするときに、長い max-age 値で出て行くことは望ましくありません。ユーザーが問題が発生したときに、突然問題の解決に忙殺されることがあります。小さく始めて、時間をかけて徐々に増やしていきます。問題がないことを確認したら、max-age ディレクティブにもっと長い期間を設定できます。完全に展開された時点で、max-age を 1 年か 2 年に設定することをおすすめします。

HSTS プリロード リストを使用したより安全で高速な初期ナビゲーション

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

使ってみる

BBC が HSTS を問題なくテストできると思ったら、ご自身のウェブサイトでも同じテストを実施できる可能性が高いです。ご自身のウェブサイトで試し、改善をお考えの場合はバグがないことが確認でき次第、HSTS プリロード リストに追加して、ユーザーにより安全で高速なエクスペリエンスを提供します。