web-dev-qa-db-ja.com

SSL暗号化とSSL証明書

私は、SSL\TLSセッションがSSL証明書なしで続行できる可能性があることを知っています。つまり、暗号化されたデータを渡すことはできますが、実際に作業している人物の確固たる基盤がありません。

これはどのように行われますか?

また、PuTTYを使用してエンドポイントに接続するときのSSL通信プロセスは、セキュアセッションでWebサーバーと通信するときとは異なりますか?

8
Franko

SSL/TLSハンドシェイクと呼ばれる手順で始まります。クライアントとサーバーは、使用する暗号アルゴリズムに同意します(暗号スイート)、そして、非対称暗号化マジックを実行して共有シークレットを確立します。共有シークレットは、セッション期間中、後で交換されるアプリケーションデータの対称暗号化と整合性チェックに使用されます。

通常、「鍵交換」ビットは以下を前提としています。

  • サーバーは、公開鍵を certificate (X.509で指定)の一部として送信します。
  • クライアントvalidates自身のトラストアンカーセット(別名「ルート証明書」)に関する証明書。本物であること、および目的のサーバーの公開鍵が含まれていることを確認します。
  • クライアントはサーバーの公開キーを使用して非対称キー交換を実行します。通常はencryptingサーバーの公開キーを含むランダムな文字列(サーバーは秘密キーを使用して復号化します)(スキップします)この回答には関係のない詳細)。

サーバー証明書の難しい部分は、クライアントが受け入れる証明書にサーバーの公開鍵が必要なことです。クライアントは署名に基づいて証明書を受け入れるため、有限セットアプリオリ既知の公開鍵(「ルート証明機関」の鍵)に対して検証されるため、検証に適した証明書を取得できます。言われた証明機関に尋ねることによってだけ。ほとんどのCAはこれを有料でのみ行います( StartSSL は無料で行います)。クライアントに独自の「ルート証明書」を追加して、実際には独自のCAを管理し、独自の証明書を発行できるため、クライアントコードを制御すれば、事はより簡単になります。これは依然として鍵管理であり(恐ろしい 公開鍵インフラストラクチャ )、そのため、コストがゼロではありません。

「証明書なし」のSSLは、次の2つの方法で実行できます。

  • 「DH_anon」暗号スイートの1つを使用できます。これらは、クライアントとサーバーの両方が証明書がないことに同意する暗号スイートです。キー交換は Diffie-Hellman キー交換に依存しています。ほとんどのクライアント実装(読み取り:Webブラウザー)canはこれをサポートしますが、デフォルトではほとんどの場合非アクティブ化されています。

  • サーバーに彼の公開鍵を偽の証明書として送信させることができます。証明書は単なるコンテナー形式です。 「signature」フィールドにほぼ適切な長さのバイトシーケンスを配置する限り、それはフォーマットに適合します(従来、サーバーが独自のCAであるかのように、「自己署名」証明書を使用しますが、ジャンクバイトのシーケンスはすべて実行されます)。もちろん、クライアントは証明書を検証できなくなります。 Webブラウザは恐ろしい警告で大声で不満を言うでしょう。

Webブラウザーは自己署名証明書を見ると大声で叫びますが、(「何をしているのかわかっている」ボタンを数回クリックした後)「例外」をインストールすることもできます。これにより、クライアントは未検証の証明書の使用を受け入れます。例外の良い部分は、永続化できることです。サーバーは問題の証明書のコピーを保存し、次にクライアントが同じサーバーに接続してサーバーがまったく同じ証明書を送り返すときに、クライアントはもはや文句を言う。インストールされた例外には弱点があります(つまり、ユーザーが「例外をインストールする」ことを決定したとき:その時点では、証明書が正しいものであるか、それとも干渉する攻撃者のものであるかはわかりません)。しかしその後、セキュリティは回復します。

(例外をインストールすることで恐ろしい警告を回避するようにユーザーを訓練することは、疑わしい品質のアイデアです。)

PuTTY はSSLクライアントではありません。 [〜#〜] ssh [〜#〜] プロトコルを使用します。これは、概念的にはSSLプロトコルと似ていますが、実際にはSSLプロトコルとは異なります。 SSHプロトコルは、自己署名証明書とインストールされた例外を使用して上記で説明したものと同じモデルに依存しているため、証明書なしです。特定のサーバーに初めて接続するとき、SSHクライアント(PuTTY)はサーバーの公開鍵を受け入れる前に確認を求め、通常は公開鍵(ハッシュ値)の「フィンガープリント」を表示して、そのフィンガープリントと比較できるようにします期待値(たとえば、「帯域外」を知っている、たとえば、暗記した、またはシステム管理者に電話をかけたが、彼がそれを綴った)その後、SSHクライアントは公開鍵を永続的に記録し、確認を求めなくなります-しかし、ある特定のクライアントが突然different公開鍵を使用した場合、SSHクライアントは、Webブラウザーが直面するよりもさらに大きな声で叫びます新しい自己署名証明書に。

13
Thomas Pornin