谈谈HTTPS演变过程-轻识

走过路过不要错过

点击蓝字关注我们

前言

本文谈谈HTTPS设计演变过程，希望对大家理解HTTPS有帮助，有不对的地方欢迎指出。

密码学基础知识

在讨论HTTPS之前，需要掌握一些密码学基础概念。

明文、密文、密钥

明文： 指没有经过加密的信息/数据。

密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。

密钥：是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。

对称加密

定义：需要对加密和解密使用相同密钥的加密算法。由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。

常用的对称加密算法： DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK等。

加密过程： 明文 + 加密算法 + 私钥 => 密文

解密过程： 密文 + 解密算法 + 私钥 => 明文

由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。

非对称加密

定义

非对称加密算法需要两个密钥：公开密钥和私有密钥。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
公钥指的是公共的密钥，任何人都可以获得该密钥。私钥被自己保存，不能对外泄露。
因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

常用非对称加密算法： RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。

被公钥加密过的密文只能被私钥解密，过程如下：

明文 + 加密算法 + 公钥 => 密文，密文 + 解密算法 + 私钥 => 明文

被私钥加密过的密文只能被公钥解密，过程如下：

明文 + 加密算法 + 私钥 => 密文，密文 + 解密算法 + 公钥 => 明文

HTTP明文传输

HTTPS发展源头是HTTP（超文本传输协议），所以我们先来看看HTTP传输，如下：

流程

客户端，把一条消息，以明文的方式，发送到服务器。

那么在网络上赤裸裸的明文传输会有什么问题呢？

问题

请君试想，如果HTTP请求被某个不怀好意的中间人截取，并且，消息包含银行密码等敏感信息的话，造成的后果不堪设想吧。

解决方案

既然明文传输会有问题，那么，我们可以用加密算法加密嘛。

对称算法加密+HTTP

接下来，看看用对称算法加密后，是怎样的，如图：

流程

客户端把要发送的消息，用密钥加密成密文。
客户端把密文发送到服务器。
服务器收到密文消息，用同一把密钥把密文解密成明文。

问题

这种方式还是有问题，一开始客户端怎么把密钥发过去呢？如果不怀好意的中间人截取到了密钥，发送的消息还是会被盗取和利用呢。

解决方案

可以考虑非对称加密试试。

非对称加密+HTTP

OK,我们再来看看，使用非对称加密算法，又是怎样，如图：

流程

客户端向服务器发起HTTPS请求，连接到服务器的443端口。
服务端将自己的公钥返回到客户端。
客户端使用返回的公钥，给要发送的消息加密。
客户端将加密之后的消息密文发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到消息数据。

问题

纵观整个过程，感觉没啥问题，即使中间人截取了公钥，也没啥用，他没有私钥解密不了。但是，非对称算法（如：RSA）有个弊端，它很慢。试想一下，如果你用浏览器请求，它很久才响应，你能接受吗？

解决方案

因为对称加密快，但是它安全性不高，非对称加密安全性高，但是它慢，那么，可以考虑非对称加密+对称加密结合一起嘛。

非对称加密+对称加密+HTTP

非对称加密+对称加密双剑合璧的流程图如下：

流程

客户端向服务器发起HTTPS请求，连接到服务器的443端口。
服务端将自己的公钥返回到客户端。
客户端产生对称加密密钥，并用服务端返回的公钥对它加密
客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
服务器将加密后的密文返回给客户端。
客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。

问题

这个流程看来，似乎已经天衣无缝了呢？但是，如果中间人又来搞事情呢？要是中间人截取公钥，把公钥进行篡改呢? 打个比喻，把公钥比喻你自己的手机号，它是公开的，谁都可以给你打电话。假设你发消息给你朋友，告诉他你的手机号，然后消息被中间人截取修改了，改为110，然后你朋友不知情的情况下，拨通110，打电话给你。。。

解决方案

为了避免公钥被篡改，需要引入数字签名，类似给你的公钥盖个章，证明身份用。

数字证书登场

为了避免公钥被篡改，引入了数字证书，如图所下：

数字证书构成

公钥和个人信息，经过Hash算法加密，形成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，形成数字签名.
公钥和个人信息、数字签名共同构成数字证书。

数字证书验证

拿到数字证书之后，用同样的Hash算法，先再次生成消息摘要；
然后用CA的公钥对数字签名解密，得到CA创建的消息摘要，两者对比，就知道有没有人篡改了。

完整的HTTPS运行流程图

介绍完数字证书，完整的HTTPS流程千呼万唤始出来了，如图：

用户在浏览器里输入一个https网址，然后连接到server的443端口。
服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。
服务器将自己的数字证书（含有公钥）发送给客户端。
客户端收到服务器端的数字证书之后，会对其进行检查，如果不通过，则弹出警告框。如果证书没问题，则生成一个密钥（对称加密），用证书的公钥对它加密。
客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后得到客户端密钥，然后用客户端密钥对返回数据进行对称加密，这样数据就变成了密文。
服务器将加密后的密文返回给客户端。
客户端收到服务器发返回的密文，用自己的密钥（客户端密钥）对其进行对称解密，得到服务器返回的数据。

总结

对称加密效率高，所以最终目的是要使用对称加密进行客户端与服务端的通信。但客户端如何告诉服务端要共同使用的密钥，而不被第三方获取
所以引入了非对称加密，客户端先与服务端建立连接，然后服务端保留自己的私钥，把公钥返回给客户端。但客户端接收公钥的过程中，第三方也可以截取公钥，甚至对公钥进行篡改
所以引入了数字证书，起初服务端在返回给客户端公钥的时候，附带了数字证书。数字证书是使用非对称加密，切私钥永远只保存在CA，且数字证书的形成是可逆的。
所以客户端在对比服务端的公钥没问题后，使用服务端的公钥非对称加密对将要使用的对称加密密钥加密后，发送给服务端，然后服务端私钥解密。
至此客户端、服务端仅彼此获得了对称加密的密钥，达成了高效安全传输数据的目的。