• https与http的区别以及https加密原理
  • 一.什么是HTTPS
  • 二.为什么要用HTTPS替代HTTP
  • 三.HTTPS 与 HTTP 的区别
  • 四.HTTPS如何解决HTTP上述问题?
    • 1. 对称加密方案
    • 2. 非对称加密方案
    • 3. 改良的非对称加密方案
    • 4. 非对称加密+对称加密方案
    • 5. 中间人攻击
    • 6. 如何证明公钥就是要访问的网站的？
    • 7. 如何防止数字证书被篡改？（数字签名）
    • 8. 为什么制作数字签名时需要hash一次？

HTTPS 的加密机制，作为网络通信的基础知识，之前东看看，西看看，一直没有研究透彻，最近在知乎上看到了一位小哥的文章，通俗易懂，以问题的形式逐步展开，不断抛出问题，解决问题，原文见引用1，笔者只记录了其中比较重要的知识点，详情可见原文。

本篇文章主要介绍为啥 HTTPS 会比 HTTP 安全，二者之间的区别，以及HTTPS背后的加密原理是什么？

动动发财小手，点赞 + 收藏不迷路。文章较长，建议没事多看几遍，加深理解。

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。

HTTPS主要作用是：

• 1.对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;

• 2.对网站服务器进行真实身份认证。

在HTTP协议中有可能存在信息窃取或身份伪装等安全问题，
使用HTTPS通信机制可以有效地防止这些问题。

http存在的问题

• 1.通信使用明文（不加密），内容可能被窃听
• 2.无法证明报文的完整性，报文数据有可能会被篡改
• 3.不验证通信方的身份，因此有可能遭遇伪装

1. HTTP 是明文传输协议，HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，HTTPS 协议安全
2. HTTPS 相比 HTTP 更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引 HTTPS 网页
3. HTTPS 需要用到SSL证书，而 HTTP 不用
4. HTTPS 标准端口443，HTTP 标准端口80
5. HTTPS 基于传输层，HTTP 基于应用层
6. HTTPS 在浏览器显示绿色安全锁，HTTP 没有显示

先简单介绍一下两种加密算法：对称加密、非对称加密

对称加密：加密和解密使用的是同一个秘钥。

非对称加密：与对称加密不同，它有两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

注意：对称加密加密速度快，非对称加密速度慢，后面会用到这个知识点。

1. 对称加密方案

首先想到的是对称加密的方案，如果浏览器和服务器持有同一个秘钥，并且秘钥没有泄露，那么浏览器和服务器之间的通信就是安全的。但这是理想情况，通常秘钥需要在网络中传输，才可以让双方都知晓。秘钥采用明文传输，如果被别人拦截到，那么他就可以用这个秘钥解开双方传输的内容了。

2. 非对称加密方案

鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。

然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性（其实仍有漏洞，下文会说），那由单个方向传输是安全的这点你能想到什么解决方案吗？

3. 改良的非对称加密方案

我们已经理解通过一组公钥私钥，可以保证单个方向传输的安全性，那用两组公钥私钥，是否就能保证双向传输都安全了？请看下面的过程：

1. 某网站服务器拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’。
2. 浏览器把公钥B明文传输给服务器。
3. 服务器把公钥A明文给传输浏览器。
4. 之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以能保证这条数据的安全。
5. 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全。

的确可以！抛开这里面仍有的漏洞不谈（下文会讲），HTTPS的加密却没使用这种方案，为什么？很重要的原因是非对称加密算法非常耗时，而对称加密快很多。那我们能不能运用非对称加密的特性解决前面提到的对称加密公钥容易别拦截的问题呢？

4. 非对称加密+对称加密方案

既然非对称加密耗时，那非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。

当然是可以的，且非对称加密、解密各只需用一次即可。
请看一下这个过程：

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器发起请求，服务器把公钥A明文传输给浏览器。
3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
4. 服务器拿到后用私钥A’解密得到密钥X。
5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

完美！HTTPS基本就是采用了这种方案。完美？还是有漏洞的。

5. 中间人攻击

假如在网站服务器和浏览器之间进行数据传输时，有一个中间人劫持到了数据，看似中间人在拿到公钥A没有什么作用，因为他没有私钥A’，无法解密拿到流浪器的对称加密秘钥X，其实中间人在没有拿到A’的情况下，就可以与网站服务器进行通信。中间人的骚操作如下：

1. 某网站服务器有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，然后他也生成一份公钥B以及对应的私钥B’，将数据包中的公钥A替换成自己的公钥B。
4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的。

6. 如何证明公钥就是要访问的网站的？

中间人攻击的根本问题，在于浏览器无法确保拿到的公钥就是网站的。

那么 HTTPS 是如何来确保浏览器拿到的公钥一定就是网站的呢？答案就是证书颁发机构，假如从机构获取的信息都是可信，能够证明公钥就是对应网站的公钥，那么通信就是安全的。

证书颁发机构就是 CA（Certificate Authority）机构，网站在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？

7. 如何防止数字证书被篡改？（数字签名）

数字签名制作过程

1. CA 机构拥有非堆成加密的私钥和公钥
2. CA 机构对证书的明文 T 进行hash
3. 使用私钥对 hash 后的值进行加密，得到数字签名S

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

浏览器验证过程

1. 浏览器拿到证书，得到明文 T，签名 S
2. 用 CA 机构的公钥对 S 解密，得到 S’
3. 用证书里指明的 hash 算法对明文 T 进行 hash 得到 T’
4. 比较 T’ 是否等于 S’，相等，则证书没有被篡改

8. 为什么制作数字签名时需要hash一次？

最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，加密比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。

当然也有安全上的原因，这部分内容相对深一些，感兴趣的可以看这篇解答:
crypto.stackexchange.com/a/12780