HTTPS の有効化に関する経験の共有

国内のネットワーク環境が悪化し続ける中、さまざまな改ざんや乗っ取りが後を絶たず、サイト全体をHTTPS化するWebサイトが増えています。現在、Let's Encrypt は無料の証明書サービスを提供しています。このプロジェクトも正式にオープンしており、HTTPS はまもなく WEB に必須のものとなるでしょう。 HTTPS は、TLS 層と証明書メカニズムを通じて、コンテンツの暗号化、ID 認証、データの整合性という 3 つの主要機能を提供します。これにより、データの閲覧や改ざんを効果的に防止し、仲介者によるなりすましを防ぐことができます。この記事では、HTTPS を有効にした経験をいくつか紹介し、いくつかの新しいセキュリティ仕様で HTTPS を使用する方法に焦点を当てます。 HTTPS の導入と最適化については、これまでにも何度も書いているので、この記事では繰り返しません。

混合コンテンツを理解する

HTTPS Web ページに読み込まれる HTTP リソースは、混合コンテンツと呼ばれます。混合コンテンツの処理ルールは、ブラウザーによって異なります。

初期のインターネットエクスプローラー

初期の IE では、混合コンテンツ要求が検出されると、「安全に転送された Web ページコンテンツのみを表示しますか?」と尋ねるモーダルダイアログボックスが表示されました。ユーザーが「はい」を選択した場合は、混合コンテンツリソースはすべて読み込まれず、「いいえ」を選択した場合は、すべてのリソースが読み込まれました。

新しいIE

新しい IE では、モーダルダイアログボックスがページの下部にあるツールヒントに変更され、以前よりもユーザーの邪魔になりにくくなりました。さらに、画像タイプの混合コンテンツはデフォルトで読み込まれ、JavaScript、CSS などの他のリソースはユーザーの選択に基づいて引き続き読み込まれます。

モバイルブラウザ

これまで述べてきたことはすべてデスクトップブラウザーの動作です。モバイル端末の状況はより複雑です。現在、ほとんどのモバイルブラウザーでは、混合コンテンツの読み込みがデフォルトで許可されています。つまり、モバイルブラウザーの場合、画像であれ、JavaScript と CSS であれ、HTTPS 内の HTTP リソースはデフォルトで読み込まれます。

一般的に、サイト全体に HTTPS を選択する場合は、混合コンテンツを避ける必要があります。すべてのプラットフォームとすべてのブラウザで問題が発生しないようにするには、ページ上のすべてのリソース要求で HTTPS プロトコルを使用する必要があります。

CSPの適切な使用

CSP の正式名称はコンテンツセキュリティポリシーで、ページコンテンツのセキュリティに関連するさまざまな機能を実装するために使用される多くの命令が含まれています。ここでは、HTTPS 関連の手順を 2 つだけ紹介します。詳細については、前回の記事「コンテンツセキュリティポリシーレベル 2 の概要」を参照してください。

すべての混合コンテンツをブロック

前述のように、HTTPSの画像の場合、オプションでブロック可能最近のブラウザがデフォルトで読み込む、HTTP のようなリソース。画像リソースの乗っ取りは通常、それほど多くの問題を引き起こすことはありませんが、いくつかのリスクがあります。たとえば、多くの Web ページのボタンは画像で実装されています。仲介者がこれらの画像を変更すると、ユーザーの使用にも支障をきたします。

CSPを通じてすべての混合コンテンツをブロックページが厳密な混合コンテンツチェックモードに入ることを許可するディレクティブ。このモードでは、HTTPS 以外のリソースはすべて読み込むことができません。他のすべての CSP ルールと同様に、このディレクティブは次の 2 つの方法で有効にできます。

HTTP 応答ヘッダーメソッド:

Content-Security-Policy: block-all-mixed-content

<メタ> ラベル方式:

< meta http-equiv = "Content-Security-Policy" content = "block-all-mixed-content" >

アップグレードの安全でないリクエスト

HTTPS への移行に長い歴史を持つ大規模な Web サイトの場合、特にすべてのリソースを HTTPS に置き換えるステップの作業量は非常に膨大になることが多く、漏れが発生しやすくなります。すべてのコードが正しいことが検証されたとしても、データベースから読み取られた一部のフィールドに HTTP リンクが含まれる可能性が高くなります。

そしてアップグレードの安全でないリクエストこの CSP 命令により、ブラウザがこの変換を支援できるようになります。このポリシーを有効にすると、次の 2 つの変更が行われます。

ページ上のすべての HTTP リソースは、リクエストを行う前に HTTPS アドレスに置き換えられます。
ページ上のすべてのリンクは HTTPS アドレスに置き換えられ、クリック後にリダイレクトされます。

他のすべての CSP ルールと同様に、このディレクティブは 2 つの方法で有効にできます。具体的な形式については、前のセクションを参照してください。注目すべきはアップグレードの安全でないリクエストプロトコル部分のみが置き換えられるため、HTTP/HTTPS ドメイン名とパスがまったく同じシナリオにのみ適用されます。

HSTSの適切な使用

ウェブサイト全体が HTTPS になった後、ユーザーがウェブサイトの HTTP アドレスを手動で入力したり、他の場所からウェブサイトの HTTP リンクをクリックしたりする場合、HTTPS サービスはサーバーの 301/302 リダイレクトに依存してのみ使用できるようになります。最初の HTTP リクエストがハイジャックされ、リクエストがサーバーに到達できなくなり、HTTPS ダウングレードハイジャックが発生する可能性があります。

HSTSの基本的な使い方

この問題は、HSTS (HTTP Strict Transport Security、RFC6797) によって解決できます。 HSTS は次の形式の応答ヘッダーです。

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]

max-age (秒単位) は、指定された時間内にこの Web サイトには HTTPS プロトコルを介してアクセスする必要があることをブラウザに通知するために使用されます。つまり、この Web サイトの HTTP アドレスについては、ブラウザはリクエストを送信する前にローカルで HTTPS に置き換える必要があります。

includeSubDomains はオプションのパラメータです。このパラメータが指定されている場合、この Web サイトのすべてのサブドメインにも HTTPS プロトコル経由でアクセスする必要があることを意味します。

preload はオプションのパラメータであり、その機能については後で紹介します。

HSTS 応答ヘッダーは HTTPS 応答にのみ使用できます。Web サイトはデフォルトのポート 443 を使用する必要があり、IP ではなくドメイン名を使用する必要があります。さらに、HSTS を有効にすると、ユーザーは Web サイトの証明書エラーを無視できなくなります。

HSTS プリロードリスト

HSTS は HTTPS ダウングレード攻撃を効果的に解決できることがわかりますが、HSTS が有効になる前の最初の HTTP リクエストがハイジャックされることは避けられません。この問題を解決するために、ブラウザメーカーは HSTS プリロードリストソリューションを提案しました。組み込みリストが作成され、リスト内のドメイン名については、ユーザーが以前にアクセスしたことがない場合でも HTTPS プロトコルが使用され、リストは定期的に更新されます。

現在、このプリロードリストは Google Chrome によって管理されており、Chrome、Firefox、Safari、IE 11、Microsoft Edge で使用されています。このリストにドメイン名を追加する場合は、まず次の条件を満たす必要があります。

有効な証明書を持っていること (SHA-1 証明書を使用する場合、有効期限は 2016 年以前である必要があります)。
すべての HTTP トラフィックを HTTPS にリダイレクトします。
すべてのサブドメインで HTTPS が有効になっていることを確認します。
出力HSTS応答ヘッダー:
- max-age は 18 週間 (10886400 秒) 未満にすることはできません。
- includeSubdomains パラメータを指定する必要があります。
- プリロードパラメータを指定する必要があります。

上記の条件をすべて満たしている場合でも、HSTS プリロードリストに必ずしも含まれるとは限りません。詳細については、こちらをご覧ください。 Chrome経由 chrome://net-internals/#hsts このツールを使用すると、Web サイトがプリロードリストに含まれているかどうかを確認できるほか、ドメイン名をローカルプリロードリストに手動で追加することもできます。

HSTS と HSTS プリロードリストに関しては、HTTPS サービスが常に提供されることを保証できない限り、これらを有効にしないことをお勧めします。 HSTS が発効すると、Web サイトを HTTP にリダイレクトする場合、古いユーザーは無限にリダイレクトされることになります。唯一の方法は、ドメイン名を変更することです。

CDN セキュリティ

大規模な Web サイトの場合、Web サイト全体を HTTPS に移行した後も CDN を使用する必要がありますが、HTTPS をサポートする CDN を選択する必要があります。サードパーティの CDN を使用する場合は、セキュリティに関する考慮事項がいくつかあります。

SRIの適切な使用

HTTPS は、送信中にデータが改ざんされるのを防ぐことができ、正規の証明書によってサーバーの身元を確認することもできます。ただし、CDN サーバーがハッキングされ、サーバー上の静的ファイルが改ざんされた場合、HTTPS は無力になります。

ウィキペディアこの問題を解決するには、SRI (Subresource Integrity) 仕様を使用できます。 SRI を使用すると、ページがリソースを参照するときにリソースのダイジェスト署名を指定することにより、ブラウザはリソースが改ざんされていないかどうかを確認できます。ページが改ざんされない限り、SRI ポリシーは信頼できます。

SRI の詳細については、以前の記事「サブリソース整合性の概要」を参照してください。 SRI は HTTPS に固有のものではありませんが、メインページが乗っ取られた場合、攻撃者はリソースの概要を簡単に削除できるため、ブラウザーの SRI 検証メカニズムが失われます。

キーレス SSL について

もう 1 つの問題は、サードパーティ CDN の HTTPS サービスを使用する場合、独自のドメイン名を使用する場合は、対応する証明書の秘密鍵をサードパーティに渡す必要があることです。これも非常にリスクの高いことです。

CloudFlare はこのシナリオのために Keyless SSL テクノロジーを開発しました。証明書の秘密鍵を第三者に渡す代わりに、リアルタイムコンピューティングキーサーバーを提供できます。 CDN が秘密鍵を使用する必要がある場合、必要なパラメータを暗号化されたチャネルを介してキーサーバーに送信し、キーサーバーが結果を計算して返します。プロセス全体を通じて、秘密鍵は独自のキーサーバーに保管され、第三者に公開されることはありません。

CloudFlare のメカニズムはオープンソース化されています。詳細については、公式ブログのこちらの記事をご覧ください: Keyless SSL: The Nitty Gritty Technical Details。

さて、この記事はここで終わりです。この記事で言及したCSP、HSTS、SRI戦略は最新のブラウザでのみサポートされていることに注意してください。詳細なサポートについては、使えますかチェック。 HTTPS に切り替えた後は、パフォーマンスの最適化のために行うべき新しい作業がたくさんあります。この部分については以前のブログでたくさん書いたので、ここでは繰り返しません。最も重要な点だけを述べます。HTTPS なので、正しい方法はすぐに HTTP/2 に切り替えることです。

原文: https://imququ.com/post/sth-about-switch-to-https.html

<<: HTML でナンバープレート番号と州の略語を入力するためのサンプルコード

>>: DockerにRabbitMQをインストールする詳細な手順