ウェブサイトにHTTPSを適用しない理由はありますか？
私が頻繁に使用するWebサイトは、サーバーに対してTLSを有効にすることを最終的に決定しました。メンテナは、TLS mustはオプションであると主張しています。どうして？
自分のWebサイトで、長い期間の必須のTLSおよびHSTSを長い間設定しており、弱い暗号スイートは無効になっています。プレーンテキストアクセスは、TLSで保護されたバージョンへのHTTP 301でウォールアウトされることが保証されています。これは私のウェブサイトに悪影響を及ぼしますか？
TLSを使用する理由はいくつかあります
（そして、そうしないためのほんのわずかな理由だけ）。
- サイトに認証がある場合は、HTTPエクスポーズを使用してセッションとパスワードを盗みます。
静的で単なる情報サイトであっても、TLSを使用すると、誰もデータを改ざんしていないことが保証されます。
Google I/O 2014 以降、GoogleはすべてのサイトにHTTPSの使用を奨励するためにいくつかの措置を講じています。
- Googleはサーバーをより安全に構成するために helping webmasters を使用していますが、 ランキング信号としてのHTTPS も使用しています。
- 最近では、Google Chromeが開始されました HTTPサイトを非セキュアとしてマーク 、すべてのHTTPをマークする長期計画の一部として非セキュアとしてのサイト。
- Google Chrome開発者チームの Mythbusting HTTPS 講義は彼らの態度を明確に述べています。
Mozilla Security Blogも 非セキュアHTTPの非推奨 を発表しましたすべての新機能をセキュアなWebサイトのみに利用可能にしますおよび安全でないWebサイトのブラウザー機能、特にユーザーのセキュリティとプライバシーにリスクをもたらす機能へのアクセスを段階的に段階的に廃止する。
TLSを適用する理由はいくつかあります
すでに広く信頼されている証明書がある場合は、常にそれを使用しないのはなぜですか？事実上すべての現在のブラウザはTLSをサポートし、ルート証明書がインストールされています。私が実際に数年間見てきた唯一の互換性の問題は、Androidデバイスと 中間認証局がない としてAndroidはルートのみを信頼する直接CAこれは、証明書のチェーンをルートCAに送り返すようにサーバーを構成することで簡単に防ぐことができます。
メンテナが直接301 Moved PermanentlyなしでHTTP接続を許可したい場合、たとえば、いくつかの本当に古いブラウザまたはモバイルデバイスからのアクセスを保証するためにブラウザがそれを知る方法はありませんHTTPSも設定されています。さらに、301 Moved Permanentlyなしで HTTP Strict Transport Security（HSTS） をデプロイしないでください。
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").
両方のプロトコル用に構成されたさまざまなサイトの問題は、The Tor ProjectおよびElectronic Frontier Foundationによって認識され、マルチブラウザによって対処されます- HTTPS Everywhere 拡張：
Web上の多くのサイトでは、HTTPSを介した暗号化のサポートが制限されていますが、使用が困難です。たとえば、暗号化されていないHTTPにデフォルト設定したり、暗号化されていないサイトに戻るリンクで暗号化されたページを埋めたりすることができます。
混合コンテンツも、安全でないHTTP接続を介して読み込まれたJavaScriptまたはCSSを変更することにより、HTTPSサイトへのXSS攻撃の可能性があるため、大きな問題でした。したがって、現在、すべてのメインストリームブラウザは、コンテンツが混在しているページについてユーザーに警告し、自動的にロードすることを拒否しています。これは、HTTPでの301リダイレクトなしでサイトを維持することを困難にします。すべてのHTTPページがHTTP接続（CSS 、JS、画像など）、すべてのHTTPSページはHTTPSコンテンツのみをロードします。両方のコンテンツを同じにすることは、非常に困難です。
この時代では、TLS + HSTSは、自分のサイトが何をしているのかを知る信頼できる専門家によって管理されているマーカーです。それが信頼できるサイトのポジティブランキングを提供するとグーグルが述べているように、それは信頼性に関する新たな最低基準です。
もう一方の端は最大の互換性です。特に米国、ヨーロッパ、中国以外の一部の地域では、まだ古いクライアントが存在します。プレーンHTTPは常に機能します（ただし、常に機能するわけではありませんwell;これは別の話です）。
TLS + HSTS：検索エンジンのランキングを最適化
プレーンHTTP：互換性のために最適化
あなたにとってより重要なことに依存します。
単純な読み取り専用 WebサイトがHTTPSを使用しないのには1つの理由があります。
- Webキャッシュは、HTTPS経由で転送される画像をキャッシュできません。
- 世界の一部の地域では、非常に低速の国際接続があるため、キャッシュに依存しています。
- 別のドメインの画像をホストするには、小さな読み取り専用 Webサイトのオペレーターには期待できないスキルが必要です。
メンテナは、TLSはオプションである必要があると主張しています。どうして？
この質問に対する答えを本当に知るには、質問する必要があります。ただし、推測は可能です。
企業環境では、ITがファイアウォールをインストールして、送受信するマルウェア、マルウェア、疑わしいCnCのようなアクティビティ、仕事に不適切と見なされるコンテンツ（ポルノなど）を検査するのが一般的です。これは、トラフィックが暗号化されると、はるかに困難になります。基本的に3つの可能な応答があります。
- このトラフィックの監視をあきらめてください。
- ユーザーのマシンにルートCAをインストールして、MitMの復号化と検査を実行できるようにします。
- 卸売ブロック暗号化トラフィック。
懸念のあるシステム管理者にとって、これらのオプションはどれも特に魅力的ではありません。企業ネットワークを攻撃する脅威は非常に多くあり、企業をそれらから保護するのが彼らの仕事です。ただし、非常に多くのサイトをブロックすると、ユーザーの怒りが完全に発生します。ルートCAをインストールすると、ユーザーのプライバシーとセキュリティに関する考慮事項が導入されるため、少し不自然に感じることがあります。最初にHSTSをオンにしたときに、システム管理者の請願redditが表示された（すみません、スレッドが見つからない）のを覚えていました。ポルノに焦点を当てたサブレディットをブロックする。
テクノロジーの車輪は絶えず変化し続けており、この種の保護は時代遅れであり、段階的に廃止する必要があると主張する多くの人がいます。しかし、それを実践する人はまだ多く、おそらくあなたの神秘的なメンテナーが関係しているのは彼らでしょう。
すべては、セキュリティ要件、ユーザーの選択、および暗黙的なダウングレードのリスクによるものです。ブラウザがユーザーエクスペリエンス/利便性の名の下にクライアント側で絶対に恐ろしい暗号に移行するため、サーバー側で古い暗号を無効にすることが主に必要です。安全な方法でユーザーへの安全なチャネルでdependsに到達できないことを確認することも、もちろん非常に健全です。
Python more than Ruby（あなたがそう言っているわけではない）理由についてのあなたのブログ投稿と私が思うとき、私が安全でないHTTPに明示的にダウングレードすることを許可しない、単なる一般的な例です）HTTPSが私にとって取るに足らないものであるという前提で、私がアクセスしたことが正当な理由もなく邪魔になっていることを知っている一般の人やスパイが気にしないものではありません。
今日、組み込みのシステムにTLSをそのまま使用できない機能、または古い実装でスタックされているシステムがあります（これがそうであるのは非常に悪いと思いますが、[insert embeddedここにデバイス]、私は時々これを変更することができません）。
これは楽しい実験です。十分に古いTLS/SSL実装を使用して、HTTPS経由で上流のOpenBSDサイトからLibreSSLの最新バージョンをダウンロードしてみてください。あなたはできなくなります。この組み込みシステムをソースからのより安全な新しいものにアップグレードしたかったので、2012年かそれより古いOpenSSLビルドのデバイスで先日試しました-ビルド済みのパッケージの贅沢はありません。私が試したときのエラーメッセージは正確には直観的ではありませんでしたが、古いOpenSSLが適切なものをサポートしていなかったためだと思います。
これは、HTTPSのみが実際に人を不快にさせる可能性がある移動の1つの例です。最近のビルド済みパッケージの贅沢がなく、ソースからビルドして自分で問題を解決したい場合、ロックアウトされます。ありがたいことに、LibreSSLの場合は、明示的にHTTPを要求するようにフォールバックできます。確かに、これは攻撃者がトラフィックをすでに書き換えていることからあなたを救うことはありません。ソースパッケージを侵害されたバージョンで置き換え、閲覧するWebページでダウンロードできるパッケージを説明するHTTP本文のすべてのチェックサムを書き換えることができますが、それでも多くの場合に役立ちます。より一般的なケース。
私たちのほとんどは、APT（Advanced Persistent Thread：National Investigation Agencyやその他の非常にリソースの豊富なサイバー脅威のためのセキュリティ専門用語）が所有することから、1つの安全でないダウンロードではありません。 wgetに、最新の暗号スイートをサポートしていないボックス上で、そのソース（たとえば、GitHubにある自分の小さなユーティリティ/スクリプト）をすばやく監査できるプレーンテキストのドキュメントまたは小さなプログラム。
個人的に、私はこれを質問します。あなたのコンテンツは、人が「私が公開知識であることへのアクセスに大丈夫です」と合法的に決定できるようなものですか？コンテンツを誤ってHTTPにダウングレードする、技術者以外の人々に実際のリスクが生じる可能性はありますか？セキュリティ要件、ユーザーに対するプライバシーの強制要件、およびケースバイケースで情報に基づいた選択を行うリスクを理解しているユーザーが安全でない状態に陥る可能性に対する暗黙のダウングレードのリスクに重みを付けます。あなたのサイトにとって、HTTPSを強制しないことには正当な理由はないと言うのは完全に正当ですが、私はプレーンなHTTPの良いユースケースがまだそこにあると言っても差し支えないと思います。
Tlsが優れている理由については、ここで多くの議論があります。
Maxthonは2つの質問をしました：
1）httpとhttpsの両方の存在を維持することにした無名のランダムなサイトがある理由
2）Maxthonへの悪影響はありますか？
最初の質問に関しては、プロバイダーがhttpサイトとhttpsサイトの両方を保持することを選択した理由がわかりません。理由はたくさんあります。互換性、分散キャッシュ、および地政学的アクセシビリティに関するいくつかのヒントに関するポイントに加えて、コンテンツの統合と、安全でないコンテンツに関する醜いブラウザメッセージを回避することについての考慮事項もあります。 Alvaroが指摘したように、TLSはセキュリティに関して氷山の一角にすぎません。
しかし、2番目の質問は答えられます。安全な運用のために実際にhttpsが必要なときに、http経由でWebサイトのサイトの一部を公開すると、攻撃のための悪用可能なベクターが提供されます。ただし、トラフィックがサイトのポート80に誤って送信されている場所を特定し、原因を修正するために、これを維持することには意味があります。つまりマイナスの影響とプラスの影響の両方の機会があるため、最終的な結果は、管理者としての仕事をしているかどうかによって異なります。
Sysadmin1138は、httpsがseoのランキングに影響を与えると述べています。 Googleはランキングに影響を与えると述べていますが、唯一の 信頼できる調査 違いは小さいことを示しています。これは人々の助けにはならない 誰が知っているべきか 上位のサイトにはhttpsが存在する可能性が高いため、httpsが存在するそのためが向上するランキング。
WebサイトでHTTPSの代わりにHTTPを使用する良い理由はほとんどありません。 Webサイトがあらゆる種類のトランザクションを処理する場合、またはあらゆる種類の機密データや個人データを保存する場合、そのデータを保護するには、HTTPSを絶対に使用する必要があります。 HTTPSを適用しない理由として適切な唯一の理由は、HTTPSがキャッシュで機能しないため、Webサイトがキャッシュに依存している場合です。ただし、Webサイトのセキュリティを確保するために、パフォーマンスを少し犠牲にすることはしばしば価値があります。クライアントがHTTPSをサポートしていない可能性もありますが、2017年にはサポートする予定です。
これはgoodの理由ではありません。不良/破損/安全でないクライアントがあることを意味しますが、既存のhttp:// URLを介してリソースにアクセスする自動化プロセスがある場合、それらの一部がhttpsもサポートしていません（例：busybox wget、これは内部でTLSサポートがなく、openssl子プロセスを介して最近追加されただけです）、httpsのURLへのリダイレクトが与えられた場合に中断します彼らが従えないこと。
リダイレクトルールを記述して不明な（または既知のレガシー）ユーザーエージェント文字列がリダイレクトされないようにし、必要に応じてhttp経由でコンテンツにアクセスできるようにして、この可能性に対処したくなります。強制https/hsts。
以前は、HTTPSではなくHTTPを使用する必要がありました。これは、HTTP経由で提供されている他の場所からの<embed>ページが必要で、それ以外の場合は機能しないためです。