底层网络监测工具：Wireshark

一、名词全称

• HTTPS

HTTP Secure/HTTP over SSL / HTTP over TLS

• SSL

Secure Socket Layer ：安全套接字层

• TLS

Transport Layer Security：安全传输层

TLS 是 SSL的前身，在HTTPS中指的是TLS

二、HTTP+加TLS后的传输层级示意

发送：HTTP -> TLS -> TCP -> IP -> LINK

接受：LINK -> IP-> TCP -> TLS -> HTTP

简单总结：传输加一层TLS加密层，接受加一层TLS解密层

三、本质

在客户端和服务器之间使用非对称加密协商出一套对称密钥，每次发送信息之前对内容进行加密，收到之后进行解密，实现加密传输。

• 为什么不直接使用非对称加密？

非对称加密属于复杂型算法，会严重降低接受和发送的性能，降低处理效率。

四、TLS 链接流程

1.Client发送：Client Hello

• 1.TLS 版本
• 2.加密套件：对称加密算法、非对称加密算法、hash 算法
• 3.客户端随机数
• 4.其他信息

2.Server发送： ServerHello

• 1.选出可匹配的TLS版本
• 2.选出加密套件：对称加密算法、非对称加密算法、hash 算法
• 3.其他

3.Server发送：服务器证书

• 1.服务器证书(包含证书签名，公钥、主机名，地区等信息)
• 2.证书签发机构证书信息（证书公钥，与公钥签名）
• 3.指定根证书信息
• 4.其他信息

验证规则：

• 1.使用证书签发机构的私钥，对服务器的公钥的hash值进行签名。对应证书签发机构的公钥可以解开这个签名，确认服务器证书安全可信。
• 2.使用指定的根证书的公钥，可以解开证书签发机构证书公钥的签名，确认签发机构安全可信

• 到达客户端后，客户端验证链：
  • 1.客户端向系统确认服务器指定的根证书是否可信，可信则使用根证书中的公钥，解密服务器证书的签发机构证书的公钥签名
  • 2.使用签发机构的公钥解密服务器证书的公钥的签名，确认服务器证书安全可信

以上有一个验证环节未通过，那么TLS链接就建立失败。

服务器的证书只是证明网站或域名所有者，而不能证明是否合法

用Wireshark对建立HTTPS链接传输信息展示： 

4.Client 连发3个消息：

• Pre-master secret（使用服务器公钥加密）
• 将开始传输加密消息
• Finished（加密后的握手信息）

服务端使用Pre-master secret按照相同的计算方式得出跟客户端一样的加密密钥

到此阶段，两端都将会持有以下信息：

1.客户端随机数

2.服务器随机数

3.Pre-master secret 随机数

4.Master secret（两端使用相同的算法，计算上面的三个信息，得出相同的结果）

用Master secret计算出下面的对称密钥：

5.客户端加密密钥（对称密钥）

6.服务器加密密钥（对称密钥）

7.客户端MAC secret

8.服务端MAC secret

到此两方都创建出了用于对称加密的传输的密钥

5.Server 连发2个消息：

• 将开始传输加密消息
• Finished（加密后的握手信息）

时序上并不一定在客户端最后两条消息之后

将上面确认的信息 通过用加密方式发送给客户端，客户端对数据进行验证，确认两方一致。

至此一共五个大步骤，都顺利完成TLS链接就建立成功，可以使用对应的对称加密密钥进行加密传输了。

五、问：

1.服务器随机数作用？

避免replay attack:重放攻击 虽然解不开加密信息，但是将发送的加密数据拦截后重复发送给服务器，来搞破坏，比如拦截的是转账请求，换个时间段继续重放请求，多次转账。 每次链接后拿到的服务器随机数都不一样，避免被重放攻击

2.既然是对称加密，为什么客户端于服务端要用不同的加密密钥？

为了避免发送出去的数据被原封不动的又被发回来，发和收使用不同的密钥，避免这种攻击

3.既然HTTPS都用上了，为什么有时候项目上还要内部再搞一套内部加密逻辑

这个问题是个大坑，以至于从理解上就容易产生误区。

• 第一如果使用的证书不能100%信任，比如证书签发机构可能出卖用户、卖国、被恶势力控制。这时候整个HTTPS就彻底被瓦解，毫无意义。

逻辑是这么个逻辑，但在国内基本是无稽之谈！国外就不知道了。

真的不信任的话用私有证书，比起自己订一套不如TLS安全的加密逻辑来得保险得多。

当然这只是我个人的理解，也许有其他的知识面，欢迎评论提出。

• 第二HTTPS 只是传输层的加密，防的是中间人攻击。所以服务器很被动，终端伪造证书被根证书信任后都可以访问他。

所以C端个体被破解后，可以对服务端造成小范围破坏，或者有大范围破坏的风险

比如HTTPS抓包，导致单用户可授权访问的接口请求参数，返回参数都被窃取，造成数据安全，和特定接口被攻击的风险。

因此服务端需要鉴别基于某些端信任私有证书后在业务层面的非法请求，以及单用户的重放攻击（replay attack）

那么可以考虑：

1.使用私有证书，但是这会给C端带来极高的运营成本，毕竟每次更新证书都要更新C端版本

2.使用对称加密，每次请求都生成一个新的请求签名。这样第一可以防重放攻击，第二服务器可以鉴别访问者是否合法。

3.使用非对称加密先加密原始数据，再丢给HTTPS进行传输。这样抓包也不担心，破解也不担心。只需权衡性能方面的损失，通常用于支付等极度敏感的数据交互场景上。

END