HTTPSがまだ一般的に使用されないのはなぜですか？

暗号化 私たちは皆彼を愛し、どこでもそれを使いたいと思っています。 しかし、なぜそれがまだ普遍的に適用されないのですか？

証明書に問題がありますか？

HTTPSへの切り替えに対する最初の最も一般的な障壁は、有効な証明書の取得、構成、および維持の価格です。 証明書プロバイダーを見つけ、身元を確認し、支払いを行ってサーバーを構成し、タイムリーに更新する必要があります。



ユビキタス暗号化に切り替えるための提案のほとんどは次のようなものです。「NSAはすべてのトラフィックを記録します。なぜ暗号化しないのですか？」 このような提案の目的は、攻撃者が使用するより複雑で標的を絞った攻撃ではなく、すべてのトラフィックのパッシブトラッキングのコストを増やすことです。



Let's Encryptの担当者は、証明書に関する問題はほぼ完全に自動化されており、最も一般的なプラットフォームのいくつかでのリリース、インストール、構成、および更新の実装がインターネットの大部分をカバーできることをすでに推測しています。 すばらしい仕事であり、やるべきことはまだたくさんありますが、証明書の問題は解決されたと考えることができます。

これで証明書が作成されました。HTTPSを有効にできますか？

まあ多分。 しかし、そうではないかもしれません。 提供するすべてのHTMLリソースに同じホストへのリンク（画像、スクリプトなど）があり、相対URLのみを使用している場合、すべて問題ありません。 そうしないと、ほとんどの場合HTTPSが正しく機能しません。



なに？ HTTPSは良いのですが、なぜそれがすべて壊れたのですか？



ほぼ確実にページにコンテンツが混在しているため、すべてが壊れました。

混合コンテンツとは何ですか？なぜ興奮させる必要がありますか？

OriginAオペレーターである場合、次のケースを考慮してください。 緑色の円は、httpとhttpsで利用可能なリソースですか？ 赤-httpのみ。 点線は、httpを介したコンテンツの読み込みです。 通常の行はhttpsです。 すべてのリンクが絶対であると仮定します。 赤い十字は、ダウンロードが失敗することを意味します。







ここで、証明書を設定し、OriginAでhttpsを有効にしたとしましょう。 チャートはどのようになりますか？







HTMLの絶対リンクを更新しない場合でも、ブラウザーはhttp経由でリソースを取得しようとします。 ほとんどの場合、そのようなダウンロードは禁止されており、そのような場合は警告が表示されます。

ブラウザが混合コンテンツをブロックするのはなぜですか？ サイト所有者としてこれに影響を与えられないのはなぜですか？

ほとんどのWebセキュリティモデルでは、ソースは自身の情報に責任を負います。 HTTPS経由でダウンロードしたコンテンツは、ユーザーを安全でないサイトにリダイレクトし、POSTリクエストまたはpostMessage（）を安全でないソースに送信できます。また、httpsサイトは、http経由でダウンロードしたドキュメントからGET、POSTまたはonMessage（）を受信できます これだけで、なぜPOSTは許可されますが、XHRは禁止されますか？



ブラウザがサイトに適用しようとする正式なセキュリティルールがあります。 このルールは初めて「静けさ」として定式化されました。 簡単な言葉で言えば、これは安全なドキュメントが対話中に安全でなくなることを意味します。



Webセキュリティのすべての複雑さと落とし穴のうち、ブラウザは、信頼性が高く有用なセキュリティインジケータが1つしかないという結論に達しました。アドレスバーとロック、つまりHTTPSを使用することです。 アドレスバーに「https：//」と入力するか、操作するドキュメントのロックアイコンが表示された場合、ブラウザはコンテンツが外部の脅威から保護されていると約束します。



httpsサイトがhttpを介してスクリプトまたは画像をアップロードした場合、この約束は破られます。 このようなアクションの特定の結果は大きく異なる可能性がありますが、ブラウザーにはそれを処理する権利がないため、この動作を単純に抑制します。 これは、コーヒーショップでhttpを介してスクリプトを要求するブラウザでメールクライアントを開くなど、自分で理解できないユーザーを保護するためだけでなく、何かを見逃している可能性があるコンテンツ作成者の指標としても行われました。



これはユーザーにとっては良い解決策ですが、サイトをhttpsに変換する際にWebサイトオペレーターにいくつかの困難を与えます。 安全でないコンテンツにリンクするすべてのHTMLリソースは、警告を発してユーザーを壊したり怖がらせたりします。 この依存関係の問題は、リソースの100％をHTTPSに転送するために克服する必要がある本当の障害だと思います。

混合コンテンツを修正する

混合コンテンツの問題を修正する必要がある場合は、httpsに切り替えるコストがわずかに増加します。 これは、サーバーの構成や証明書の取得よりも少し複雑です;混合コンテンツの削除は高価であり、常に自動化に対応できるとは限りません。



複雑なサイトの場合、すべてのページでs / http / https / gを実行したり、mod_rewriteでルールを記述したりすることはできません。 httpリソースは、静的コンテンツ、動的、データベースに保存されたクライアント、サードパーティのリソースからデータを受信するなど、多くの場所で発生します。



開発中の新しい仕様は 、このプロセスを促進することを目的としています。 HTTPリソースを自動的にhttpsに置き換えるのに役立ちます。



宛先：







後：







この例では、Upgrade-Insecure-ResourcesがOriginAアクセスに役立ちました。 プロトコルが見えないようにスプーフィングされ、リモート依存関係がhttps経由で利用可能になったため、HTMLリソースの1つに混合コンテンツが含まれなくなりました。 この例は、恐ろしいエラーメッセージや機能の欠陥を避けるために、多くのサイトがhttpsを介して独自のコンテンツを提供することを渋る理由を示しています。



これは、依存関係チェーンの最後にある最も責任の低い参加者が進行を妨げることができるという悲しい状況につながります。 周期的な依存関係（Webの広大な構造に確実に存在するため）は、調整なしでは解決できないデッドロックを作成する可能性があります。

これらのサイトはいずれもhttpsを有効にできません

循環依存関係の解決

httpとhttpsの間に十分な中間状態がありません。 この条件に次のプロパティがあれば理想的です。

1.静けさの原則に違反することなく、リソースに依存する安全なソースがそれらを受信できるようにします。

2.他のリソースに、セキュリティまたは混合コンテンツの欠如について急いで結論を下すことを強制しません。

3.それは非常に安価であり、実装のリスクを引き起こしません。 理想的には、httpヘッダーを追加します。

4.静けさの原則に違反する依存関係を決定したり、混合コンテンツのエラーを作成したりできます。







OriginBはhttps-transitionalモードに入ります。 つまり、https：//を介してリソースにアクセスすることはできませんが、有効な証明書を含む完全な保証付きでTLSを介して将来利用できるようになります。 ブラウザとユーザーはこのリソースのセキュリティステータスについて何も知らないため、OriginBのコストはかかりません。



OriginBリソースがhttps-transitionalを介して利用可能になりました。 OriginAにはHTTPSが含まれています。 ブラウザは、OriginBへのTLS接続を開始し、従来のhttpプロトコルを介してリソースを要求できることを知っています。 このプロトコルの変更が失敗すると、リソースは安全でないとマークされ、混合コンテンツに関する警告が表示されます。 すべてが正常に終了すると、ブラウザが主張するすべてのOriginAセキュリティ保証が真になり、ファイルがhttp経由で転送されたという事実にもかかわらず、混合コンテンツに関する警告はありません。



アップグレード後、OriginA OriginCもアップグレードされる場合があります。 OriginBは依然としてOriginDに依存しているため、まだhttpsに切り替えることはできませんが、「トランジット」モードを有効にすると、リソースAとBがhttps経由でリソースにアクセスできます。

この状態をどのように作成できますか？

混合コンテンツを含むドキュメントを作成せずに循環依存関係を解決するには、Content-Typeテキスト/ htmlを返すことができるものを除くすべての要求に対して404を返すフィルターを構成する必要があります。 CORSに関連するいくつかのケースを除く、かなり良いソリューション。 必要な4つのプロパティのうち、このアプローチでは3つ実装しています。



4番目のプロパティは、完全なHTTPSを有効にできる瞬間を知るために、依存関係の状態を判断する機能です。 ブラウザがhttpドキュメントに対して「upgrade-insecure-requests」でContent-Security-Policy-Report-Onlyを使用できる場合はどうなりますか？

1. プロトコルを置き換えようとしています
2. 失敗した場合：httpへのロールバック、管理者へのメッセージ

上記の手順以外の操作は必要ない場合があります。 「upgrade-insecure-requests」を使用したこの構成は、A、B、およびCに実装されています。

iframe

残念ながら、httpsを介したHTMLのリソース送信に切り替えるだけでは不十分であり、iframeを介したHTMLからHTMLへの依存関係では機能しません。 これはよく使用されます。







プロトコルをTLSに置き換えてHTMLリソースをロードする機能を実現する必要がありますが、これは安全なページでのみです。 プロトコルスプーフィングがなければコンテンツはすでに安全ではないため、これはセキュリティに違反しません。そのため、OriginBユーザー向けの混合コンテンツは作成しません。

ALPNおよびHTTP Alt-Svcを使用したhttps-transitional

ALPNでは、クライアントが使用する別のプロトコルを指定することにより、クライアントはTLSを介してサーバーと通信できます。



新しいタイプのALPNプロトコル「https-transitional」を紹介しましょう。 この方法でクライアントがデータを要求するサーバーは、これを「httpでサーバーに接続しますが、httpsではなくTLSで接続します」と認識します。 Alt-Svc HTTPドラフトで説明されているように、TLS接続が発生し、サーバーはドメインに一致する証明書を提示する必要があります。



「https-transitional」を介して開かれたリソースには、次のプロパティがあります。

• リソースを混合コンテンツとしてブロックしないでください。
• 「https-transitional」を介して送信されるドキュメントの設定は、混合コンテンツを禁止すべきではありません。
• 前のプロパティは、ドキュメントの親フレームが禁止するまで実行されます。 この場合、upgrade-insecure-requestsは自動的に発生するはずです

Upgrade-Insecure-Requestsは次のように変更されます。

• 依存リソースのプロトコルスプーフィングの場合、httpsに接続し、http / spdy / h2に加えて、新しい「https-transitional」ALPNプロトコルを優先プロトコルとして追加します。
• サーバーが「https-transitional」を理解している場合は、このプロトコルを使用して応答し、TLSを介してhttpリソースを配信します。
• サーバーが「https-transitional」を理解していない場合は、httpsで返信します。

混合コンテンツのブロックも変更する必要があります。 両方のスキームが同じコンテンツを提供するという保証がないため、ブラウザは現在、httpをhttpsに自動的に置き換えようとはしていません。 「https-transitional」のスキームは、このような保証を提供します。 Servetは、HTTP Alt-Svcヘッダーを使用して、トランジットモードの可用性を報告することもできます。



転送中のドキュメントをダウンロードした後、ブラウザは、混合コンテンツとしてブロックされたすべての接続を、upgrade-insecure-requestsが有効であるかのように置き換えようとしますが、前回の試行が失敗した場合はhttpsで静かにコンテンツをダウンロードする必要があります また、コンソールにエラーを出力する必要があります。







上記の図は、上記のルールの実装を示しています。 OriginBがトランジットモードをサポートしているため、OriginAからダウンロードされたリソースは、OriginBを指すiframeには混合コンテンツが含まれません。 ただし、OriginBリソースが混合コンテンツをブロックするドキュメントからロードされ、プロトコルを置き換えることができないリソース（OriginDのJSファイルなど）に依存している場合、そのような要求は静かにブロックされます。 故障を完了するためには、部分的な損傷が望ましいです。 OriginBから直接ダウンロードされ、OriginDに依存するリソースは、静けさの原則が必要ないためブロックされません。

パフォーマンスへの影響

httpsリソースの場合、この提案では、Upgrade-Insecure-Requestsを使用する場合と比較して、新しい遅延は発生しません。 ブラウザはTLSを優先するため、https移行サポートを決定するために新しいリクエストは必要ありません。



パフォーマンスを失う可能性がある唯一の場所は、Alt-Svcヘッダーによる接続の交換です。 ブラウザは依存するすべてのリソースを再帰的に更新しようとしますが、その一部はhttps経由では利用できない場合があり、大きな遅延が発生する可能性があります。 また、一定の期間、特定のソースでTLSが使用できなかったこと、または並列化されたリクエストを思い出して、これを修正することもできます。 おそらく、最良の戦略を決定するためにいくつかの実験が必要です。



ある時点で、すべてのサイトがhttpから離れたいと思うでしょう。 httpsを介したダウンロードがhttpにロールバックすることはありませんが、上記のシナリオでは、攻撃を使用して暗号化を削除するハッカーから保護するには不十分です。 特に最初の存在がサイト上の各リンクのリクエストスキームを変更する必要を回避することを意味する場合、どうすればトランジットウェブから完全にセキュアなウェブに移行できますか？



HTTPおよびAlt-Svcヘッダーを完全に放棄したいサイトの問題を解決するために作成されたHTTP Strict Transport Securityに基づくパターンの開発を開始できます。



管理者が最初にできることは、Alt-Svcを無限に設定することです。これは、ブラウザがhttp経由で接続しようとせず、常にhttps-transitionalとhttpsのみを使用するように信号を送ります。 その後、サイトはレガシクライアントのhttpサポートを残すか、完全に無効にします。



次のステップは、トランジットコンテンツに静寂性の原則を適用することです。 おそらくこれを行う最良の方法は、HTTPヘッダーを使用することです。 「静かな」ビットを設定すると、混合コンテンツが禁止されます。 また、このリソースがロックアイコンを受信したり、インターフェイスに同様の変更を引き起こしたりする可能性があります。



ある日、トランジットモードの伝播が十分であれば、ブラウザはhttpの放棄を開始できます。 おそらく最初は、設定内のアイテムの外観、そして大きな警告の表示でしょう。 多くのサイトは無制限の期間、送信中のままになる可能性がありますが、ユーザーはTLSサイトを使用することで利益を得ることができます。