浅谈HTTPS中客户端与服务端的交互流程

浅谈HTTPS中客户端与服务端的交互流程

一、为什么会出现HTTPS?

在http传输协议中，客户端和服务端在发送和接收数据的时候不会给数据做加解密操作，因此数据都是以明文的方式传输。

可以发现，明文传输过程由于没有对数据加密将可能出现如下风险：

1. 数据泄露：中间人截取数据后直接可以看到传输内容；
2. 数据被篡改：中间人截取数据后替换为其他内容，接收端无法判断内容是否被修改过；
3. 会话劫持：由于HTTP协议不提供有效的会话管理机制，攻击者可以截获用户的会话标识（如cookie）并使用该会话标识冒充合法用户，进而进行未授权的操作

因此为了解决HTTP的安全性问题，出现了HTTPS，其在HTTP的基础上利用SSL/TLS协议对数据进行加密后再传输，保障了数据传输过程的安全。

HTTPS是HTTP的安全版本，由于HTTP不对数据进行加解密，因此HTTP更快，而HTTPS更加安全。

二、HTTPS如何保障数据的安全传输

常见的数据加密包含两种：

1. 对称加密：即双方通过同一个密钥对数据进行加解密；
2. 非对称加密：即生成一对密钥（一个公钥，一个私钥），公钥用于对数据加密，私钥用于对数据解密；

先不谈对称加密和非对称加密的好坏，我们分别假设HTTPS使用对称加密和非对接加密看会出现什么问题？

如果HTTPS仅使用对称加密算法

对称加密只需要客户端和服务端都同时知道加密的密钥即可，但服务器生成密钥后如何让客户端知晓成了一个永远无法解决的问题。

由于服务端返回秘钥的过程可能会被中间人截取，因此仍然是不安全的，仍然存在数据泄露和数据篡改的风险。要想解决这个问题，就必须先解决秘钥传输的问题。
拓展：可能有人会说，为什么不提前线下生成好秘钥并同步到客户端，这样到时候直接用秘钥加密数据传输就行了，还同步个毛的秘钥。其实主要的原因是绝大多数情况下客户端的数量是不能提前确认的，比如互联网项目上线后哪些用户哪些电脑会访问是无法确定的，只有当用户通过浏览器访问服务的时候才能明确这台电脑需要访问，因此HTTPS必须要在客户端与服务端第一次建立连接的时候先解决掉秘钥同步的问题才能进行加密传输。

如果HTTPS仅使用非对称加密算法

同理，非对接加密只需要客户端和服务端都同时知道加密的公钥和解密的私钥即可，交互流程图可以如下：

当客户端请求服务端数据时，服务端先生成一对公钥和私钥，由于公钥是公开的，所以服务端可以明目张胆的把公钥直接给到客户端，但传输过程也有可能被中间人截取，由于中间人手中有了公钥，因此在后续业务数据的加密传输过程中中间人完全可以篡改数据后利用截取的公钥对数据进行加密，并且加密后的数据服务端是无法感知的，因此如果HTTPS仅使用非对称加密只能解决数据泄露问题，无法解决数据篡改问题，同时由于私钥无法给到客户端，只使用非对称加密的情况下只能保证客户端–>服务端单项的数据加密，否则也会存在数据泄露的问题。

既然只使用一种加密方式都不行，能否在秘钥同步的问题上使用非对称加密，双方拿到秘钥后业务交互采用对称加密？

HTTPS的实现正是如此。在前面提到过，如果使用对称加密，只需要解决秘钥同步的问题即可，那如何利用非对称加密解决秘钥同步的问题呢？如下图：

由于中间人只能拿到公钥，无法对数据内容进行解密，因此客户端可以在拿到公钥后生成随机数（最终业务数据加密传输的秘钥），并利用公钥加密后传输给服务端，因为只有服务端有私钥，因此只有服务端才能知道随机数是多少，这样就解决了对称加密秘钥的同步的问题。总的来说HTTPS是在客户端和服务端在建立连接前先利用非对称加密解决秘钥同步的问题，利用的就是非对称加密中公钥加密的数据只能用私钥才能解密，而私钥一直都在服务端中，所以只要让客户端来生成需要同步的秘钥并利用公开的公钥加密，那就只有服务端才能解密出秘钥。而HTTPS最终业务数据的交互仍然使用的是对称加密。

三、听说HTTPS里有CA，那它是干啥的？

其实上面秘钥的同步过程中还可能会存在一个漏洞，简化一下上诉流程后如下图：

既然客户端对使用公钥加密后的随机数无法解密，那当服务端给客户端返回公钥时我就给你掉包，让客户端误以为接收到的是服务端返回的公钥，其实是拿到的是中间人自己生成的公钥。当客户端对生成的随机数加密后中间人再次拦截，由于自己有私钥，仍然能获得随机数。那这个问题又如何解决呢？
这个问题的核心是客户端拿到服务端返回的公钥后如何判断是否是服务端给的，此时引入了CA认证，HTTPS中利用数字证书解决了这个问题。具体解决方案如下：
当项目使用到HTTPS时需要先在本地通过工具生成非对称加密所需要的公钥和私钥对，并将公钥和其他申请信息提供给CA认证机构用于申请数字证书，CA认证机构会将申请者提供的信息以及生成的数字签名、有效期等信息统一封装成数字证书供申请者下载并放置到服务端。同时由于CA认证机构是权威机构，目前各浏览器中都默认内置可信CA的根证书签名，也就是说当客户端第一次请求服务端时服务端返回给客户端的是CA颁发的数字证书，客户端拿到证书后通过里面的数字签名去浏览器内置的CA里核查是否合法，如果数字证书被中间人修改过那CA认证机构肯定是核查为不合法的，此时浏览器就会出现如下提示：

因此当我们的项目是通过linux和windows命令自己生成的证书时，浏览器第一次都会提示这个，出现这个提示仅仅是说明浏览器拿到的数字证书中的数字签名是不能被权威CA所识别，并不代表它一定不安全，所以咱们可以通过高级选项中的继续访问来忽略这个提示。

自己生成的证书，可以解决这个弹窗吗？

当然可以，既然浏览器是通过内置的CA签名来核查是否合法进而判断是否做这个弹窗提示，那咱们完全可以将本地生成的证书提前导入到浏览器中。


当然，前提是你的用户范围是可控。很多国密CA厂商其实就是利用这个点挣钱，即他们提前生成证书，然后自己包装一款浏览器（就是在普通浏览器基础上提前导入数字证书），当项目接入时给服务端提供提前生成好的证书。这样用户使用他们的浏览器时就不会出现不安全提示了。

四、补充知识

1. 非对称加密中，**使用公钥对消息进行加密的过程被称为"加密"。**通过公钥加密的数据只能使用相应的私钥进行解密。**使用私钥对消息进行加密并生成数字签名的过程被称为"签名"。**通过私钥进行签名后，可以使用相应的公钥进行验证。
2. HTTPS是使用非对称加密算法实现秘钥的共享，实际数据传输过程使用的是对称加密。