如何简单的从宏观上理解HTTP/HTTPS的加密过程？

本文主要是本身在学网络这一块的一些我的理解，主要是宏观上的一些解释，旨在对整个过程有个大概的了解。 咱们知道HTTP都是明文传输的，因此通讯信息容易被拦截，所以出现了不少手段来保证信息的安全。

HTTP时代的加密

名词解释

对称加密： 加密和解密都是用同一个秘钥。速度快。

非对称加密： 分公钥和私钥。公钥是公开的，私钥只有本身知道。公钥加密的只能用私钥解密，私钥加密只能用公钥解密。因此叫非对称加密。

加密和签名： 借用知乎的一个回答。

加密： 既然是加密，那确定是不但愿别人知道个人消息，因此只有我才能解密，所以是公钥加密，私钥解密。

签名： 既然是签名，那确定不但愿别人冒充我，因此只有我才能签名，所以是私钥加密，公钥解密。

加密方法：

• 使用对称加密，须要传输私钥。存在问题：私钥被拦截。
• 使用非对称加密，须要传输公钥。 存在问题： 1. 公钥被拦截；2.加密速度太慢

针对加密速度： 使用非对称传输对称加密的秘钥，而后用对称加密来通讯。

主要流程以下：

1. 获取双方的公钥
2. 使用公钥传输私钥
3. 使用私钥进行对称加密，进行通讯
复制代码

针对公钥被拦截：引入CA和数字证书。

CA至关于现实中的公证处，简单理解就是CA颁发给服务端一个数字证书，而浏览器能够鉴别这个证书是否是真的。能够从数字证书中得到服务端的公钥。

首先服务端经过CA生成数字证书（含数字签名）：

服务端将数字证书传递给客户端，客户端验证消息是否被篡改的过程：

经过上述过程，便安全获取了服务端的公钥。完成了步骤1. 整个过程以下：

HTTPS时代的加密

TLS握手：

使用RSA加密方式：

1. 客户端给服务端传递随机数X
2. 服务端给客户端传递一个随机数Y和数字证书
3. 客户端根据数字证书获得服务端公钥，并用公钥加密传递给服务端Z。
4. 服务端解密得到Z.
5. 服务端和客户端都有三个参数X,Y,Z。根据同一个加密算法F(X,Y,Z)得到对称加密的秘钥key。

但X,Y,Z均为明文传输，X,Y,Z被hacker拿到后，他也能够生成一样对称加密的秘钥key。

目前主流的是ECDHE加密方式：

1. 客户端给服务端传递随机数X
2. 服务端给客户端传递一个随机数Y
3. 服务端继续给客户端传递服务端参数A。
4. 客户端传递客户端参数B给服务端，以上均为明文传输。
5. 此时客户端和服务端都有四个参数X,Y,A,B。经过算法生成一个参数Z, 在由X,Y,Z 生成对称加密的秘钥key。

以前的疑惑是既然X,Y,A,B均为明文传输，hacker拦截后也同样能够经过算法生成key啊，不就不安全了吗？

这就要讲到DH算法了，DH，DHE，ECDHE算法能够理解为不断的优化，本质上仍是同样的。为何这个过程是安全的，关键就在于A,B。

DH算法是服务端根据参数a, 生成A = F(a). 客户端根据参数b，生成B = F(b)。并且即便hacker知道A，也知道算法F(),可是没法推算出a的值，同理b的值也没法获取。

该算法存在如下关系, 生成Z：

Z = A * b = B * a 。

明文传递有X, Y, A, B.

由于hacker没法获取a,b的值，因此生成的Z是安全的，所以经过X,Y,Z生成的对称秘钥也是安全的。

附上详细的RSA过程：

详细的ECDHE

参考文章

• 一个故事讲完https
• 彻底吃透 TLS/SSL
• TLS握手协议分析与理解——某HTTPS请求流量包分析