SSL/TLS过程解析

首先我们为什么需要SSL?

互联网的通信安全，建立在SSL/TLS协议之上。SSL/TLS协议位于应用层和传输层之间，用于对上层数据包加密之后传输，同时进行身份、数据完整性校验。

简单地讲，SSL/TLS就是同时结合各种密码算法、数字签名算法及数字证书等技术的一套协议，目的就是为了保证通信的安全性。采用SSL/TLS协议，通信双方建立连接之前需要进行握手，目的是协商出会话密钥，用于后续对通信数据的加解密操作。

加密算法分为两大类：

1、对称加密算法 数据加解密使用同一份密钥，加解密速度快，效率高，缺点是密钥的管理难度大，密钥传输绝对不可泄漏。

2、非对称加密算法 数据加解密使用公钥和私钥，公钥用于传输，私钥自己保存，安全性较高，但加解密速度偏慢。

而SSL/TLS则结合两者的优缺点，数据包的加密使用对称加密算法，而对称加密算法的密钥采用非对称加密手段协商获取。
常用的对称加密算法有：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES
常用的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）
常用的数字签名算法有：MAC、MD5、SHA1

以与CSDN的一次连接建立为例

C:\Users\DELL>ping CSDN.com

正在 Ping CSDN.com [39.106.226.142] 具有 32 字节的数据:
来自 39.106.226.142 的回复: 字节=32 时间=12ms TTL=87
来自 39.106.226.142 的回复: 字节=32 时间=11ms TTL=87
来自 39.106.226.142 的回复: 字节=32 时间=12ms TTL=87
来自 39.106.226.142 的回复: 字节=32 时间=13ms TTL=87

39.106.226.142 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 11ms，最长 = 13ms，平均 = 12ms

启动wireshark
捕获过滤器：ip.addr==39.106.226.142&&ssl
浏览器打开CSDN官网

可以看出主要发生的动作是：
1、客户端向服务器端发送一个Client Hello
2、服务器端向客户端返回一个Server Hello
3、服务器端向客户端返回一个Certificate
4、服务器端向客户端返回Server key change,Server Hello Done
5、客户端向服务器端发送Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
6、服务器端向客户端返回Change Cipher Spec, Encrypted Handshake Message
至此通信完成，开始data的传输建立。

逐步分析

1. client hello
直奔transport layer security展开：
可以看出，第一步由客户端发送密码套件（加密协议）、TLS版本、随机数等信息。密码套件即cipher suite。

2. sever hello
同样打开transport layer security：
sever回应，TLS版本号、随机数、所有支持的密码套件等。

3. certificates
这一步是sever向client发送certificates证明自己的服务器身份

server的证书信息，只包含public key，server将该public key对应的private
key保存好，用于证明server是该证书的实际拥有者，那么如何验证呢？原理很简单：client随机生成一串数，用server这里的public
key加密(显然是RSA算法)，发给server，server用private
key解密后返回给client，client与原文比较，如果一致，则说明server拥有private
key，也就说明与client通信的正是证书的拥有者，因为public key加密的数据，只有private
key才能解密，目前的技术还没发破解。利用这个原理，也能实现session key的交换，加密前的那串随机数就可用作session
key，因为除了client和server，没有第三方能获得该数据了。原理很简单，实际使用时会复杂很多，数据经过多次hash，伪随机等的运算，前面提到的client和server端的RN都会参与计算。

4. Server key change,Server Hello Done

sever key change:
运行Diffie-Hellman算法后生成pubkey

Server Hello Done：

5. Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

client key exchange:
同样运行Diffie-Hellman算法后生成pubkey。用于与server交换session key
client拿到server的certificate后，就可以开始利用certificate里的public key进行session key的交换了。client和server使用的session key是不一样的，但只要双方都知道对方使用的是什么就行了。这里会取出4个：client/server加密正文的key，client/server计算handshake数据hash的key。

Change Cipher Spec:
client告知sever从此发送的消息都是加密过的
Encrypted Handshake Message:
encrypted这个消息非常关键，一是能证明握手数据没有被篡改过，二也能证明自己确实是密钥的拥有者(这里是单边验证，只有server有certificate，server发送的Finished能证明自己含有private key，原理是一样的)。client将之前发送的所有握手消息存入handshake messages缓存，进行MD5和SHA-1两种hash运算，再与前面的master secret和一串常量"clientfinished"进行PRF伪随机运算得到12字节的verify data，还要经过改进的MD5计算得到加密信息。因为只有密钥的拥有者才能解密得到pre-master key，master key，最后得到key block后，进行hash运算得到的结果才与发送方的一致。

6. Change Cipher Spec, Encrypted Handshake Message
同理，
Server发送ChangeCipherSpec，指示Client从现在开始发送的消息都是加密过的
与client发送Finished计算方法一致。server发送的Finished里包含hash给client，client会进行校验，如果通过，说明握手过程中的数据没有被第三方篡改过，也说明server是之前交换证书的拥有者。现在双方就可以开始后续通信，进入Application context了。