一、说明
尽管做过证书生成、双向认证、SSL通信编程等事情，但一直不清楚SSL如何完成密钥交换。看网上的资料则众说纷纭，最近和朋友学习时聊到了这个问题，然后正巧上周处理客户反馈SSL版本过低时领导也想弄清SSL的密钥交换过程，所以来研究一番。
二、密钥交换过程
第一步，客户端向服务端，Client Hello（Client Random+Session ID+Cipher Suites）；Cipher Suites是客户端支持的加密套件列表。
第二步，服务端接收到Client Hello后，取出Session ID看该Session ID是否在自己认识的列表中。
如果在，则返回Server Hello（Server Random+Session ID+Cipher Suite+Exist Key(Client Random)），要求使用已有密钥进行通信。
如果不在，则返回Server Hello（Server Random+Cipher Suite+Certificate）；其中，如果服务器选Cipher Suite使用RSA做密钥交换那么整个Server Hello以一个tcp包的形式返回，如果使用DH做密钥交换那么Certificate等都单独用一个tcp包返回。
第三步，客户端接收到Server Hello。
如果看到是要求使用已有密钥进行通信，则发送Change Cipher（Exist Key(Server Random)）；然后后续就直接发送http请求。
如果看到是要求密钥协商，则查看证书是否有问题（比如格式、有效期、签名者是否是受信任CA），没问题则取出服务器选中的加密套件；如果是RSA类，再生成一个随机数使用公钥加密（即PreMaster）发往服务器，客户端则按选好的套件加件计算出对称密钥。如果是DH类，则客户端生成一对DH密钥，将公钥（明文）直接发往服务器，客户端使用证书中的公钥和自己DH的私钥计算出对称密钥。
第四步，服务端接收到客户端响应。
如果是Change Cipher，那么就切换至加密模式，等侯客户端请求。
如果是密钥协商，且原先选的是RSA，则使用私钥解密PreMaster获取原随机数，然后按选好的加密套件加三个随机数生成对称密钥。如果原先选的是DH，则取出公钥结合自己的私钥计算出对称密钥。
三、密钥交换过程数据流
3.1 使用DH协商密钥
3.2 使用RSA协商密钥
3.3 使用已有密钥
四、密钥交换过程的几点说明
4.1 TCP/SSL/HTTPS相互之间是什么关系
我们追路tcp流来看一下ssl的通信过程，如下图所示：先是经过了三次握手建立tcp连接，然后再进行ssl的密钥协商过程，然后传输应用层内容，最后仍是tcp四次挥手。
所以总的关系就是：原先是“tcp+http”现在是“tcp+ssl+http”；https不是一个纯粹的协议，而是“ssl+http”；只要你愿意你可以在任意“tcp+xxx”中间插入ssl形成xxxs，如ftps。
4.2 SSL中的Session ID怎么理解
我刚开始听Session ID没什么感觉，然后分析使用已有密钥Client Hello时还和领导反馈说，为什么这个新建的tcp连接中的Session ID和前面的Session ID一样，然后领导又经常性地一语惊醒梦中人：当然一样Session ID就是用来超越tcp连接的。
也就是说，前面说的使用已有密钥模式，其中的Random、Session ID、Cipher Suite都是之前的tcp三次握手和四次挥手使用过的；从编码角度看，如果原先已协商过密钥，那可以保存Random、Session ID、Cipher Suite后续在Session ID有效期内建立SSL连接，只要进行使用已有密钥过程即可，不需要进行密钥协商过程；但一般来说，我们都不是自己实现SSL过程而都是直接调用SSL库，所以这事也不归一般的应用开发人员管。
4.3 RSA在密钥协商中的作用是什么
DH密钥协商过程是比较好理解的，对方的公钥的自己私钥次方等于自己的公钥的对方公钥次方，这个值即是公钥（当然是离散对数运行不是直接的数据运算）；RSA怎么完成密钥协商呢？
个人猜测，在密钥交换中RSA仅仅用于第三个随机数的公钥加密私钥解密，最终的对称秘钥和RSA没关系，可能是SHA（Client Random+Server Random+New Random）这种形式生成的。
但如果是这样的话，就不太明白为什么说RSA是唯一可于签名和密钥交换的算法，ECC有什么区别？
4.4 怎么探测服务端支持哪些SSL版本和加密套件
从原理上讲，使用某个版本的SSL发送Client Hello，如果服务器不支持该版本则会使用其支持的版本回Server Hello；对于加密套件，则可能是客户端声称其只支持某个加密套件，如果返回Server Hello则表明服务端支持该加密套件，如果返回Alert（Handshake Failure）则表明服务器不支持该加密套件。
如果要测服务端支不支持某个SSL版本或者某个加密套件，那么推荐使用openssl：
# -ssl3指定只使用ssl v3版本 # -cipher指定加密套，可使用openssl ciphers查看所有加密套件 # -ssl3和-cipher两个选项不是强相关的，可只指定其中一个 # 另外要注意有些加密套件可能只持部分SSL版本，注意看清到底报什么错 openssl s_client -ssl3 -cipher DH-RSA-DES-CBC3-SHA -host 192.168.220.128 -port 443
如果要探测服务端支持的所有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级的加密强度最好
4.5 SSL和SSH有没有关系
SSL是Netscape公司提出的，OpenSSL是OpenSSL管理管员会维护的一个SSL实现，其他括SSL协议库、应用程序（openssl可执行程序）以及密码算法库（包括各类主流加密算法）三部分。
OpenSSH是OpenBSD维护的一个项目，最开始使用OpenSSL的密码算法库，由于“心脏出血（heartbleed）”漏洞，OpenSSH已从OpenSSL转向自己开发的分支LibreSSL。
总而言之，SSH和SSL都是非对称算法协商对称密钥最后使用对称加密，过程很相似但他们的具体有差别；至于SSH为什么不直接使用SSL的设计，可能是SSH和SSL基本同时延生然后SSH的设计者觉得没必要换吧。
一个SSH密钥交换过程如下：
第一步，客户端向服务端发送自己的客户端信息（SSH版本+实现软件+软件版本，实现软件和软件版本并没有多大意义服务端后续步骤不会因为客户端的不同而不同）；
第二步，服务端向客户端发送自己的服务端信息（SSH版本+实现软件+软件版本，实现软件和软件版本并没有多大意义客户端后续步骤不会因为服务端的不同而不同）；
第三步，客户端向服务端发送自己支持的算法列表；
第四步，服务端向客户端发送自己支持的算法列表（这设计与SSL相比就显得多余？）；
第五步，客户端发送选择的密钥计算方法+自己的DH公钥；
第六步，服务端回复确认使用的密钥计算方法+自己的DH公钥，并表示已准备好可切换至加密模式；
第七步，客户端回复确认将进入加密模式；
第八步，后边就是加密通信，包括用户名密码认证等步骤。
