PKI：TLS握手

Netscape把SSL弄到了3.0，然后被IETF采纳，但是改名叫TLS（Transport Layer Security），这个名字不错的，就是说在传输层上加了安全。那么，TLS是SSL的后续版本，TLS1.0是SSL3.0的一个升级版本，后续小版本还有TLS1.1和TLS1.2。
互联网上的恶意行为，比现实世界严重的多，偷窥数据的、篡改的、钓鱼的，乱七八糟，TLS可以来保障安全通信。

1. 保障机密性
   别人拦截或偷窥到的数据是加密的，解密不了。TLS先用非对称加密（如RSA）传递对称加密的密钥信息（不是密钥，是在生成密钥时要用到的信息），之后的大量数据传输，则采用对称加密。
2. 保障完整性
   网上有些人，就喜欢搞些热点，结果往往反转。其采用的阴暗的手段就是掐头去尾，恶意剪辑，只给你看到他想给你看的，不让你看到完整的经过，从而诱导受众的情绪，引爆网络。都是些坏人。TLS将消息和对称密钥一起做hash，求得的摘要值一并发送。这样通过摘要值检查，知道原始信息是否被篡改。有本事将摘要值也一起改了。能改摘要值，必定知道了对称加密的密钥。所以安全的一切的基础，在于密钥的私密。
3. 保证身份真实
   服务器要将数字证书给客户端来验证。证明不是李鬼。

TLS是基于TCP之上的，所以在TLS之前，有TCP的三路握手，然后是TLS的握手，其可分为3个阶段：

1. 参数协商

这个阶段是协商确定以下内容：双方都支持的最高版本的TLS协议是多少，双方选择使用那个算法组合（三个算法的组合：交换密钥和验证身份的、加密数据的、完整性检验的），交互双方产生的随机数。

客户端说Client Hello，服务器说Server Hello。
用wireshark可以看的清楚，这是客户端发出的hello，说我客户端能支持的TLS最高版本，支持的算法组合列表（Cipher Suites），我产生的随机数。

然后是服务器回的ServerHello，它是服务器一次性回复的其中的一部分。
整个服务器回复其实有4部分内容，如下：Server Hello. Certificate. Server Key Exchange, Server Hello Done.

先看Server Hello里面的内容，有服务器的随机数、选择的TLS版本（1.2），选择的算法组合（TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)）。即交换秘钥用RSA，加密数据用AES，完整性摘要用SHA。

2. 身份验证

因为服务器选择的算法组合中交换秘钥使用RSA，所以服务器要把它的证书给客户端，因为证书里包含了服务器的公钥。证书就是回复的Certificate部分：

反过来，服务器也可以要求客户端提供证书，以验证客户端的身份。这个不是必须的，是看上层应用的要求。这种情况，就是双向认证了。

3. 密钥交换。

使用了 ECDHE 非对称秘钥协商算法做Server Key Exchange。

然后就是服务器表示协商结束，Server Hello Done.

轮到客户端了，客户端做Client Key Exchange:

然后是Change Cipher Spec ，表示后面就用前面生成的秘钥进行数据加密了。

服务器也是Change Cipher Spec，表示后面就用前面生成的秘钥进行数据加密。

至此TLS握手结束。后面就在加密连接里进行数据通讯。4个报文完成TLS的握手，相对于TCP握手要多1个，因为它明细要复杂许多。

客户端对服务端的证书进行认证，是怎么认证的呢？

1. 证书是否过期、
2. 发行服务器证书的CA 是否可靠、
3. 发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名" 、
4. 服务器证书上的域名是否与服务器的实际域名匹配等。

那么，双向认证，即服务器对客户端也进行认证，
一般是客户端将自签名的证书发给服务端进行认证。
自签名的证书，能够保证自己是完整、未经篡改的，
但无法证明证书是属于谁的。
当然，双方之间可以手工交换来建立信任。只是这个缺点在大型数量的场景中就被放大到不可接受了。