揭示Http的不足与HTTPS加密机制：从明文到SSL/TLS-优快云博客

本文链接：https://blog.youkuaiyun.com/jthou20121212/article/details/120752613

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

一、Http 的缺点？
二、SSL 和 TLS
三、Https
TLS 握手过程
参考

一、Http 的缺点？

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装
无法证明报文的完整性，所以有可能已遭篡改

这些问题不仅在 http 上出现，其他未加密的协议中也会存在类似问题

1.1 通信使用明文可能会被窃听

由于 http 本身不具备加密的功能，所以也无法做到对通信整体进行加密，http 报文使用明文进行发送。按 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视

1.2 不验证通信方的身份就可能遭遇伪装

http 协议中的请求和响应不会对通信方进行确认，任何人都可以发送请求，服务器只要接收到请求不管对方是谁都会返回一个响应，会有以下隐患

无法确定请求发送到的服务器是真正的服务器有可能是伪装的服务器
无法确定响应返回到的客户端是真正的客户端有可能是伪装的客户端
无法确定正在通信的对方是否具备访问权限
无法判定请求是来自何方、出自谁手
即使是无意义的请求也会照单全收，无法阻止海量请求下的 Dos 攻击（Denial of Service 拒绝服务攻击）

1.3 无法验证报文完整性可能已遭篡改

由于 http 协议无法证明通信的报文的完整性，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或者响应被篡改也没办法获悉

二、SSL 和 TLS

SSL（Secure Socket Layer）最初是由浏览器开发商网景通信公司（Netscape Communications Corporation）倡导开发的，后来 IETF（Internet Engineering Task Force 国际互联网工程任务组）以 SSL 3.0 为基准制定了 TLS1.0、TLS1.1、TLS1.2、TLS1.3 几个版本，作用是保证通信安全和数据完整性。以下统称 SSL

三、Https

https 并非一种新的协议，只是 http 通信接口部分用 SSL 协议代替，http 直接和 tcp 通信，当使用 SSL 时先和 SSL 通信，再由 SSL 和 TCP 通信。在使用 SSL 后，http 就有了 SSL 的加密、证书和完整性保护这些能力

3.1 加密

3.11 对称加密

加密和解密同用一个密钥的加密方式称为共享密钥加密，也被叫做对称密钥加密。它的缺点是不够安全，因为以这种方式加密时必须将密钥发给对方，发送密钥时候有可能被攻击者拿到就失去了加密的意义，另外如果可以安全的将密钥发送给对方那么数据也能够发送给对方

3.12 非对称加密

非对称加密算法需要两个密钥来进行加密和解密，一个公钥（public key）一个私钥（private key）其中公钥是公开的，任何人都可以获得，而私钥是保密的，发送方通过公钥/私钥加密，接收方通过私钥/公钥解密。非对称加密不需要传输密钥，所以在密钥传输上不存在安全性问题，安全性上高于对称加密算法。缺点是加密方式比较复杂效率较低

https 充分利用两者的优势，使用非对称加密对对称加密的密钥进行加密

客户端使用非对称加密的公钥对对称加密的密钥加密传给服务器
服务器使用非对称加密的私钥对客户端发过来的消息解密拿到对称加密的密钥
服务器使用对称加密的密钥对消息加密发送给客户端
客户端使用对称加密的密钥解密

这里还有最后一个问题就是非对称加密的公钥的发送方式，如何保证客户端拿到的公钥就是服务器发布的那个公钥，有可能在传输途中就被攻击者替换掉了，然后攻击者在客户端侧作为服务器，在服务器侧作为客户端就可以监听整个通信过程了（抓包工具的基本原理）。所以引入了数字证书

3.2 数字摘要

数字摘要就是采用单向（不可逆） Hash 函数将需要加密（严格来说这里并不是加密只是一种摘要算法，用加密描述简单一些）的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。

3.3 数字签名

数字签名有两个作用，一是能确定消息确实是由发送方签名并发出来的，二是数字签名能确定数据报文内容是否被篡改，保证消息的完整性。另外一般来说，非对称加密是用来处理短消息的，比较合理的做法是在数字签名前对消息先进行数字摘要。数字签名的基本工作流程如下：

发送方将数据进行加密（hash 函数）生成数字摘要
使用非对称加密的私钥对摘要进行加密生成数字签名
将原数据和数字签名一起发送给接收方
接收方使用公钥对数字签名进行解密得到一份数字摘要 A
接收方对原数据进行加密（hash 函数）得到一份摘要 B
比较摘要 A 与摘要 B 一致则说明数据没有被篡改过

由公钥可以解密可以确认发送方身份，由摘要 A 与摘要 B 一致说明数据没有篡改过

3.4 数字证书

服务器运营人员将服务器资料提交给证书颁发机构（CA, Certificate Authority）CA 在确认了提交者的身份后制作一份数字证书。数字证书包含所有者的公钥、颁发数字证书的日期、数字证书的到期日期、发行机构的名称、发行机构的数字签名。客户端在与服务器握手过程中服务器把证书发给客户端校验，客户端通过系统中内置的证书颁发机构的公钥拿到数字签名和服务器公钥，通过数字签名确认对方身份，接下来客户端生成一个随机数（Premaster secret），并使用数字证书中的公钥加密这个随机数发给服务器，之后两端根据约定的加密算法生成对称密钥，然后就可以使用这个密钥加密之后传输的内容了

TLS 握手过程

https 除了 tcp 三次握手外还要进行 tls 握手，过程如下：

在建立 Tcp 连接后客户端向服务器发送 Client Hello 消息，包含客户端版本号、支持的密码套件列表和一个随机数（Client Random）

服务端收到 Client Hello 消息后选择一个密码套件（以 ECDHE 算法为例）、版本号、和一个随机数（Server Random）发送给客户端

服务端发送证书给客户端

服务端发送 Server Key Exchange 消息包含椭圆曲线的公钥（Server Params）用来实现秘钥交换算法再加上自己的私钥签名认证

服务端发送 Server Hello Done 消息

到此为止客户端和服务端共享了 Client Random、Server Random、Server Params 参数，客户端通过证书链逐级校验证书真实性，再用证书公钥验证签名确认服务端身份

客户端根据密码套件的要求也生成一个椭圆曲线的公钥（Client Params）用 Client Key Exchange 消息发送给服务端

客户端和服务端都有了 Client Params 和 Server Params 通过 ECDHE 算法计算出一个新的随机数 Pre-Master （为了强化随机性）

客户端和服务端使用三个随机数 Client Random、Server Random、pre-master 生成主密钥（Master Secret）

客户端发送 Change Cipher Spec 消息

客户端发送 Finished 消息把之前所有发送的数据做个摘要再加密一下发送给服务端，让服务端验证

服务端是同样的操作，发 Change Cipher Spec 和 Finished 消息，双方都验证加密解密没有问题握手正式结束，后面就收发被加密的 HTTP 请求和响应了

以上是使用 ECDHE 实现秘钥交换的握手过程如果使用 RAS 稍微有些不同，大体的流程没有变，只是 Pre-Master 不再需要用算法生成，而是客户端直接生成随机数，然后用服务端的公钥加密，通过 Client Key Exchange 消息发给服务端。服务端再用私钥解密，这样双方也实现了共享三个随机数，就可以生成主密钥（Master Secret）了