Https建立安全传输原理

前言

http和https对于web developers来说肯定都不陌生，甚至是每天都在接触，然而在我接触的一些相关群体中（包括我自己），能准确说出http协议的各种头字段的含义、缓存原理，https建立安全连接过程的人很少。本文是我对最近学习的https知识点的一些整理。

关于HTTPS

HTTPS = HTTP+SSL/TLS（TLS是SSL的升级版）， 即 HTTP 下加入 SSL 层进行通信加密，不经过SSL协议加密的HTTP通讯有以下几个问题：

窃听风险（eavesdropping）：第三方可以获知通信内容。

篡改风险（tampering）：第三方可以修改通信内容。

冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

所有信息都是加密传播，第三方无法窃听。

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

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

HTTPS如何保证通信的安全性

首先讲下HTTP在通信过程，直接是明文传输，就像这样：

0.jpg

很明显， 你不想你的银行卡密码这么轻易的被黑客获取吧？于是想到对内容进行加密，客户端和服务端约定一种加密算法就行了，就像这样：

1.jpg

上面的加密方式中，通信双方使用同一种加密算法和密钥，这种加密方式称为对称加密，典型的对称加密算法有：DES、RC5、IDEA（分组加密），RC4（序列加密）

ok，现在乍看之下，内容加密之后银行卡密码没有暴露了，但是仅仅是这样还是有问题：试想，如果所有的客户端都使用同一种加密算法，那还加个毛线密？这种此地无银三百两的做法毫无实际意义。但是聪明的你很快也能想到，每个客户端都使用不同的加密算法吧！就像这样：

3.jpg

现在只要让客户端和服务器协议双方要用的加密算法就行了，就像这样：

4.jpg

嗯，好像还不错，但是客户端和服务器协商要用什么加密算法这条通信本身是没有加密的呀？还是存在被拦截并被破解密文的可能性。ok，现在需要对协商加密算法这条信息进行加密了，这里需要用到另一种加密方式了，我们称之为“非对称加密”：

非对称加密需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。典型的算法有RSA，DSA，DH。

服务器和各个客户端的关系就像这样：

5.jpg

服务器拥有一把私钥，每个客户端在与服务器连接时，服务器会返回给客户端一把公钥，客户端通过自己手中的公钥加密后的密文，只有拥有私钥的服务器才能破解，所以此时需要客户端决定此后双方通信需要用到的对称加密算法，并用公钥进行加密后发送给服务器，协定好之后，双方就使用对称加密算法进行加密通信了。上述的过程大致如下图所示：

6.jpg

现在，通信时的加密过程已经差不多完美了，但是细心的人可能会发出疑问：一开始的公钥是服务器分发给各个客户端的，那如何保证分发的过程中公钥不被黑客劫持并伪造自己的公钥给客户端呢？就像这样：

7.jpg

这里就需要权威的机构进行认证了：CA机构数字证书（需要花钱购买的）。

数字证书如何工作

CA证书包含以下内容：

证书颁发机构的名称

证书的有效期

公钥

证书所有者（Subject）

证书本身的数字签名

指纹以及指纹算法

一、验证证书的有效性

浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥。

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书；

证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了，认为是危险证书；

对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A,然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的；

证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。

里面涉及到一些比较重要的概念，比如数字签名，这里需要大致解释下什么是数字签名：

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

简单说，数字签名有两种功效：

能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。

数字签名能确定消息的完整性。

关于数字签名，可以看看阮一峰翻译过的一篇文章，写得很通俗易懂：数字签名是什么。

注意：数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

安全地获取公钥

如上述，数字证书在HTTPS通信过程中扮演身份认证和密钥分发的功能，我们可以简单模拟一下客户端与服务器之间信息交换的过程：

客户端：hello，我要跟你（xxx.com）进行数据通信;

服务器：好的，我就是xxx.com，这是我的证书，里面有我的名字和公钥等各种信息，你验证下。

客户端：（查看证书上的信息是否有误，并根据上述验证方法验证证书的有效性，如果有问题，发出警告并断开连接），Di*6D&T^@BD#H75dJ （公钥加密后的内容，翻译：我们用DES和RSA加密算法进行之后的通信）

服务器：7HUW&@O#DD#G@B（对称加密后的内容，不翻译了）

客户端：UDW@J@DH&76589DHUD（对称加密后的内容）

至此，整个HTTPS的安全通信过程已经大致讲完了，当然，还有很多细节值得深挖，比如SSL协议的握手过程等，有时间再做更细致的整理。

作者：LK2917

链接：https://www.jianshu.com/p/0935328b58e9

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。