SSL証明書が有効でない場合（期限切れ、スネークオイル、信頼できないCAなど）でも、接続は暗号化されます。 SSL証明書の検証は、あなたが接続していると思う人々に接続していることを確認するだけです。データを解読する人がPaypalではなくクラッカーである場合、暗号化は役に立ちません。
実際、Diffie-Hellmanまたは同様のキー交換アルゴリズムを使用して、証明書なしで完全な見知らぬ人の間で暗号化された接続を確立することが可能です。
アリスとボブは乱数に同意しますx。アリスはxa、ここでaはアリスのみが知っている大きな素数であり、それをボブに送信します。ボブの計算xbそしてそれをアリスに送信します。アリスは（xb）a、そしてボブは（xa）b。 （xa）b = （xb）a = xab、アリスとボブは両方とも番号を知っているxab暗号化キーとして使用できます。この利点は、ボブがaを知らないこと、アリスがbを知らないこと、そして盗聴者がどちらの数も知らないことです（計算するためa from xa、数が多い場合は数年かかります）。
Supercatが指摘しているように、これ自体は依然として中間者攻撃の影響を受けやすいため、トランザクションの少なくとも一方の端が証明書を使用して認証する必要があります。正確には、これをチェックするのはサーバーではなく、ブラウザーです。ほとんどのブラウザーでは、証明書が無効（または場合によってはゴミ）の場合でもユーザーが続行できます。その場合、接続は通常の接続よりもかなり安全です。リッスンするには、IPルーティングまたはDNSルックアップを操作できる必要があり、接続が最初に確立される前にセットアップする必要がありますが、これは簡単ではありません。
ところで、証明書のキーペアは じゃない 実際のトラフィックの暗号化に使用されるもの;これらは、より高速な対称暗号（DESなど）の新しい使い捨てキーを確立するために使用され、残りの作業を行います。
SSL証明書の検証が行われなかった場合、通信チャネルを傍受した誰かが https://www.acmebank.com への接続要求をキャプチャし、www.acmebank.comに独自の要求を送信できます。 、acmebank.comとユーザーの両方とキーをネゴシエートします。その後、ユーザーから各データを受け取り、ユーザーのキーで復号化し、acmebankのキーで暗号化し、acmebank.comのデータで同様に行うことができます。最終的な効果は、ユーザーもacmebankも間違ったものを見ることはないが、インターセプターはユーザーとacmebank間のすべてのデータを解読できることです。ユーザーと銀行は異なるキーを使用して通信を処理しますが、どちらのエンティティもこれを認識しません。インターセプターがそのようなクエリを検出し、応答を適切に変更できるため、プロトコルに標準的な側面を追加して使用中のキーを照会しても役に立ちません。
SSLは、侵入者が偽造できない形式で暗号化された（侵入者がCAを偽造できない限り）ホストが使用しているキーのコピーを受信者に送信することをホストに要求することにより、中間者攻撃を防ぎます資格情報、少なくとも）。 CAが発行した証明書を使用しない場合、中間者攻撃に対する保護はほとんどありませんが、暗号化された層はセッションコンテンツの受動的または遡及的な復号化を防ぎます（ところで、何かのための標準があればいいのに受動的または遡及的復号化が主要な脅威であるが、私は知らない状況のために、暗号化されていない通信とSSLの間。
無効なSSL証明書でもう悩まないでください。これで、スネークオイル（自己署名、ブラウザー無効）証明書を生成するのと同じくらい簡単に、サーバー用の無料ブラウザー有効証明書を生成できます。 https://letsencrypt.org/ を参照してください。無料で投稿できます。
いや。 HTTPSを使用する場合、ブラウザに別のポート（443）経由で接続するように指示しますが、通常は（80）経由で接続します。証明書がなければ、サーバーは接続を拒否します。 HTTPSは証明書なしでは不可能です。ここを見ると、 証明書が必要です が表示されます。
暗号化された接続を確立することは可能ですが、実際のサーバーではなく、クラックされたcpmputerと通信している可能性があります。そのように、クラックされたコンピューターは、サーバーに自分がクライアントになることを伝え、すべてのデータを復号化して保存し、暗号化されたデータをクライアントに送信します（そして彼がサーバーになることを伝えます）。したがって、サーバーとクライアントの間に脆弱なポイントがなければ、それは安全な接続であり、誰も保証できません。