こんにちは、バックエンドエンジニアの Kaz です。
今回は Web サイトとユーザーを保護する「 SSL 」をテーマに、 正しくサイトの強制 SSL 化を行って、すべての通信、ユーザーとサービスを保護しよう というお話をします。
目次
暗号化だけじゃない!?SSLが保護するもう一つの安全機能
まず今回のお話の大前提といて、SSL を使って何を保護できるのかを知る必要があります。
通信の暗号化
よく知られているものでは「通信の暗号化」というものがあります。これはユーザーが使っている Web ブラウザーアプリケーション( Google Chrome や Safari など)と、Web サイトを提供している事業者側の Web サーバーの間の通信を暗号化し、第三者に そのままでは 通信を覗き見られないようにするものです。
インターネットは仕組み上、通信途中で多数の第三者のサーバーを経由しながらさまざまなルートを通って通信が行われるため、通信内容を暗号化しないと、その経由ルートすべてで通信内容が見られてしまいます。
ここで、たとえばクレジットカード番号や銀行口座のオンラインバンキングにログインするためのパスワードなどが 悪意ある第三者に見られてしまうと大損害を被ってしまいますよね。これを防ぐために「 SSL で通信を暗号化しましょう」というのが SSL の主な目的になっています。
通信相手の証明
単純に通信を暗号化するだけでは、本当の安心は得られません。中間者攻撃と呼ばれる手法で、攻撃者は本物のサーバー(たとえば銀行)になりすました偽物のサーバーを立てて、通信内容をあたかも本物に見せかけて中継することで、通信を覗き見たり通信内容を改ざんしたりすることができてしまいます。
この中間者攻撃を防ぐためには、通信相手のサーバーが「確実に本物なのか」を証明する手立てが必要になってきます。SSL が提供するもうひとつの保護機能が、この「サーバーが本物であることの証明」です。
SSL を導入する際に「 SSL サーバー証明書」を認証機関に発行してもらう必要があるのはこのためで、面倒な CSR の作成や秘密鍵の管理、ドメイン名の所有権確認などは、すべてサーバーが本物であることを証明するための内部処理に求められるものになっています。
すべての通信をSSLにしなければ、安全は確保できない
Web サイトを作るとき「ログイン画面やお問い合わせフォームだけ https ( SSL 等で保護された HTTP 通信)の URL にする」といった設計にすることがあります。この場合、普通であれば「ユーザーが入力した情報は SSL で保護されるので安心」と思えるのですが、これではまだ先ほど挙げた中間者攻撃などのリスクが出てきます。
具体的には、攻撃者は SSL で保護されていないページに対して中間者攻撃を仕掛け、そのページに含まれるお問い合わせフォームへのリンクなどを書き換えて http の URL に差し替えることができます。これをされてしまうと、いくら本物を SSL で保護していても、ユーザーは暗号化の施されていない偽物サーバー上で気づかずに 秘密の情報を入力されてしまいかねません。
これを防ぐため、SSL を導入する際は原則として「すべてのページを SSL にする」「 HTTP のアクセスはすべて HTTPS に 301 リダイレクトする」と言った対策が必要です。
HSTSでSSL通信を強制させる
しかし、ここまでやっても実は不十分です。たとえすべてのページを HTTPS に書き換えても、ユーザーがもしブックマークや別サイトのリンクから HTTP の URL でアクセスしてきた場合、依然として中間者攻撃を行われるリスクが出るからです。
そこで SSL による保護を確実なものとするために、Web ブラウザに「このサイトは HTTPS のページしか提供しないので、絶対に HTTP でつながないでね」と伝える必要が出てきます。これを可能とするのが今回紹介する「 HSTS 」という規格になります。
HSTS は「今後このサイトのドメインにアクセスするときは問答無用で強制的に HTTPS に切り替えてね」とブラウザに伝えるもので、また申請すればなんと Web ブラウザーにプリインストールされる HSTS 対応サイトリストに掲載してもらう( HSTS Preload )こともできるようになっています。
Web ブラウザにプリインストールされることで、有効な SSL 証明書なしに中間者攻撃を行う手立てはほぼなくなります。これでようやく「確実な安全性」を得られます。
HSTSによる強制SSL化の手順
HSTS を用いた強制 SSL 化は、下記の手順で行います。
- サイトを SSL に対応 させる
- リンクや画像、CSS や Javascript などあらゆるリソースの読み込みURLを HTTPS に変更する
- サーバーで すべての HTTP リクエストを HTTPS に 301 リダイレクト する
- HSTS を有効 にする
- HSTS Preload の登録申請 をする
HSTSを有効にする
HSTS を有効にするには、Web サーバーの設定を変更して Strict-Transport-Security
というヘッダーを付加するようにします。
Strict-Transport-Security: max-age=63072000
ここの max-age
はブラウザーに HSTS の設定を覚えてもらう有効期限です。ここでは 2 年間を表す 63072000
秒を指定していますが、HSTS は一度ブラウザに覚えられてしまうとその期間中は戻せなくなってしまうため、最初はテストで 300
秒( 5 分)などの短い時間にし、徐々に増やしていくのをオススメします。
すべてのサブドメインにもHSTSを適用する
またサブドメインも含めたすべての配下ドメインへのアクセスに HSTS を適用することもでき、その場合は includeSubdomains
というディレクティブを追加します。
Strict-Transport-Security max-age=63072000; includeSubdomains
なお、前述のとおり HSTS の設定は有効期限がすぎるまで戻せなくなってしまうため、慎重な設定が必要です。特に安易に includeSubdomains
を有効にしてしまうと、SSL を導入していないサイトがサブドメインにある場合(たとえばテスト環境など)、それらへ一切アクセスできなくなってしまいます。
Apacheでの設定方法
Apache では、下記の設定を httpd.conf
や .htaccess
に追記することで Strict-Transport-Security
ヘッダーを送出できます。
Header always set Strict-Transport-Security "max-age=63072000"
Nginxでの設定方法
Nginx をお使いの場合は、下記の設定を nginx.conf
に追記します。
add_header Strict-Transport-Security "max-age=63072000";
確認する
Google Chrome を使っている場合、アドレスバーに chrome://net-internals/#hsts
と入力することで HSTS に関する Google Chrome の内部設定ページを開くことができます。
ここで HSTS 設定したドメイン名を Query
することで、Google Chrome が現在記憶しているHSTSの状態を確認することができます。
HSTS Preloadの登録申請をする
WebブラウザーにHSTS対応サイトとしてプリインストールしてもらうには、 hstspreload.org にて登録申請を行います。
申請条件
なおHSTS Preloadの申請には下記の条件が設定されています。
max-age
は最低31536000
秒( 1 年)以上でなければならないincludeSubDomains
ディレクティブを指定しなければならないpreload
ディレクティブを指定しなければならない (後述)- HTTPS サイトからさらにリダイレクトを行っている場合、そのリダイレクトも HSTS ヘッダーを保持しなければならない(リダイレクト先のページではない)
このなかで特に注意が必要なのが includeSubDomains
ディレクティブの指定です。前述のとおりこのディレクティブを付記する場合はすべてのサブドメインで SSL に対応する必要があるため、非対応のサブドメインがある場合は HSTS Preload は利用できません。
申請の事前準備
登録申請を行う際は、申請条件にもあるとおり事前に Strict-Transport-Security
ヘッダーに preload
ディレクティブを付記し、「このドメインは preload に追加してもいいよ」ということを明示する必要があります。
Strict-Transport-Security max-age=63072000; includeSubDomains; preload
申請
申請条件をすべて満たしたら、hstspreload.org にドメイン名を入力して登録申請を行います。
登録申請が認められたら、Google Chrome など各ブラウザにプリインストールされる HSTS 対応サイトリストに追加され、各ブラウザがアップデートされた際に世界中のユーザーに HSTS が適用されるようになります。
HSTSの注意点
HSTS はその安全性と引き換えに、一度設定するとカンタンには戻せない強力な機能になっています。
万が一 SSL に対応できないページやサブドメインがあった場合は計り知れない影響を受ける可能性があるので、HSTS を設定する際は極めて慎重に、前述のように徐々に max-age
を増やしていくような形で導入を行うことを強くオススメします。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。