HTTPS原理

本文主要内容

• 概念
• 加密算法
• HTTPS原理
• 总结

1、概念

• HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。

• HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

如上图所示， HTTPS 相比 HTTP 多了一层 SSL/TLS，可以把HTTPS 理解成安全的 HTTP 协议。

那SSL和TLS又是什么呢?

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

2、加密算法

HTTPS 协议中用了不同的加密算法，在此我们学习下加密算法的基础知识，加密算法有对称加密和非对称加密的方式。

• 对称加密，有流式、分组两种，加密和解密都是使用的同一个密钥。例如：DES、AES-GCM、ChaCha20-Poly1305等

• 非对称加密，加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。例如：RSA、DSA、ECDSA、 DH、ECDHE

由此可见，使用 git 即是使用非对称加密，我们需要在网页端填写公钥值。

除加密方法外，还有其它方法可以在一定程度上保证安全性

• 哈希算法，将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。例如：MD5、SHA-1、SHA-2、SHA-256 等

此前阐述过 android apk 签名及验证过程，里边就有涉及 SHA-256 算法等，通过此算法可以验证信息有没有被修改，如果修改了，哈希之后得到的值肯定会变化，所以哈希算法可以用于鉴定信息是否被篡改。

• 数字签名，保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。 数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。 接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用对收到的原文产生一个摘要信息，与解密的摘要信息对比。

3、HTTPS原理

HTTP 协议是明文协议，使用它通信，存在三个风险：

• 窃听风险（eavesdropping）：第三方可以获知通信内容。
• 篡改风险（tampering）：第三方可以修改通信内容。
• 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

为了解决这三个问题，HTTPS 协议可以说是煞费苦心。

第1步，既然明文协议不安全，那就执行加密通信

如上图所示，此种方式属于对称加密，双方拥有相同的密钥，信息得到安全传输，但此种方式的缺点是：

• 不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
• 因每个客户端、服务器的安全级别不同，密钥极易泄露

第2步，既然对称加密不行，我们换成非对称加密试试：

如上图所示，客户端使用公钥发送主动，服务端使用私钥解密请求，并且将响应内容加密，发给客户端。但上述过程也存在缺点：

• 公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容

第3步，非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势

如上图所示：

• 第 ③ 步时，客户端说：（咱们后续回话采用对称加密吧，这是对称加密的算法和对称密钥）这段话用公钥进行加密，然后传给服务器

• 服务器收到信息后，用私钥解密，提取出对称加密算法和对称密钥后，服务器说：（好的）对称密钥加密

• 后续两者之间信息的传输就可以使用对称加密的方式了

这里存在两个问题，客户端如何获取公钥呢？如何确定这是真实的服务器而不是黑客呢？如果客户端到某个地址去下载公钥，下载地址有可能是假的，而且每次对话之前还要去下载，很麻烦。如果是服务器主动将公钥交给客户端，客户端怎么确定服务器是真实的而不是黑客冒充的呢？

为了解决公钥问题，SSL证书派上用场了。

在第2步中，服务器会将一个SSL证书发送给客户端，SSL证书审核严格而且还是要收费的，它不会被冒充。客户端接收证书后，会对证书进行验证，证书验证为真后，客户端会从SSL证书中读取出一个公钥，用于接下来的非对称加密。在非对称加密中，客户端将对称加密的密钥发给服务器，服务器接收后，后续的通信就可以使用对称加密了。

SSL证书的验证过程：

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

4、总结

HTTPS协议比HTTP协议安全可靠，整个过程中黑客也没有办法监听或者篡改、冒充了。

（1） 所有信息都是加密传播，黑客无法窃听。

（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。

（3） 配备身份证书，防止身份被冒充。

另外需要提一点的就是TCP协议和 HTTP 及 HTTPS 协议的关系，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。

关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等。

HTTPS 协议在android应用时，与 HTTP 协议有一些差别，注意这些即可。