web-dev-qa-db-ja.com

なぜ自己署名httpsは暗号化されていないhttpより信頼性が低いのですか?

2014年にWebトラフィックの少なくとも50%が傍受される可能性があると推測するのは簡単です。

ただし、アクティブな傍受攻撃の推定値はおそらく1桁低く、おそらく0.5%をはるかに下回っています。明らかに、その多くは政府によって行われており、潜在的に 認証局を管理している可能性があります)とにかく なので、信頼できるCAチェーンを持つことの価値には疑問があります。

ほとんどのトラフィックは単にパッシブに傍受されるため、認証なしの暗号化により監視から逃れ、プライバシーの権利をこれらのケースの99,9%で維持できるため、ブラウザーベンダーとhttps業界がhttp暗号化を効果的に促進しない理由私のようなWeb愛好家のための自己署名https証明書?


数十の自己ホストドメイン上の私の電子メールは無料で暗号化され(SMTP STARTTLS)、Xか月ごとに新しい証明書をインストールする必要がなく、私に電子メールを送信する人も警告を受けません。

(同様にsshを効果的に使用することで、誰かに支払いを送金する必要がなくなります。)

非営利のWebサイトとWebプロパティで同じことができないのはなぜですか?

8
cnst

ほとんどのトラフィックは単に受動的に傍受されるため、認証なしの暗号化により監視から逃れることができます....

同じ(W)LAN内にいる場合、通常、トラフィックをアクティブに傍受することは簡単です。 ARPスプーフィングまたは類似の手法を実行する。また、より広いインターネットでトラフィックを受動的に傍受できる当事者にとっては、通常、DNSスプーフィングなどの何らかの方法でトラフィックを変更またはリダイレクトすることも可能であり、広告を挿入するようにトラフィックを変更するISPもあります。

プレーンなHTTP(暗号化なし)、「単純な」HTTPS、および「より良い」HTTPS(拡張検証証明書など)の違いを人々が理解することはすでに困難です。ここで提案するのは、暗号化なしよりわずかに優れ、単純なHTTPSよりもはるかに悪い別のセキュリティレベルです。取得したピア証明書を盲目的に信頼すると、簡単な中間者攻撃にさらされるだけです。

もちろん、特定のサービスを使用する人が少ない場合は、自己署名証明書または同様の手法を使用できます。ただし、この場合は、証明書または公開鍵を別の方法で取得し、接続によって提示された指紋と照合するなど、証明書または公開鍵をオフバンドで検証する必要があります。これは、独自のメールサーバーがある場合、または制御するホストでSSHを実行する場合に機能します。ただし、通常、オフバンド検証のための確立された安全なインフラストラクチャがないため、これはより大きなオーディエンスには機能しません。

6
Steffen Ullrich

現在、指定されているプロトコルは2つだけです。プレーンHTTPと、有効な証明書を必要とするHTTPSです。 「自己署名証明書でHTTPSが可能になりました」とだけ述べた場合、ブラウザーは、アクセスしようとしているサイトが自己署名証明書を持っているかどうか、または攻撃されているかどうかを判別できません。したがって、セキュリティが低下します。

新しいURLスキームを定義できます。自己署名証明書が期待されるhttpe。役立つ前に、すべてのブラウザで実装する必要があります。

ガイドラインとしてHTTPSのみを使用し、自己署名証明書が検出された場合に南京錠のアイコンを表示しないことは非常に危険です:Webアプリケーションが機密データをhttps URLに送信するとします-安全な接続の場合、これらのリクエストを通過させたくないとします。確立できません。したがって、たとえ望んだとしても、https =からの移行は暗号化と認証の両方で機能しません。

また、実際のリクエストの前にHTTPサーバーに日和​​見暗号化をサポートしているかどうかを尋ね、サポートしていると言われたら、HTTP URLを表示したままTLSにアップグレードすることもできます。そのような何かが実際にHTTP 2 here および here に対して提案されています。

余談ですが、StartSSLは非営利/非機密の使用のために無料の証明書を提供しています(この制限は policy 、セクション3.1.2.1に隠されています)。

5
Jan Schejbal

@SteffenUllrichと同意しますが、これだけでは実際に保護される脅威モデルはほとんどありません。信頼できないHTTPSが使用された場合、受動的にスニッフィングできる事実上すべての状況をアクティブにスニッフィングすることもできます。このスキームをMoxie Marlinspikes収束( www.convergence.io )のようなものと一緒に使用すると、偶然にも効果的で、現在のCAモデルをより堅牢なものに置き換えようとします。それ自体には欠点があると思いますが、その方が快適だと思います(これらの欠点は、現在のCAインフラストラクチャの欠点の大部分は完全に不十分です)。

そして、あなたの質問に答えるために、自己署名はプレーンHTTPよりも優れていますが、クライアントが接続しているサーバーのIDを検証する方法がないため、セキュリティの向上は実際には非常にわずかです。

2
user2867314

これはあなたの声明であり、IMO自己署名証明書またはCA期限切れ署名付き証明書は、どれも(HTTP)よりも信頼できます。

最も安全性の高いセキュリティプロトコル:1. HSTS 2. HTTPS 3. HTTP

誰があなたの証明書に署名したかは、証明書の安全性とは関係ありませんか?それは誰がそれを解読できるかにかかっています。

暗号化は、認証、否認防止、完全性、および機密性によって定義されます。

自己署名証明書は誰でも作成できますが、否認防止が保証されていません(偽のIDである可能性があります)。

理論的には、これは署名された証明書よりも信頼性が低くなります。 CA証明書(署名済み)は理論的にはより安全ですが、簡単に回避できます:c.f. SSLStripまたはSSLSnif http://www.thoughtcrime.org/software/sslsniff/

HTTP(S)はステートレスプロトコルであり、POST、GET、PUTフレームを操作したり、Cookieを作成したりできます。 HTTPSは暗号化を提供しますが、HTTPは暗号化を提供しませんが、証明書(CA署名、期限切れ、自己署名)に関係なく重要な情報を伝達する場合は、暗号化をまったく行わないよりも望ましいです。

ここにあなたが興味を持っているかもしれない代替案があります: http://convergence.io/

1
Florian Bidabe