【HTTPS原理，架构师必读！】

微信文章：HTTPS原理，架构师必读！

 

 

（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

（2） 非对称加密使用一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

 

对称密钥算法非常适合于快速并安全地加密数据。但其缺点是，发件人和收件人必须在交换数据之前先交换机密密钥。结合使用加密数据的对称密钥算法与交换机密密钥的公钥算法可产生一种既快速又灵活的解决方案。

基于公钥的密钥交换步骤如下：

 

发件人获得收件人的公钥。

发件人创建一个随机机密密钥(在对称密钥加密中使用的单个密钥)。

发件人使用机密密钥和对称密钥算法将明文数据转换为暗文数据。

发件人使用收件人的公钥将机密密钥转换为暗文机密密钥。

发件人将暗文数据和暗文机密密钥一起发给收件人。

收件人使用其私钥将暗文机密密钥转换为明文。

收件人使用明文机密密钥将暗文数据转换为明文数据。

同样，这些步骤是由启用 PKI 的应用程序(如 Microsoft Outlook)来完成的，并且对用户来说是透明的。

 

https中 通过server 的证书来交换密钥，这个过程是明文的还是加密的？这个过程被人截获后不怕被人拿到密钥从而破解整个https？

系统中会预先安装好证书，进行https通讯前会核对公钥是否在传输中被篡改。只有不信任一些不可靠证书，通讯才能安全。

 

https:

服务器 用RSA生成公钥和私钥

把公钥放在证书里发送给客户端，私钥自己保存

客户端首先向一个权威的服务器检查证书的合法性，如果证书合法，客户端产生一段随机数，这个随机数就作为通信的密钥，我们称之为对称密钥，用公钥加密这段随机数，然后发送到服务器

服务器用密钥解密获取对称密钥，然后，双方就已对称密钥进行加密解密通信了

===============================================================

摘要：本文用图文的形式一步步还原HTTPS的设计过程，进而深入了解原理。

A在向B进行通信时，如果是以明文的方式进行通信，中间qieting者会获得双方的传输的数据hello。

HTTPS要解决如下问题：

A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容

如何做到安全

这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、。。。。

做到安全的最终目的：

A与B通信的内容，有且只有A和B有能力看到通信的真正内容

对于解决方案，很容易就想到了对消息进行加密。

A与B这样的简单通信模型，我们很容易做出选择：

 

 

这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。

只要这个密钥S不公开给第三者，同时密钥S足够安全，就可以解决通信的安全问题。

但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：

 

 如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？

答案是：Web服务器与每个客户端使用不同的对称加密算法：

 

如何确定对称加密算法

首先需要解决服务器端怎么告诉客户端该使用哪种对称加密算法问题。

可以通过协商。

 

 

 但是，你协商的过程是没有加密的，还是会被中间人拦截。那再对这个协商过程进行对称加密好了，但是对协商过程加密的加密还是没有加密，怎么办？再加密不就好了……进入了鸡生蛋蛋生鸡的问题了。

 

如何对协商过程进行加密

密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

 虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。

解决了协商加密算法的问题：使用非对称加密算法进行对称加密算法协商过程。

到这里明白了为什么HTTPS同时需要对称加密算法和非对称加密算法。

 

协商什么加密算法

要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，也不能让第三者知道这个对称加密算法是什么，该怎么解决？

使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。

到这里明白了为什么HTTPS协议握手阶段会有这么多的随机数。

 

如何得到公钥

仔细思考下，如果使用非对称加密算法，客户端A，B需要一开始就持有公钥，否则无法进行加密。

所以需要解决A，B客户端安全的获得公钥问题。

可以有以下方案：

方案1. 服务器端将公钥发送给每一个客户端

方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到

选择方案1，因为方案2又多了一次请求，还要另外处理公钥的存放问题。

 

公钥被调包了怎么办

对于方案1如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？

通过下图来理解：

 

 显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

 

使用第三方机构的公钥

公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。

使用数字证书来解决，不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。

假如下图是设计的第一版“数字证书”，证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了：

 

如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。

 话到此，我以为解决问题了。但是现实中HTTPS，还有一个数字签名的概念，我没法理解它的设计理由。

仔细思考，其实第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：

第三方机构向多家公司颁发证书的情况：

 

 客户端能解密同一家第三机构颁发的所有证书：

 最终导致其它持有同一家第三方机构证书的中间人可以进行调包：

 

 这个问题需要使用数字签名技术。

 

 .....