WebサイトでHTTPSを強制しない理由はありますか？

私が頻繁に使用するWebサイトは、サーバーに対してTLSを有効にすることを最終的に決定しました。メンテナーは、TLS はオプションでなければならないと主張しています。どうして？

自分のWebサイトでは、長い期間を指定してTLSとHSTSを長い間設定しており、弱い暗号スイートは無効になっています。プレーンテキストアクセスは、TLSで保護されたバージョンへのHTTP 301で保護されます。これは私のウェブサイトに悪影響を及ぼしますか？

TLSを使用する理由はいくつかあります

（そうしないわずかな理由のみ）。

• サイトに認証がある場合、HTTPエクスポーズを使用してセッションとパスワードを盗みます。

• 静的な単なる情報サイトでさえ、TLSを使用することで、誰もデータを改ざんしないようにします。

• Google I / O 2014以来、GoogleはすべてのサイトでHTTPSの使用を奨励するためにいくつかの措置を講じています。

  • Googleは、ウェブマスターがサーバーをより安全に設定できるよう支援していますが、ランキングシグナルとしてHTTPSも使用しました。
  • 最近、Google ChromeはすべてのHTTPサイトを非セキュアとしてマークする長期計画の一環として、HTTPサイトを非セキュアとしてマークし始めました。
  • Google Chrome Developersチームの Mythbusting HTTPS講義は、彼らの態度を明確に述べています。

• Mozillaのセキュリティブログはまた、発表した卑下非セキュアHTTP作ることによってのみ、安全なウェブサイトへのすべての新機能が利用可能と特にそのポーズは、ユーザーのセキュリティとプライバシーに対するリスク特徴、徐々に非セキュアウェブサイトのためのブラウザ機能へのアクセスを段階的に廃止します。

TLSを実施する正当な理由もいくつかあります

すでに広く信頼されている証明書を持っている場合、常にそれを使用しないのはなぜですか？実際には、現在のすべてのブラウザーがTLSをサポートし、ルート証明書がインストールされています。AndroidがルートCAを直接信頼するだけなので、私が長年実際に見た唯一の互換性の問題は、Androidデバイスと中間認証局の欠落です。これは、証明書のチェーンをルートCAに送り返すようにサーバーを構成することで簡単に防ぐことができます。

メンテナーがまだ直接接続せずにHTTP接続を許可したい場合、301 Moved Permanently本当に古いブラウザやモバイルデバイスからのアクセスを確保するために、HTTPSが設定されていることさえブラウザが知る方法はありません。さらに、HTTP Strict Transport Security（HSTS）を301 Moved Permanently次のものなしでデプロイしないでください。

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

両方のプロトコル用に構成されたさまざまなサイトの問題は、TorプロジェクトとElectronic Frontier Foundationによって認識され、マルチブラウザーHTTPS Everywhere拡張機能によって対処されています。

Web上の多くのサイトでは、HTTPSを介した暗号化のサポートが制限されていますが、使用が困難になっています。たとえば、デフォルトで暗号化されていないHTTPを使用したり、暗号化されたページを暗号化されていないサイトに戻るリンクで埋めたりします。

混合コンテンツは、非セキュアHTTP接続経由で読み込まれたJavaScriptまたはCSSを変更することによりHTTPSサイトへのXSS攻撃が発生する可能性があるため、大きな問題でもありました。そのため、今日ではすべての主流のブラウザが、混合コンテンツを含むページについてユーザーに警告し、自動的にロードすることを拒否しています。これにより301、HTTP のリダイレクトなしでサイトを維持するのが難しくなります。すべてのHTTPページがHTTPコンテンツ（CSS、JS、画像など）のみを読み込み、すべてのHTTPSページがHTTPSコンテンツのみを読み込むようにする必要があります。両方で同じコンテンツを使用して達成することは非常に困難です。

現在、TLS + HSTSは、自分のサイトが何をしているのかを信頼できる専門家によって管理されていることを示すマーカーです。これは信頼性の新たな最低基準であり、Googleが証明しているように、そうするサイトに対してポジティブなランキングを提供すると述べています。

一方、最大の互換性があります。特に米国、ヨーロッパ、中国以外の世界の一部では、まだ古いクライアントが存在します。プレーンHTTPは常に機能します（ただし、常にうまく機能するとは限りません;それは別の話です）。

TLS + HSTS：検索エンジンのランキングの最適化
プレーンHTTP：互換性の最適化

あなたにとってより重要なものに依存します。

HTTPSを使用しない単純な読み取り専用 Webサイトには、1つの正当な理由があります。

• Webキャッシュでは、HTTPSを介して転送される画像をキャッシュできません。
• 世界の一部の地域では非常に低速の国際接続が行われているため、キャッシュに依存しています。
• 別のドメインからの画像のホスティングには、小規模な読み取り専用 Webサイトのオペレーターには期待できないスキルが必要です。

メンテナーは、TLSはオプションでなければならないと主張しています。どうして？

この質問に対する答えを本当に知るには、彼らに尋ねなければなりません。ただし、推測することはできます。

企業環境では、ITがファイアウォールをインストールして、マルウェアの送受信トラフィック、疑わしいCnCのようなアクティビティ、仕事に不適切と思われるコンテンツ（ポルノなど）を検査するのが一般的です。これは、トラフィックが暗号化されるとさらに難しくなります。基本的に3つの応答があります。

1. このトラフィックの監視をあきらめます。
2. ユーザーのマシンにルートCAをインストールして、MitMの復号化と検査を実行できるようにします。
3. 卸売ブロック暗号化トラフィック。

関係するシステム管理者にとって、これらのオプションはどれも特に魅力的ではありません。企業ネットワークを攻撃する脅威は非常に多くあり、企業をそれらから保護するのが彼らの仕事です。ただし、非常に多くのサイトを完全にブロックするとユーザーの怒りが生じ、ルートCAをインストールすると、ユーザーのプライバシーとセキュリティに関する考慮事項が導入されるため、少し不器用に感じることがあります。彼がまさにこの状況にあり、単にビジネスに追われたという理由だけでredditのすべてをブロックしたくなかったので、HSTSを最初にオンにしたときに、システム管理者の請願redditを（ごめん、スレッドが見つかりません）見たことを覚えていますポルノに焦点を当てたsubredditsをブロックします。

技術の車輪は先を行き過ぎており、この種の保護は時代遅れであり、段階的に廃止すべきであると主張する多くの人を見つけるでしょう。しかし、それを実践している人はまだ多く、おそらくあなたの不思議なメンテナーが関係しているのは彼らでしょう。

それはすべて、セキュリティ要件、ユーザーの選択、および暗黙的なダウングレードのリスクに帰着します。ブラウザはユーザーエクスペリエンス/利便性の名の下にクライアント側の絶対に恐ろしい暗号に喜んで落ちるので、古い暗号のサーバー側を無効にすることが大いに必要です。ユーザーへの安全なチャネルに依存しているものが、安全でない方法で到達できないことを確認することも、もちろん非常に健全です。

PythonがRubyよりも好きな理由（一般的な例ではありません）についてのブログ投稿は、私が不気味なものや一般の知識を気にしているものではないと判断したときに、安全でないHTTPに明示的にダウングレードすることを許可しませんアクセスしたのは、HTTPSが私にとって取るに足らないものであるという前提で、正当な理由もなく邪魔をしているだけです。

現在、TLSをすぐに使用できない組み込みシステムや、古い実装にこだわっている組み込みシステムがあります（これがそうであるのは非常に悪いと思いますが、[insert embeddedのパワーユーザーとしてデバイス]]、これを変更できない場合があります）。

楽しい実験があります：十分に古いTLS / SSL実装を使用して、HTTPS経由で上流のOpenBSDサイトからLibreSSLの最新バージョンをダウンロードしてみてください。できなくなります。先日、この組み込みシステムをソースからのより安全な新しいものにアップグレードしたかったため、2012年以降の古いOpenSSLビルドを搭載したデバイスで試しました-事前に構築されたパッケージの贅沢はありません。私が試みたときのエラーメッセージは正確には直観的ではありませんでしたが、古いOpenSSLが適切なものをサポートしていなかったためだと思います。

これは、唯一のHTTPSが実際に人々を傷つける可能性がある1つの例です。最近のビルド済みパッケージの豪華さがなく、ソースからビルドして問題を自分で修正したい場合、ロックアウトされます。ありがたいことに、LibreSSLの場合、明示的にHTTPを要求することにフォールバックできます。確かに、これは既にトラフィックを書き換えている攻撃者からあなたを救うことはなく、ソースパッケージを侵害されたバージョンに置き換え、閲覧するウェブページでダウンロード可能なパッケージを説明するHTTPボディのすべてのチェックサムを書き換えることができますが、それでも多くの場合に有用ですより一般的なケース。

私たちのほとんどは、APT（Advanced Persistent Thread：国家intelligence報機関やその他の非常にリソースの豊富なサイバー脅威のセキュリティ用語）の所有から離れた安全なダウンロードではありません。時々wget、最新の暗号スイートをサポートしていないボックスに対して、プレーンテキストのドキュメントまたはソースをすばやく監査できる小さなプログラム（たとえば、GitHubにある自分の小さなユーティリティ/スクリプト）が必要な場合があります。

個人的に、私はこれを尋ねます：あなたのコンテンツは、人が「私が公の知識であることにアクセスしてもいい」と合法的に決定できるようなものですか？あなたのコンテンツをHTTPに誤ってダウングレードする技術者以外の人々にとって、本当のリスクが生じる可能性はありますか？セキュリティ要件、ユーザーのプライバシーの強制要件、および暗黙的なダウングレードのリスクを、ケースごとに情報に基づいて選択するリスクを理解しているユーザーがセキュリティで保護されない状態に陥るリスクに対して重み付けします。あなたのサイトにとって、HTTPSを強制しない正当な理由はないと言うのは完全に正当です-しかし、プレーンHTTPの良いユースケースがまだそこにあると言うのは公平だと思います。

ここでtlsが良い理由について多くの議論があります-しかし、それは元の投稿のように決して尋ねられませんでした。

Maxthonは2つの質問をしました。

1）ランダムで名前のないサイトがhttpとhttpsの両方のプレゼンスを維持することにした理由

2）Maxthonがhttp要求に対する301応答のみを提供することに悪影響があるか

最初の質問に関しては、プロバイダーがhttpサイトとhttpsサイトの両方を保持することを選択した理由はわかりません。多くの理由があるかもしれません。互換性、分散キャッシュ、および地政学的アクセシビリティに関するいくつかのヒントに加えて、コンテンツの統合についても考慮し、安全でないコンテンツに関するaboutいブラウザーメッセージを回避します。アルバロが指摘したように、TLSはセキュリティに関して氷山の一角にすぎません。

ただし、2番目の質問には答えがあります。安全な操作のために実際にhttpsが必要な場合に、Webサイトのサイトの一部をhttp経由で公開すると、攻撃に対して悪用可能なベクトルが提供されます。ただし、トラフィックがサイトのポート80に誤って送信されている場所を特定し、原因を修正するために、これを維持することには意味があります。つまり、マイナスの影響とプラスの影響の両方の機会があるため、最終的な結果は、管理者として仕事をしているかどうかによって異なります。

Sysadmin1138によると、httpsはseoランキングに影響を与えます。Googleはランキングに影響を与えると述べていますが、私が見た唯一の信頼できる研究では、その差は小さいと示唆しています。これは、人に助けていないよく知っているはずですトップはサイトが多いのhttps存在感を持つようにしているランク付けしているので、httpsの存在は、と主張ため、ランキングを向上させます。

過去に、HTTP経由ではなくHTTP経由で<embed>提供されている他の場所のページが必要だったため、HTTPSではなくHTTPを使用する必要がありました。

悪い/壊れた/安全でないクライアントがあることを意味するため、これは正当な理由ではありませんが、既存のhttp://URL を介してリソースにアクセスする自動化プロセスがある場合、それらの一部がhttpsさえサポートしていない可能性があります（たとえば、busybox wget、 「内部的にTLSをサポートしておらず、最近opensslの子プロセスを介してのみ追加した）、フォローできないhttps URLへのリダイレクトが与えられた場合に破損します。

未知の（または既知のレガシー）ユーザーエージェント文字列をリダイレクトから除外し、必要に応じてhttpを介してコンテンツにアクセスできるようにリダイレクトルールを記述することで、この可能性に対処したいと思うでしょう。強制https / hsts。

非常にいくつかあります良いのウェブサイト上ではなく、HTTPS、HTTPを使用する理由は。ウェブサイトがあらゆる種類のトランザクションを処理する場合、またはあらゆる種類の機密データや個人データを保存する場合、これらのデータを安全にするには、絶対にHTTPSを使用する必要があります。HTTPSが強制的に機能しないのは、HTTPSがキャッシングで機能しないため、Webサイトがキャッシングに依存している場合だけです。ただし、多くの場合、Webサイトのセキュリティを確保するために、パフォーマンスを少し犠牲にする価値があります。クライアントがHTTPSをサポートしていない可能性もありますが、実際には2017年にサポートする必要があります。