I.説明
行って証明書の生成にもかかわらず、双方向認証、SSL通信プログラミングのようなもの、それはSSLの鍵交換を完了するかどうかは不明でした。、異なる意見であり、オンラインで情報を見て、最近の研究にこの問題や友人に話をして、顧客からのフィードバックに対処するSSLのバージョンが低すぎるリーダーシップにもいくつかの研究をして、鍵交換プロセスのSSLを見つけるために望まれるとき、先週起こりました。
第二に、鍵交換手順
最初のステップは、サーバーへのクライアント、クライアントこんにちは（クライアントランダム+セッションID +暗号スイート）;暗号スイートは、クライアントリストによってサポートされている暗号スイートです。
サービスはクライアントのHelloを受信した後、第2ステップでは、彼らがリストに知っているかどうかを確認するために、セッションID、セッションIDを削除します。
、サーバーこんにちはが返された場合、既存の通信キーを使用する必要があります（サーバーランダム+セッションID +暗号スイート+キー（クライアントランダム）が存在します）。
暗号スイートから選択したサーバーがRSA鍵交換を使用して作られた場合はDH鍵交換がそうならば、全体のサーバーこんにちはTCPは、パッケージとして返され;いない場合は、サーバーこんにちは（サーバーランダム+暗号スイート+証明書）を返します単一のリターンパッケージTCPとそう証明書。
第3のステップは、クライアントがサーバーのHelloを受けます。
既存のキーが通信するために必要されて表示された場合は、変更暗号を送信する（キー（サーバランダム）が存在）;その後、直接、後続のHTTPリクエストを送信します。
あなたが鍵合意が必要とされて表示される場合は、（署名者がCA信頼されている場合、有効な書式など、）問題の証明書は、暗号スイートを選択し何の問題サーバーが削除されていないかどうかをチェックし、RSAはクラスであり、その後、乱数を生成した場合サーバ、クライアントが選択したプレス部材キットプラス算出対称鍵を公開鍵暗号（すなわち、前マスター）を使用。クラスはDHである場合、クライアントはDH鍵のペアを生成し、公開鍵（プレーンテキスト）は、公開鍵とそれらのDH秘密鍵を使用して、クライアント証明書、サーバーに直接送信計算対称鍵です。
第四のステップは、サービスがクライアント応答を受け取ります。
変更暗号場合は、クライアントの要求を待っている、暗号化モードに切り替わります。
鍵合意した場合、RSAは、プレマスターは、乱数と乱数ジェネレータプラス3つの対称鍵によって選択された暗号スイートを取得し復号化するために、元の秘密鍵を使用して、選択してオリジナルれます。元はDHを選択した場合、撮影した自分の秘密鍵で公開鍵は、対称鍵を計算します。
第三に、鍵交換プロセス流
3.1 DH契約キー
3.2 RSA契約キー
3.3既存のキーを使用します
いくつかの4つの鍵交換プロセスを説明しました
4.1 TCP / SSL / HTTPS相互間の関係は何ですか
TCP接続を確立するために、最初の3ウェイハンドシェイクの後、し、キー交渉プロセスを、SSL、および、アプリケーション層の内容を転送し、最後の4つのTCPはまだ手を振っ：私たちは、以下に示すように、通信プロセスでのSSL見ての通りのTCPストリームを追いかけます。
だから、全体的な関係はこれです：オリジナルは現在、「TCP + HTTP」である「TCP + SSL +のhttp」であり、HTTPSは、単なる契約ではなく、「SSL +のhttp」;あなたが好きなら、あなたはどんな「+ xxxのTCP」にすることができます介在SSL形成XXXS、そのようなFTPS。
どのように理解する上で4.2 SSLセッションID
私はちょうどそのリーダーシップは、定期的にフレーズを持って、何かを感じ、その後、既存のキークライアントのHelloを用いて分析し、リーダーシップのフィードバックShihaiが言った、なぜ同じセッションIDとセッションIDでのこの新しいTCP接続の前にいないセッションIDを聴き始めました目覚め：はい、もちろん、セッションIDは、TCP接続を超えて使用されています。
也就是说，前面说的使用已有密钥模式，其中的Random、Session ID、Cipher Suite都是之前的tcp三次握手和四次挥手使用过的；从编码角度看，如果原先已协商过密钥，那可以保存Random、Session ID、Cipher Suite后续在Session ID有效期内建立SSL连接，只要进行使用已有密钥过程即可，不需要进行密钥协商过程；但一般来说，我们都不是自己实现SSL过程而都是直接调用SSL库，所以这事也不归一般的应用开发人员管。
4.3 怎么探测服务端支持哪些SSL版本和加密套件
从原理上讲，使用某个版本的SSL发送Client Hello，如果服务器不支持该版本则会使用其支持的版本回Server Hello；对于加密套件，则可能是客户端声称其只支持某个加密套件，如果返回Server Hello则表明服务端支持该加密套件，如果返回Alert（Handshake Failure）则表明服务器不支持该加密套件。
当然，其实上边都是个人的猜测，并没有充分的证据；不过这里倒可以提供一个方便的方法探测服务端支持哪些SSL版本和加密套件，即使用nmap：
# -p是端口 nmap -p 443 --script ssl-enum-ciphers 192.168.220.128 # 可以用以下命令来查看帮助说明 # nmap -p 443 --script-help ssl-enum-ciphers
结果如下图所示，各套件末尾的A/D这种表示该加密套件的加密强度级别，A级的加密强度最好
