What Is an SSL/TLS Handshake?
An SSL/TLS handshake is negotiation between two parties on network – like browser and web server – to establish their connection details.The SSL/TLS handshake is the negotiation of the SSL/TLS handshake on the networks – like the web server. セッションで使用される SSL/TLS のバージョン、通信を暗号化する暗号スイート、サーバー (そして時にはクライアント) の検証、データ転送の前に安全な接続が確立されていることの確認が行われます。 これは単純なバージョンです。何十もの記述がこの形式を多かれ少なかれ守っていることに気づくかもしれませんが、細部では何十もの異なる方法で、時には混乱するほど異なっています。 TLS ハンドシェイクがどのように機能するかの大まかなモデルを示すチャートを表示しましょうか。 SSL.comはあなたをカバーしています。 S/MIME やコードサイニング証明書など、オプションを比較して、あなたにぴったりのものを見つけてください。
ORDER NOW
Obligatory SSL/TLS Handshake Graphic
すべての SSL/TLS 関連サイトには、独自のハンドシェイク図があります – これが私たちの図です! (Click to enbiggen.)
できればいくつかの混乱を解決しよう
SSL/TLS ハンドシェイクがどう動くかについてのいくつかの混乱は、ハンドシェイクが実際の安全なセッションへの前段階でしかないことに起因しています。
Asymmetric vs symmetric encryption
ハンドシェイク自体は非対称暗号を使います – 公開鍵と秘密鍵の2つが使われます。 非対称暗号化システムははるかに高いオーバーヘッドを持つので、フルタイムの実世界のセキュリティを提供するためには使用できません。 したがって、ハンドシェイクの間だけ公開鍵を暗号化に、秘密鍵を復号化に使用し、両者が秘密裏に新たに作成した「共有鍵」を設定し交換できるようにします。 セッション自体はこの1つの共有鍵を使って対称型暗号化を行い、これが実際の運用で実現可能な安全な接続を実現するものです（オーバーヘッドが圧倒的に少ない）。 SSL/TLS 暗号化は非対称か対称か” に対する完全で正しい答えは “最初にどちらか、次にどちらか” です。
“cipher suite” とは何ですか？
ハンドシェイク自体は複数の段階があり、それぞれが異なる規則に従って管理されます。 詳細はこちらをご覧ください。しかし、その要点は、一連の個別の交渉 (使用する鍵、ハンドシェイク自体の暗号化方法、ハンドシェイクの認証方法など) の代わりに、当事者が「暗号スイート」、つまり合意されたコンポーネントの既存の選択またはキットの使用に合意できる、ということです。 (非対称暗号化は時間とリソースの面でコストがかかることを忘れないでください。暗号スイートをショートカットとして使うことで、ハンドシェイク自体を高速化することができます。) TLS 仕様は非常に多くの暗号スイートを許可しており、クライアントとサーバーはほとんどの場合、両者が採用できるものにアクセスできます。
Basic vs mutually-authenticated handshake
もうひとつの混乱させるポイントは、上で述べた基本モデルはクライアントにサーバーを確認させ、TLS によって保護される大半のセッションはこれだけを必要とするという点です。 しかし、一部の暗号スイートでは、両者の相互認証のために、クライアントが証明書と公開鍵も送信する必要があります。 この双方向認証はもちろんハンドシェイクにオーバーヘッドを追加しますが、場合によっては (たとえば、2 つの銀行が資金移動のための安全な接続を交渉している場合など)、暗号スイートがこれを要求し、追加のセキュリティがそれに値すると判断されることがあります。 これが、この忌まわしいハンドシェイク チャートの多くの異なる反復が存在する理由の 1 つであり、ここでかなり広範な概要を説明する理由でもあります。 また、セッションは、あなたが期待するものとは異なるパラメータを設定できることも知っておいてください。 暗号スイートによっては、いくつかのステップが追加されたり(双方向認証の要件など)、なかったりします。 実際、セッションが暗号化を一切使用しないようにネゴシエートする暗号スイートもあります。 (ポート 443 を介した HTTPS 接続が、データを平文で送信することを決定していることは、我々にとっても意味のないことです。 SSL.comではこのようなことをしないよう強く推奨しています – ただ、可能性の領域であることは認識しておいてください。