URLを入力すると、ブラウザのデフォルトがhttps：ではなくhttp：になるのはなぜですか？
ブラウザバーにスキームなしでexample.comと入力してEnterキーを押すと、HTTP://example.comではなくHTTPS://example.comとして解釈されます。どうして？そして、これを修正する計画はどこにありますか？
（明確にするために、私は話しているのみ「遅延」ユーザーからの入力/貼り付けされたアドレスについてではなく、次のスキーマ相対URL、window.location = "url"などのソフトウェア定義のアクションについてではない。そして明らかにHTTP://example.comの入力/貼り付けは引き続き機能する必要があります。）
[〜＃〜] edit [〜＃〜]：一部の回答では、サイトはすでに可能であると指摘していますmostlyリダイレクトでこれを実現します+ HSTS。中心的な技術的利益は、最初の接続の問題を絞り込むことです（これもHSTSプリロードによって対処されますが、すべてのサイトに拡張することはできません）。それが物事を壊すための弱い正当化であることを私は見ることができますnow;私がもっと興味を持っているのは、それが5年間で明らかな終盤なのかどうかです。 10？ 20？
デフォルトのhttps解釈に至るまでにいくつかの問題が見られます。
Httpでのみ機能するサイトのユーザーエクスペリエンス。 httpsにデフォルト設定するとエラーが表示されますが、通常、ユーザーはそれがshould機能するかどうか、つまり、このサイトが単にhttpsで機能しないか、これがダウングレード攻撃であるかを知りません。
この状況のエラーページに簡単な「http：...ですか？」リンク（*）を使用すると、機能しないサイトでユーザーがクリックすることに慣れ、あまり得られません（？）。そして、それが簡単でない場合（たとえば、ユーザーが
https->httpを編集する必要がある場合、ユーザーはそのようなブラウザを使用しません。[〜＃〜] edit [〜＃〜]：エラー表示は、失敗したHTTPSアドレスに明示的にアクセスするのとは異なる必要があることを明確にすべきでした—このシナリオは、「安全な解釈が機能しなかった」ほどの「失敗」ではありません。初心者にとっては、警告バーを上にして自動的にHTTPに「ソフトフェイル」することでさえ問題ありません。
しかし、私はまだ3つのことを獲得していると思います。安全でないサイトに行くことは意識的な行動であり、安全でないHTTPは 通常ではない であることをユーザーに教育し、httpsを実装するようにサイトに圧力をかけます。
場合によっては
http://を入力しなければならないという不便さ。 IMOは、より多くの場合にhttps://を入力する必要がないという便利さを完全に上回っています。過去のデフォルトとの「互換性」。いくつかの規格に記載されているかどうかはわかりませんが、IMOでは変更する必要があることは明らかですsome dayなので、これはショートッパーではありません。
政治/経済学：CAシステムには問題があり、ブラウザーはサイト管理者に支払うように圧力をかけることに消極的かもしれません（そうでなければ彼らに価値を見ない場合）。ちょっとお金を無視して、ふりをしてみましょう Let's Encrypt free CA が到着しました。
今すぐ変更を加えることが物議を醸す可能性がある理由がわかります。何が私を困惑させるのかは、明らかに長期的な目標として広く議論されていない理由です。私が見るものは、httpが事実上永遠にデフォルトのままであると想定しているようです：
Chromeが
http://をURLバーに非表示にするようになったのは一歩後戻りです。 httpsのデフォルトに向けた最初のステップは、httpを赤で示しているはずです。しばらくして、最終的にはhttps://（緑の南京錠のみを表示）を非表示に移動します...HSTSは正しい方向に進んでいますが、サイトごとの慎重なオプトインがあります。どちらも弱くて強力です—サイトは明示的なhttp URLの場合でもhttpsを強制することをオプトインしており、ユーザーはエラーに頼ることはできません—しかし、RFCはhttpsがglobalデフォルトである可能性があるという考えについてさえ言及していません。または、そのブラウザのデフォルトスキームは bootsrap MITM 問題のせいです。
HSSECのようなオプトインの将来のベクトルとしてDNSSECが言及されているのを見たことがありますが、オプトアウトの提案を見たことはありません...
また、これをオプションとして提供しているブラウザー（または拡張機能）はありますか？
まあ、私はいくつかの理由が存在すると推定できます：
- HTTPSサポートは、Webサイトで自動的に構成されません。したがって、ブラウザはなぜそうであると想定する必要がありますか？
- 特定のスキームを使用することがかなりの数のユーザーの頭を超えることにならない限り、ウェブサイトにアクセスできないと言います。
- HTTPSへの切り替えは、場合によっては簡単とは言えません。 たとえば、スタック交換を行います
安全でないウェブサイトを赤で表示することに関しては すでに進行中 。
Google Chromeには、安全でないWebサイトでエラーを発生させるための次のタイムラインがあります。
- Chrome 46
Chromeは、HTTPページと同じ中立的なページアイコンを使用して、「HTTPS with Minor Errors」状態をマークします。
- Chrome 56
パスワードまたはクレジットカードを収集するHTTPページを非セキュアとしてマークする
- Chrome 62
Chromeは、ユーザーがHTTPページにデータを入力したときと、シークレットモードでアクセスしたすべてのHTTPページに2つの状況で「安全ではありません」という警告を表示します。
- Chrome 68
アドレスバーには、すべてのHTTPページで「保護されていません」と表示されます。
- Chrome 79
Chromeは、デフォルトですべての混合コンテンツのブロックに徐々に移行します。破損を最小限に抑えるために、混合リソースをhttps：//に自動アップグレードします。そのため、サブリソースがhttps：//ですでに利用可能であれば、サイトは引き続き機能します。
- Chrome 81
Chromeは、すべての混合コンテンツのダウンロードに関する警告メッセージをコンソールに出力します。
- Chrome 82
Chromeは、実行可能ファイル（.exeなど）の混合コンテンツダウンロードについて警告します。
Chromeは混合コンテンツの実行可能ファイルをブロックします
Chromeは、混合コンテンツアーカイブ（.Zip）とディスクイメージ（.iso）について警告します。
Chromeは混合コンテンツの実行可能ファイル、アーカイブ、ディスクイメージをブロックします
Chromeは、画像、音声、動画、テキスト形式を除く、その他すべての混合コンテンツのダウンロードについて警告します。
Chromeは、画像、音声、動画、テキストの混合コンテンツダウンロードについて警告します
Chromeは他のすべての混合コンテンツのダウンロードをブロックします
- Chrome 86
Chromeはすべての混合コンテンツのダウンロードをブロックします。
ブラウザはエンドユーザー向けのアプリケーションです。ほとんどのサイトはhttpで利用できますが（httpsにリダイレクトする場合でも）、httpsではほとんどのサイトを利用できません。したがって、あなたの提案は、ユーザーの非常に大部分のWebサーフィンを壊します。それは彼らが理解していない方法で壊れるでしょう。 httpsが失敗した場合に自動的にhttpにダウングレードしても意味がありません。攻撃者は単にポート443への接続で大混乱を引き起こし、ダウングレードを強制できるからです。
ほんの少しの重要でないサイトを除いてすべてがhttpsに切り替えられると、より安全なデフォルトに切り替えることができますが、まだではありません。エンドユーザーは何が起こったのか理解せず、おそらく代わりのブラウザーに切り替えるか、インターネット上のどこかから古い動作を取り戻すためのヒントを得ます。
セキュリティの決定は、ユーザーに対してではなく、ユーザーに対して行う必要があります。
ここには、あなたの提案を妨げる大きな問題があります。現在多くのWebサーバーが構成されている方法で、デフォルトのhttpsにすると、実際には間違ったWebサイトになってしまう可能性があります。デフォルトがhttpの場合、これは当てはまりません。
たとえば、3つのサイトがすべて同じIPアドレス上にあるとします。
http://site.a.com
http://site.b.com
https://site.c.com
多くのサーバーで、httpではなくhttps://site.a.comにアクセスしようとすると、実際にはサイトCが表示されますが、証明書エラーが発生します。
多くのユーザーを混乱させ、事態をさらに悪化させる危険が本当にあると思います。どこでもHTTPSを試すことは必ずしも悪い考えではありませんが、HTTPSが利用できない場合は、ユーザーに何らかのフォールバック計画を立てる必要があります。
多くのユーザーは警告サインに興味がなく、自分のコンテンツを求めています。多くの場合、盗聴またはMITM攻撃から取得するトラフィックを保護することは厳密に必要ではありません。少なくとも、リスクと結果が銀行の不正な証明書よりもはるかに低いです。
基本的に、ユーザーがお気に入りのHTTP専用サイト（新聞やブログなど）にアクセスしようとしたときに警告サインが表示された場合、ignore警告を伝える必要があります。この場合でも問題ありません。ユーザーが警告を無視しても問題ないことを本当に理解しているが、他のユーザーを無視することは正しくない場合を除いて、警告を無視するようユーザーに指示することは、一般にひどい考えです。
警告は適切ですが、ユーザーがすべての警告を無視する可能性が高いため（特にユーザーが完全に理解していない場合）、比較的リスクの低い問題に対する多数の警告は効果がありません。
技術者以外のユーザーの多くは、Firefox警告が悪い証明書に与える影響を理解しようとはしていません。次に例を示します。
この接続は信頼されていません
Firefoxにsome.site.exampleに安全に接続するように依頼しましたが、接続が安全であることを確認できません。
通常、安全に接続しようとすると、サイトは信頼できるIDを提示して、正しい場所に移動していることを証明します。ただし、このサイトのIDは確認できません。私は何をすべきか？
通常、問題なくこのサイトに接続している場合、このエラーは誰かがサイトになりすまそうとしている可能性があるため、続行しないでください。
これは3つの段落であり、多くのユーザーは、頻繁に発生する場合でも、少なくとも毎回読む必要はありません。
プレーンHTTPサイトとの主な違いは、プレーンHTTPサイトは安全な接続を提供するとは主張していないことです。同様の方法で、別の3段落のメッセージでそれを説明できると仮定します。技術に精通したユーザーが気を散らし、先に進む前にこれらの説明を完全に読まないことは、非常に一般的です。
多くのサイトはhttp://からhttps://へのリダイレクトを使用し、301（永続的）ステータスコードまたはHSTSを使用する場合があります。プリロードされたHSTSは優れていますが、まれです。最初の接続でのHSTSは、妥協案としてかなり適切です。
結局のところ、適切なときに接続が安全であると期待するかどうかは、常にユーザー次第です。ブラウザーができることはそれだけですが、ユーザーが期待するサイトで、HTTPSが使用されていることを確認するのは、それが理にかなっている場合にユーザーが行うことです。これは実際の生活と特に違いはありません。これまでに話し合ったすべての人のパスポートを確認する必要はありませんが、重要な場合はそうします。
技術の領域では伝えられないブートストラップの問題があります。ユーザーがhttp://www.gmail.com/にアクセスした場合、https://www.gmail.com/またはhttps://mail.google.com/またはhttps://accounts.google.com/にリダイレクトする必要があります。 GmailでHTTPSを期待する必要があること、およびGmailはGoogleが実行していることを伝えるのは、帯域外の知識です。 （HTTPSさえ存在することを彼らに伝える同じ帯域外の知識...）
それらがリダイレクトされない場合、Google（Gmailまたはログイン）によって実行されるHTTPSサイトに、これは彼らと一緒に警報ベルを鳴らすべきです。自動化されたメカニズムは限られた数の有名なサイトで機能する可能性がありますが、一般的に機能するシステムを想像することは困難です。それでも失敗する場合は、ユーザーに次の責任を負わせる必要があります。（a）HTTPSを予期するタイミングを把握し、（b）HTTPSが使用されていることを確認し、（c）ユーザーが本当に希望するサイトにいることを確認します。 （残念ながら、一部のブラウザー、特にモバイルデバイスでは、その情報が少し見えにくくなっています。）
私の意見では、ユーザーに3つのポイントを教える方が、とにかく無視することを選択できる警告の詳細を読むように教えるよりも簡単です。
もちろん、将来、すべてのサイトがHTTPSを使用する世界を想像できます。これが必要だと私はまだ完全には確信していません。悪質なサイトも証明書を取得する可能性があるため、ユーザーは、訪問するつもりのサイトにいることを確認する責任を負う必要があります。
プレーンHTTPが「通常ではない」ことを教えようとすることは、問題を次のレベルに押し上げるだけです。すべてHTTPSのWebは、サービスプロバイダーにとって負担となる可能性がありますが、必ずしも期待するメリットを提供できるとは限りません。
EFFには、Firefox（Androidを含む）、ChromeおよびOpera）用のプラグインがあります。これはHTTPS Everywhereと呼ばれ、ルールを使用して最終的に正しいサイトに到達するようにします。たとえば、書き換えますexample.comを https://secure.example.com/ に変更します。httpsバージョンがsecure.example.comにのみ存在することがわかっている場合、リンク内のURLも置き換えられます。
現在、ブラウザは何十年にもわたって行われているHTTPをデフォルトで使用しています。 Webサイトが安全であることを確認することは、ブラウザの責任ではありません。適切なリダイレクトを行い、HTTPSをサポートするためにWebサイトに依存しています。 google.comと入力すると、HTTPSバージョンに正常にリダイレクトされます。 WebサイトがHTTPSをサポートしている場合は、適切なリダイレクトを行う必要があります。ブラウザは堅牢でなければなりません。
サイトが両方をサポートしている場合、バックドアは開いたままですが、フロントドアはロックされていると言えます。
以前はコンピューターが弱く、暗号化はcpuであり、インターネットの帯域幅は空腹であり、インターネットの初期段階では不要であると見なされていたためです。この追加レイヤーは、動作するために独自の儀式用タンゴを実行する必要があります。つまり、追加のCPU、追加のラウンドトリップ、追加の帯域幅などです。ただし、最近のバージョンchrome今日はhttpsを試しますが、サーバー側では、リダイレクトを設定して、ブラウザがサイトのhttpsフレーバーをポイントする上記のドメインで提供される唯一のWebコンテンツを設定する必要があります。
セキュリティが必要なWebサイトは、http：//からhttps：//に自動的にリダイレクトする必要があります。これにより、ブラウザーがhttps：//を自動的に表示する必要がなくなり、証明書のないサイトでhttpsからhttpにリダイレクトする必要がある場合よりも簡単なソリューションになります。
これは、とにかく実際に行うべきではないことです。つまり、ブラウザはセキュリティ警告を出さなければならず、不必要なCookie警告などのようにユーザーを不必要に煩わせます。