このページは Cloud Translation API によって翻訳されました。

HTTPS と HTTP Strict のトランスポートセキュリティで悪意のある仲介者を混乱させる

Mike West

インターネットという大規模な一連のチューブを通過する個人データの量を考えると、暗号化は軽く無視できるものではなく、軽視すべきものでもありません。最新のブラウザには、ユーザーの転送中のデータを保護するためのメカニズムがいくつか用意されています。安全な Cookie と Strict Transport Security の 2 つが特に重要です。これにより、ユーザーをシームレスに保護し、接続を HTTPS にアップグレードして、ユーザーデータが暗号化されない状態で送信されないようにすることができます。

注目すべき理由次の点を考慮してください。

暗号化されていない HTTP 接続でウェブページを配信することは、道路で最初に見かけた郵便局の方向に歩いているように見える人に未封の封筒を渡すのとほぼ同じです。運が良ければ、彼女はそれをすべて引き継ぐか、正しい方向に向かっている人を次に見つけた人に引き渡します。その人物も同様にます

この即興の連鎖で見知らぬ人のほとんどは信頼でき、公開書を覗いたり、改ざんしたりすることはありません。ただし、手紙の持ち主が交代する回数が多いほど、送信する手紙への完全なアクセス権を持つ人の数が増えます。最終的に、手紙の宛先に何かが郵送で届く可能性は高いですが、それが最初の引き渡しと同じものであるかどうかは自由回答形式の質問です。封筒に封をすべきだったかもしれない...

ミドルマン

良くも悪くも、インターネットの広い範囲は見知らぬ人の信頼性にかかっています。サーバーは直接接続されていませんが、電話という巨大ゲームでは、リクエストとレスポンスをルーターからルーターへと渡します。

これらのホップの動作は traceroute で確認できます。パソコンから HTML5Rocks へのルートは次のようになります。

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 ホップは悪くないね。ただし、HTTP 経由でリクエストを送信する場合、各中間ルーターはリクエストとサーバーのレスポンスに完全にアクセスできます。すべてのデータは暗号化されていない平文として転送されます。これらの中間データは中間者として機能し、データの読み取りや転送中のデータ操作を行うことができます。

さらに悪いことに、この種の傍受はほとんど検知されません。不正に変更された HTTP レスポンスは、受信したデータが完全に送信されたデータであることを確認できるメカニズムが存在しないため、有効なレスポンスとまったく同じように見えます。誰かが笑うためにインターネットを逆さまに決めたとしたら、私はほとんど幸運にもなりません。

この回線は安全ですか？

平文の HTTP から安全な HTTPS 接続に切り替えると、仲介者に対する防御を強化できます。HTTPS 接続は、データが送信される前にチャネル全体をエンドツーエンドで暗号化するため、ユーザーと宛先の間のマシンが転送中のデータの読み取りや変更を行うことはできません。

Chrome のアドレスバーには、接続のステータスに関する詳細情報が表示されます。

HTTPS が提供するセキュリティは、公開鍵と秘密鍵の概念に基づいています。詳細について詳しく説明すると（幸いにも）この記事の範囲をはるかに超えていますが、基本的な前提はかなり単純です。つまり、特定の公開鍵で暗号化されたデータは、対応する秘密鍵でのみ復号できます。ブラウザが HTTPS handshake を開始して安全なチャネルを作成すると、サーバーは証明書を提供します。この証明書は、サーバーが適切な秘密鍵を所有していることを確認して、本人確認に必要なすべての情報をブラウザに提供します。それ以降のすべての通信は、リクエストが認証されたサーバーに配信され、レスポンスが認証済みサーバーから受信されることを証明する方法で暗号化されます。

したがって、HTTPS を使用することで、通信しようとしているサーバーに通信しているということと、他の誰かがネットワーク上でデータをリッスンしたり、通信をいじったりしていないことを保証できます。この種の暗号化は、ウェブ上のセキュリティの絶対的な前提条件です。アプリが現在 HTTPS 経由で配信されていない場合、攻撃に対して脆弱になります。修正してください。Ars Technica には、証明書を無料で取得してインストールするための優れたガイドがあり、技術的な詳細を確認することをおすすめします。構成はプロバイダやサーバーによって異なりますが、証明書リクエストのプロセスはどこでも同じです。

デフォルトで保護

証明書をリクエストしてインストールしたら、HTTP リダイレクトを活用して既存のユーザーを HTTPS 接続に透過的に移行し、Cookie が安全な接続でのみ配信されるようにします。

このように

ユーザーが http://example.com/ にアクセスしたら、適切な Location ヘッダーを含む 301 Moved Permanently レスポンスを送信して、ユーザーを https://example.com/ にリダイレクトします。

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

この種のリダイレクトは、Apache や Nginx などのサーバーで簡単に設定できます。たとえば、http://example.com/ から https://example.com/ にリダイレクトする Nginx 構成は次のようになります。

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Cookie jar をロックする

Cookie により、ステートレス HTTP プロトコルを介してシームレスなログインエクスペリエンスを提供できます。Cookie に保存されたデータ（セッション ID などの機密情報を含む）は、リクエストごとに送信されます。これにより、サーバーはその時点でどのユーザーに応答しているかを把握できます。ユーザーが HTTPS 経由でサイトをアクセスしていることを確認したら、Cookie に保存された機密データは安全な接続を介してのみ転送し、暗号化されていない状態で送信しないようにする必要があります。

Cookie の設定には、通常、次のような HTTP ヘッダーが含まれます。

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

セッションを保護する目的で Cookie の使用を制限するようブラウザに指示するには、1 つのキーワードを使用します。

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

secure キーワードで設定された Cookie が HTTP 経由で送信されることはありません。

開いているウィンドウを閉じる

HTTPS への透過的なリダイレクトとは、ユーザーがサイトを訪問するほとんどの時間、安全な接続を使用することを意味します。ただし、最初の HTTP 接続は広く開いており、SSL ストリッピングや関連する攻撃に対して脆弱です。中間の人物は最初の HTTP リクエストへの完全なアクセス権を持っているため、ユーザーとサーバー間のプロキシとして機能し、サーバーの意図に関係なく、安全でない HTTP 接続を維持できます。

この種の攻撃のリスクを軽減するには、ブラウザに HTTP Strict Transport Security（HSTS）を適用するよう要求します。Strict-Transport-Security HTTP ヘッダーを送信すると、ネットワークにアクセスせずにクライアントサイドで HTTP から HTTPS へのリダイレクトを行うようブラウザに指示します（これにより、パフォーマンスが向上します。最適なリクエストは、実行する必要がないリクエストです）。

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

このヘッダーをサポートしているブラウザ（現在は Firefox、Chrome、Opera: caniuse に詳細があります）の場合、この特定のサイトが HTTPS のみのアクセスをリクエストしていること、つまり、ユーザーのアクセス方法にかかわらず HTTPS でアクセスしていることが示されます。ブラウザに「http://example.com/」と入力しても、HTTP 接続を確立することなく HTTPS が使用されます。さらに、ブラウザが無効な証明書を検出した場合（サーバーの ID を偽装しようとしている可能性がある場合）、ユーザーは HTTP 経由で続行できなくなります。すべてか、まったくかかわりません。これは素晴らしいことです。

ブラウザは、max-age 秒（この例では約 1 か月）後にサーバーの HSTS ステータスを期限切れにします。これを適度に高い値に設定します。

ヘッダーに includeSubDomains ディレクティブを追加することで、送信元のすべてのサブドメインが保護されるようにすることもできます。

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

安全に利用

HTTPS が、送信されたデータが目的の受信者に無事に届くようにリモートで確認するための唯一の方法です。今すぐサイトやアプリに安全な接続を設定しましょう非常に簡単なプロセスであり、顧客データを安全に保つのに役立ちます。暗号化されたチャネルを設定したら、ユーザーがどのようにしてサイトにアクセスしたかにかかわらず、301 HTTP レスポンスを送信して、この安全な接続に透過的にユーザーをリダイレクトする必要があります。Cookie の設定時に secure キーワードを追加して、すべてのユーザーの機密性の高いセッション情報でそのセキュアな接続のみが使用されるようにします。これらすべてを行ったら、ユーザーが誤ってバスから降りることがないようにします。つまり、ブラウザが Strict-Transport-Security ヘッダーを送信して正しい動作をするようにして、ユーザーを保護します。

HTTPS の設定はそれほど難しくなく、サイトとそのユーザーにとって大きなメリットがあります。努力する価値は十分にあります。

リソース

StartSSL では、ドメイン所有権を証明済みの無料の証明書を提供しています。やりたいことは何でしょう。当然ながら、検証のレベルを上げることは可能であり、手頃な料金の場合もあります。
SSL サーバーテスト: サーバーに HTTPS を設定したら、SSL Labs のサーバーテストで設定に問題がないことを確認します。本当に稼働しているかを確認できる詳細なレポートが得られます。
Ars Technica の最近の記事「SSL/TLS によるウェブサーバーの保護」では、サーバーのセットアップに必要な基本事項について詳しく説明しています。
HTTP Strict Transport Security 仕様（RFC6797）では、Strict-Transport-Security ヘッダーのあらゆる技術情報をざっと読む価値があります。
処理の内容を把握したら、次は特定の証明書セットによってのみサイトにアクセスできることをアドバタイズします。IETF では Public-Key-Pins ヘッダーを介してこれを実現するための作業が進行中です。まだ初期段階ですが、興味深いのでフォローする価値があります。

HTTPS と HTTP Strict のトランスポート セキュリティで悪意のある仲介者を混乱させる