証明書なしでhttpsを使用できますか？
基本的に何かを誤解している場合は、事前に謝罪しますが、証明書システムに頼らずに暗号化された通信プロトコル（https）を使用することは可能ですか？
この質問は、「どこでも暗号化する」というEFF/Mozillaイニシアチブに関するものです。証明書が/ identity /を検証することを理解しましたが、検証済みのIDを使用してhttpsプロトコルwitboutを構築することは可能または合理的ですか？最もわかりにくい例は自己署名証明書サイトとの通信ですが、通信相手の身元よりも通信の暗号化を重視する状況は他にありますか？
証明書なしでSSL/TLSを使用できます。これは TLS標準 でサポートされています。「DH_anon」暗号スイートには証明書は一切含まれていません。ただし、このような認証されていないTLSは、クライアントまたはサーバーの偽装を同時に防止することができないため、本質的にアクティブな攻撃者に対して弱いことを覚えておく必要があります（同時に両方とも呼ばれます 中間者攻撃） ）。
ほとんどのWebブラウザーは、MitMに固有の脆弱性があるため、DH_anon暗号スイートを非アクティブ化します。自己署名SSL証明書を使用すると、CAと通信せずに自分で作成できるのと同じ概念上の効果を得ることができます。もちろん、ほとんど同じ理由で、同じWebブラウザが「怖い警告」を表示します。
EFFの観点から見ると、その大敵はNSAであり、一般的なDH_anon暗号スイートは理にかなっています。これは、Evil Spy Agencies™が受動的な盗聴を好むことが知られているためです（有害な痕跡がないため）。パッシブ盗聴はDH_anonによって打ち負かされます。ただし、他のほとんどの人にとって、最大の脅威は政府の侵入ではありませんが、お金からあなたを引き離そうとする平凡な共演者であり、これらは完全なMitM攻撃を実行することを躊躇しません。偽のWiFiアクセスポイント。
Let's Encrypt イニシアチブは、証明書の発行を無料で（「お金なし」のように）自動化する一方で、証明書を取得した人がある程度制御できることを「確認」するための努力を維持します指定ドメイン。外観から見ると（これは綿密な検査に値します）、このシステムはDNSに依存しており、DNS攻撃（例 DNSスプーフィング ）が完全に自動化された方法で不正な証明書の発行に悪用される可能性があることを示唆しています。したがって、このイニシアチブは、現在の証明書モデルの弱体化になります。一方、より多くの人々にSSLを使用するよう説得する場合、それは少なくともNSAが悪魔であるという観点から「より安全な世界」に貢献します。そこでは、重要なのは受動的な盗聴者を倒すことです。
とにかく、MicrosoftとGoogleからのサポート（つまり、Let's EncryptルートCAをIEおよびChromeに）することなしに、イニシアチブが本当に一般的なHTTPSに変わる方法はありません。多くの人ではありません。ユーザーの70％がブラウザに侮辱されて怖がってしまうことを意味する場合は、WebサイトでSSLをアクティブにします。MicrosoftとGoogleがワゴンに飛び乗らない場合（そして私はそうは思わないでしょう）、Let's暗号化システムは引き続き政治的なジェスチャーのままですが、普及することはありません（そして、誰かが自動化されたDNSベースの攻撃を仕掛けようとすると、結局Mozillaはそれを落とします）。
SSLには、完全に異なる別の証明書なしモードがあります。それは [〜＃〜] srp [〜＃〜] と呼ばれます。 つまり安全ですが、通常のWebブラウジングとは異なります。 SRPは、共有シークレットに関してクライアント/サーバーの相互認証を保証し、オフラインのブルートフォースから共有シークレットを保護する方法でこれを実行します。これにより、低エントロピー共有シークレット、つまりpassword。 TLS-SRPは、パスワードで保護されたネットワークリソースにアクセスするのに非常に意味があり、証明書はまったく必要ありません。しかも、MitMや盗聴に対して安全です。
残念ながら、Webブラウザは現在SRPをサポートしていません。
SSL/TLS（HTTPSの基礎となるプロトコル）には、次の2つの機能があります。
- 暗号化。誰も受動的にデータを聞くことができません。暗号化は、ピア間で共有されるキーを使用して行われます。
- 身元確認。これにより、誰と話しているのかが確実になります。これは通常、証明書を使用して行われます。
識別せずに暗号化している可能性がありますが、接続はアクティブな攻撃にさらされます。そこでは、予期されるピアの代わりに、データを復号化して操作し、元のピアにデータを転送できる真ん中の男のような他のパーティと話します。再暗号化後。
識別なしとは、証明書がないことだけでなく、取得した証明書（通常は自己署名証明書）だけを信頼する場合も意味します。
したがって、TLS自体は証明書なしで暗号化を実行できますが、HTTPSは証明書を必要とします。これが、このユースケースで適切に識別する唯一の方法だからです。
いいえ、SSL証明書/公開鍵を使用せずに[〜＃〜] https [〜＃〜]にすることはできません。
SSL証明書を使用すると、サーバーはクライアントに対して自身を識別します。
自己署名証明書がある場合はHTTPSを使用できますが、自己署名証明書は最新のブラウザーでは信頼されていません。
Https接続上のデータは、送信者と受信者の両方が知っている秘密鍵を使用して暗号化されます。送信者は秘密キーを使用してデータを暗号化し、受信者は同じキーを使用してデータを復号化します。
同じキーは、リプレイ攻撃を防ぐために再利用されません。したがって、すべてのセッションで一意のキーを使用する必要があります。
さて、問題は誰が一意のキーを生成し、どのようにこの一意のキーをすべてのセッションで共有するかです。これは問題ですよね？この一意の秘密鍵は公開鍵インフラストラクチャを使用して共有され、証明書はそれに不可欠な部分です。通常、要求はクライアント（この場合はブラウザー）によって開始されます。証明書には、クライアントが生成したランダムな秘密鍵を暗号化するために使用されるサーバーの公開鍵に関する情報が含まれています。このデータは、サーバーだけが知っているサーバーの秘密鍵によってのみ復号化できます。クライアントとサーバー間で秘密鍵が確立されると、それらは安全に通信を開始できます。これは基本的にはhttpsです。
通信プロトコルの証明書ベースの（非対称）暗号化に代わるものとして、対称暗号化は、両方の当事者が知っている共有鍵などの可能性です。
SSLの代替手段、特に証明書を検討する場合は、データをネットワークに送信する前に暗号化することを検討してください。これにより、データが表示されないようにしながら、トランスポートとして任意の数のプロトコルを使用できます。復号化が成功すると、データが宛先に正常に到着し、改ざんされなかったことを示します。
技術的には、URIスキームのため、SSLなしではhttpsを使用できません。 このウィキペディアの記事 は、これを説明する素晴らしい仕事をしており、より技術的なものを探している場合は、RFC記事へのリンクが含まれています。つまり、この仕様では、httpsスキームはSSL/TLSに対応しているとされています。これは除外シナリオで、RFC仕様を無視して独自のソリューションを優先していることに注意してください（例： 独自の暗号化をロール ）ここでhttpsの独自の仕様を作成します。そのサービスを利用する人は、カスタム仕様を理解する必要があります。