HTTPS简介

HTTPS简介

HTTP协议，实现了网站的交互访问。随着互联网规模的快速扩张，网站类型的增多，HTTP以明文形式传递的报文，无法满足大多数网站的安全需求，由HTTP+（SSL/TLS）结合的HTTPS应运而生。

数据加密传输

在简述HTTPS前，我们先讨论数据在什么情况下传输，是相对安全的。这里我们引入密码学的两个重要角色：Alice（数据发送者）和Bob（数据接收者）。

相对安全的数据传输，我们需要保证：

1.机密性：保证数据不被窃取—不能以明文形式传输

2.完整性：保证数据不被篡改—验证数据完整性

3.认证：保证数据源是真正的发送者发来的—消息认证

4.不可否认性：传输双方不可抵赖自己发出的信息—非对称加密签名

机密性

对称加密

为了保证数据不被Alice和Bob以外的人窃取。通常对数据实施加密，使在不安全网络空间中传输的是一般情况下看不懂的密文形式。

综合考虑安全性和效率，我们常对数据进行对称加密，即指定加密和解密使用同一个对称密钥：

报文的机密性得到了保证，但是密钥的机密性怎么得到保证呢？

非对称加密

为了保证密钥的机密性，再对密钥进行对称加密显然不能解决实际问题。此时我们引入非对称加密—公钥私钥对。

非对称加密，公钥加密后，只能通过私钥解密，私钥加密后，只能通过公钥解密。公钥可以随意的放在网络空间中，私钥由各自安全的保管，这样就不需要担心密钥的传输问题了。

那么我们为什么不直接使用非对称加密来加密数据进行传输呢？

这就要提到前文提到的效率了，非对称加密采取的加密算法比较复杂，而传输的数据杂七杂八，如果每次数据传输都摇进行一个非对称加密和解密，双方传输的效率都会大打折扣。

结合

经过上述的讨论，对于数据机密性，我们得到一个相对安全且高效得数据传输方式：

先通过非对称加密的形式，协商本次数据传输使用的对称密钥：Alice使用Bob的公钥，对对称密钥进行加密，Bob使用自己的私钥进行解密，双方得到一个相对安全的对称密钥。

随后双方使用对称密钥对数据进行加密解密，进行数据传输。

完整性

为了保证传来的数据不被篡改，我们可以对发出的数据进行一些操作，使他生成一个简短的数据摘要。接受者可以对数据进行同样的操作，得到到接受数据的数据摘要进行比对，来确定数据是否是原来的信息。当然，我们为了保证数据摘要是原始的，我们也要使用非对称加密，对数据摘要进行加密传输。

认证

为了保证数据原始的发送者是真正的发送者，我们需要对消息进行认证，这里我们引入消息认证码。Alice使用事先商量好的对称密钥， 对数据进行一些操作（算法），得到这次数据传输的消息认证码，通过非对称加密进行传输。Bob接收到数据后，也通过同样的对称密钥，进行操作，得到自己的消息认证码，与Alice传来的消息认证码进行比对。这样我们发现消息认证码可以替代数据摘要的工作，还可以保证数据交流的双方是真正的对方（伪装者不知道对称密钥，就算可以编造数据，也没法编造消息认证码）。

不可否认性

为了防止双方数据传输后，其中一方否认是自己发出的数据，我们引入数字签名。既然采用对称加密的消息认证码，Alice可以狡辩称数据是Bob自己使用对称密钥捏造的，那么我们可以对数据摘要进行非对称加密，用Alice自己的私钥进行加密，生成数字签名。Bob在验证完整性和认证时，使用Alice的公钥进行解密。即实现了数据摘要和消息认证码的功能，又可以防止ALice事后狡辩是Bob自己捏造的数据。

真的就安全了吗？

上面我们讨论了数据的机密性，完整性，认证，不可否认性。得到了一个相对安全的数据传输过程：

Alice和Bob事先交换了双方的公钥，然后用对方的公钥协商数据传输的对称密钥，每次传输时，使用对称密钥进行原始数据加密，保证数据机密性。使用私钥对数据摘要进行加密形成数字签名，验证数据的完整性并完成发送者认证。

但是，不管是对称密钥的协商还是数字签名的验证，我们都不能保证，自己得到的公钥，就是对方传来的真正的公钥（伪装者可以在数据传输前给Alice和Bob各传递一个假的公钥）。因此，我们需要一个大家都认可的第三方，给我们的公钥做一个保护，也就是证书。证书包含了自己的公钥以及颁发机构的信息等。在一定程度的可信度上，我们采信了公正的第三方，也就保证了公钥是安全的了。

总结

证书的引入，让数据传输变得相对安全，那么我们从Alice和Bob的视角出发，总结一下数据的安全传输过程吧：

1.获取公钥：Alice和Bob建立通信连接后，先交换了双方的证书获取到对方的公钥。

2.协商对称密钥：Alice生成一个对称密钥，通过Bob的公钥进行加密，传输给Bob。Bob接收到密钥信封后，用自己的私钥进行解密，双方都得到对称密钥

3.加密数据传输：Alice生成了想发送的数据，通过一些操作（Hash函数）生成了数据摘要，然后用自己私钥进行加密，生成数字签名。Alice将数字签名和原始数据通过对称密钥进行加密，生成了密文，安全得传输给Bob。

4.接收数据解密：Bob收到了Alice发来的密文，用对称密钥解密，获取到发来的原始数据和数字签名。用Alice的公钥，对数字签名进行解密，得到发来的数据摘要，同时自己也对原始数据进行一些操作（Hash函数），得到一份数据摘要。然后对两份数据摘要进行比对，如果摘要相同，那么就放心的接受这个数据。

HTTPS

上文描述了安全传输数据的一个模型，那么我们可以对比着来描述HTTPS的传输过程：

1.客户端发送TLS版本号，生成的随机数1和自己支持的加密方法（明文）

2.服务器返回确认的加密方法，服务端的证书，生成的随机数2（明文）

3.客户端验证证书有效（浏览器和操作系统内置），然后生成随机数3，并且用有效证书中的公钥加密这个随机数，加密传输给服务器。（非对称加密密文）

4.服务器使用自己的私钥解密这个密文，得到随机数3，此时双方都有了3个随机数（2个明文传输，1个密文传输），双方根据之前确定的加密算法，生成对话密钥（对称密钥）

5.之后的每次数据传输，都使用这个密钥对数据进行加密（对称加密密文）