【面试】【超详细】HTTPS为什么是安全的_ssl为什么安全

写在前面：

在正式了解HTTPS协议之前，我们先对齐一些密码学的基础概念：

明文：明文指的是未被加密过的原始数据。

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

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

对称加密：对称加密又叫做公钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是密钥公开（所以对称加密的缺点是秘钥安全管理困难）、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有DES、3DES、TDEA、RC5、IDEA。

• 加密过程：明文+加密算法+公钥 => 密文
• 解密过程：密文+解密算法+公钥 =>明文

其加密过程中的私钥与解密过程中用到的公钥是同一个秘钥，这也是称加密为“对称”的原因。

非对称加密：非对称加密也叫做私钥加密。非对称加密与对称加密相比，其安全性更好。

对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的秘钥，任何人都可以获得该秘钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。

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

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

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

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

由于加密和解密使用了两个不同的秘钥，这就是非对称加密中“非对称”的原因。

非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。

非对称加密中使用的主要算法有：RSA、ECC（椭圆曲线加密算法）等。

1.HTTPS是什么？

简单来说就是一种网络传输协议，我们用这个协议在网络中传输数据。

详细来说我们可以理解为HTTPS协议 = HTTP协议 + SSl/TLS协议，也就是说在HTTPS数据传输的过程中，1.需要用SSL/TLS对数据进行加密和解密，2.需要用HPPT对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netspace发明，后来各个浏览器均支持SSL，其最新版本是3.0

TLS的全称是Transport Layer Security，即安全传输层协议，最新版本的TLS是建立在SSL3.0协议规范上，是SSL3.0的后续版本。

（TLS与SSL3.0之间存在明显差别，主要是他们所支持的加密算法不同，所以TLS与SSL3.0不能互相操作。虽然TLS和SSL3.0在加密算法上不同，但是我们理解HTTPS的过程中，我们可以把SSL和TLS看做是一个协议。）

2.HTTPS和HTTP有什么区别？

1.本质的区别是：HTTPS是密文传输数据，HTTP是明文传输数据。

2.HTTPS在HTTP的基础上，解决了以下3个问题：

• HTTP通信使用明文（不加密），内容可能会被窃听。
• HTTP不验证通信方的身份，因此有可能遭遇伪装。
• HTTP无法证明报文的完整性，所以有可能已遭篡改。

其他的自行百度～

3.HTTPS是如何加密的「思想」？

只有思想，没有技术实现细节

我和小宇早恋了，上课的时候老是说话。

老师把我们的座位分的很远，我在最后一排，她在第一排，我们中间隔了很多人。

但我们还是想通过传纸条的方式进行交流。

我们中间的那些同学，虽然老想给我们搞破坏，但好在可以保证将纸条传递到位，于是我们用传纸条的方式一直偷偷的聊天。

但是好景不长，我们逐渐发现，中间有些同学特别不靠谱，出现了以下两种恶劣的行为：

• 偷看信息，拿我们的小秘密聊天，好气哦

• 篡改内容，让我们之间产生了很多误会

这还能忍吗， 必须想个办法避免才行！

单钥匙锁

 于是我发明了一个盒子，并且给这个盒子配了一把锁和一把钥匙。

这把锁与普通的锁不太一样，解锁需要钥匙，同时上锁也需要钥匙。

我把这个钥匙复制了一份给小宇，这样我每次给她写完小纸条之后，都把纸条放进盒子里，用钥匙把它锁起来。小宇收到这个盒子后，用钥匙解锁，才能拿出纸条 。同时如果小宇想给我回纸条时，也需要把纸条放在盒子里，并且用钥匙加锁，再传给我。

这样，由于中间同学没有钥匙，就无法偷窥里面的内容了，也无法篡改里面的内容，问题完美解决。

这种方案是存在漏洞的

但是好景不长，由于之前我把钥匙给小宇时，也是通过中间同学传递过去的，有个同学就偷偷复制了一份，因此她也能拿到钥匙。于是她每次收到我们传递的盒子时，就先用单钥匙解锁，偷看内容，有的时候还修改内容，然后再把纸条放回盒子里用钥匙锁起来。

单钥匙锁方案宣布失败-_-

双钥匙锁 - 防篡改

我绞尽脑汁，通宵达旦肝了几天，终于发明出来一把神奇的锁。

与这个锁相对应的有两把不同的钥匙A和B，神奇的地方在于，用钥匙A加锁，必须用钥匙B才能解锁。反过来用钥匙B加锁，必须用钥匙A才能解锁。

我对这个发明很满意，于是给这个锁起了一个名字叫双钥匙锁，那之前那个简单的锁，就叫单钥匙锁。

而双钥匙锁这种加密锁的方式，就是密码学中说的非对称加解密，之前那个单钥匙锁对应的方式，就叫对称加解密。

有了这个发明，我只需要把钥匙B给小宇，我每次写纸条的时候先用钥匙A进行加密，然后盒子到了小宇那里，她只需要用钥匙B解密，即可看到我的内容了。

这个钥匙B被人复制了一份也没有关系，坏人只能用钥匙B打开盒子偷看我的内容，但是她如果想篡改内容，必须用钥匙A才能把盒子锁住，而钥匙A一直在我手里，从来没有传递过，没人知道。

当然，坏人也可以用钥匙B把盒子锁住，但用B锁住的盒子，只能用A去解锁，所以如果小宇用自己手里的钥匙B解锁时，发现解不开，就知道内容被人篡改了。

现在，内容篡改的问题被解决了。

但是还有内容被偷看的问题还没解决，也就是内容泄漏。

双钥匙锁 - 防泄漏

我灵机一动，想到了办法。

我发现，小宇那边已经有了钥匙B，如果小宇用B去加锁，只有钥匙A能解锁，而钥匙A只有我这里有，这样小宇用钥匙B加锁的纸条，就没有任何人能看到并且篡改了！

就这这个思路，因为我们完全是对称的关系，锁亿只要小宇那边再造一个类似的神奇的锁，然后分配两把钥匙C和D。

然后小宇把钥匙D给我，自己保留钥匙C，这样只要用钥匙D加锁我的内容，就只有小宇能解开了

这样，就保证了双向的通信安全！中间的坏同学们即无法阅读我们的内容，也无法篡改我们的内容了，因为会被我们发现。

目前为止，解决了内容被篡改和偷窥的问题 

但是好景又不长，我们发现，这个双钥匙锁由于设计的太过复杂，导致加锁解锁的效率实在是太低了，每次传递一个纸条都要费好大的劲儿再解锁，极大的限制了我们每天交流的次数，不开心呐。

必须再想个解决方案：

单双钥匙相互配合

还记得当初那个单钥匙锁的效率就挺高的，只是因为传送钥匙的过程中容易被坏人偷看到，复制一份出来，就可以监听和篡改我们后续的通信了。

那我们能不能用双钥匙锁的安全性，把单钥匙锁的钥匙安全的传送给对方，然后再用单钥匙锁高效的进行通信呢？这样，安全性和效率就有了保证。

具体的方案为：

1. 由小宇设计一个双钥匙锁，配两把钥匙C和D，然后把钥匙D给我
2. 我这边准备一个单钥匙锁，配一个钥匙M，把它放在盒子里，用小宇给我的钥匙D加锁，传给小宇。
3. 传递的过程中，由于钥匙D加锁的盒子只能用钥匙C解锁，所以中间人无法查看和篡改内容，最终钥匙M被安全传送到小宇那边。
4. 此时，我们双方都有了钥匙M和与之对应的单钥匙锁，而且这个钥匙M谁都不知道
5. 在此之后，我们用钥匙M去加密我们的信息，对方用钥匙M解密我们的信息，达成了安全通信的条件。

简单说就是，小宇给了我钥匙D，我用D加锁我的M传给小宇，之后我们用钥匙M进行对称加解锁的方式进行通信。这就是密码学中说的混合加密方式。

当然，中间的坏蛋可以在小宇给我钥匙D的时候，偷偷换成别的钥匙E，但我用E加锁我的钥匙M之后，小宇是无法用钥匙C解锁的，也就知道中间有人动了手脚，那就是有内鬼停止通信。

也就是说，中间人可以阻止我们的通信，但是却无法偷窥和篡改我们的通信内容了。

需要给自己点个赞了，居然在中间人完全不可靠的通信链路上，实现了安全的通信，这简直不可思议！

是不是觉得这个时候已经万事大吉了？

但是好景又不长。

有个又坏又聪明的坏蛋，居然也研究出来这种双钥匙锁的技术！

这些坏蛋给自己也准备了一个双钥匙锁，并且配置了两把钥匙X和Y。此时她在我们原来的通信方式上，做了这么个事情：

1. 由小宇设计一个双钥匙锁，配置两把钥匙C和D，然后把钥匙D给我。
2. 但是中间这个人没把钥匙D给我，而是把自己造的钥匙Y给了我（但我不知道，以为这是小宇给我的呢）
3. 接下来，我这边准备一个单钥匙锁，配一个钥匙M，把它放在盒子里，用小宇给我的钥匙（其实是坏蛋给我的钥匙Y）加锁后传给小宇。
4. 中间这个人收到加锁后的盒子，用自己的钥匙X轻松解了锁（因为这个锁是被Y锁的，X钥匙在坏蛋这里，所以坏蛋可以解锁），解锁后取出里面的钥匙M，坏蛋复制了一份，然后再用小宇的钥匙D加锁（第一步中坏蛋把小宇传的钥匙D私藏了）。
5. 小宇用C解开了锁，得到里面的钥匙M（这个的确是我给我的，但是小宇不知道此时已经被坏人知道了，与此同时我也不知道这个事。）
6. 于是我们用钥匙M加锁解锁通信，坏蛋也同样用钥匙M来偷窥或者篡改我们的信息。

简单来说就是，我以为我是用小宇的钥匙加密，但确是坏蛋的。小宇以为是我用她的钥匙加密后传给她的M（因为她解得开），但其实是坏蛋伪装的。而我们双方都不知道这件事。

坏蛋可是真卷呐，那这肯定是不行的，我必须再找一个解决方案避免这种情况。

找人做公证

为了更好的传纸条，我开始冥思苦想，终于又找到了一个解决思路。

首先我们至少有一次（就是第一次传输的那把钥匙）通信是无法进行加密的，会被中间人看见，这个是避免不了的。

但是我们能不能做到，可以让对方看到，但却无法篡改呢？

也就是说，坏蛋传给我假钥匙Y，我可以知道这个是假的呢？

只靠我们两个，几乎是不可能的，于是我求助了班长。

我让班长也准备一个双钥匙锁，然后配置了两把钥匙J和K，并把钥匙K公开让所有人都知道。

小宇在第一次准备给我钥匙D时，不在直接给我了，而是找班长，把钥匙D放在一个盒子里，让班长用自己的钥匙J给加锁。

然后小宇把这个用钥匙J加好锁的盒子传给我，我用班长公开的钥匙K解锁盒子，就可以得到小宇的钥匙D了。

这样，中间的坏蛋可以用公开的钥匙K把盒子打开，看到小宇给我准备的钥匙D。

但是，她们却无法把自己伪造的钥匙M传给我，因为要想加锁这个盒子，必须有钥匙J才行，而钥匙J只有班长知道。

也就是说，目前这个内容，中间的坏蛋们只能看，但是不能修改了！

如果不能修改，我就能成功用小宇给我的真正的钥匙D加锁我们之后药通讯用的钥匙M，于是这个钥匙M就被安全的传给了小宇，我们之后就可以用这个谁也不知道的钥匙M，和配套的单钥匙锁，愉快的聊天了！

这个做公证的人，就是我们常说的“证书、CA机构”

啊这么多钥匙，脑子要歇菜了，我们来回顾一下：

我的单钥匙M：是用来之后我和小宇对称加锁方式通信用的，需要想办法安全传给小宇。

小宇的双钥匙CD：用来让我把M传给给她，做法是把公开的钥匙D传给我，我用钥匙D加锁我的单钥匙M，这样只有他才能用自己的保密钥匙C解开，中间人无法得知。

坏蛋的双钥匙XY：用来传给我伪造的钥匙Y，让我误以为是小宇传给我的钥匙D。

班长的双钥匙JK：用来加锁小宇的钥匙D，防止中间的坏蛋篡改这个值。

这在安全领域，分别对应对称加密和非对称加密。

单钥匙就是对称加密，对称加密的锁度很快，可以用于传输过程中的数据加密，防止中间人查看和篡改信息。但是如何将对称加密的密钥安全传递过去，这是个问题。

双钥匙就是非对称加密，非对称加密的速度慢，可以用于加密少量数据，同时也可以用于签名防止篡改。

非对称加密的密钥中，公开让别人知道的就是公钥，比如小宇的钥匙D或班长的钥匙K等。

留在自己这里不让别人知道的就是私钥，比如小宇的钥匙C或班长的钥匙J等。

既可以用私钥加密数据，公钥解密数据；也可以用公钥解密数据，私钥解密数据。

公钥加密，私钥解密，这个叫加密，目的是为了保证内容安全，因为私钥只有自己知道，是为了保证这个信息不被中间人解开。

私钥加密，公钥解密，这个叫签名，目的是为了防止内容被篡改，因为公钥所有人都知道，所有人都能看到这个信息做验证。但是如果想篡改，就必须得篡改原文信息后，用私钥加密，才能得到原来的效果，可惜私钥是不公开的。

还有一种不可逆的哈希函数，这个叫摘要，是无法解密的，不做多说。

在刚刚的环节中，首先小宇让班长用私钥J加密自己的公钥D传给我，这个是私钥加密公钥解密，这个目的是签名，防止公钥D在传输过程中被别人篡改。

我得到了公钥D之后，加密我的对称加密的密钥M，传给小宇，这是公钥加密私钥解密，这个目的是加密，为了让中间人不知道我的M是什么。

当然，我们之后的数据传输过程，也可以使用这种非对称加密的方式，但可惜，非对称加密的复杂度非常高，性能非常低，因此仅仅适合这个传递密钥M的过程，数据量小，而且只有一次。

在之后的传输，就是通过我们协商好的对称密钥M进行传输，这个也是加密，与公钥加密私钥解密的目标是一致的，只不过适合的场景不同，对称加密的效率比非对称加密高出好几个数量级。

我和小宇传纸条这个过程，就是 HTTPS 的工作原理。

（其中我的角色就是客户端，小宇是服务端，班长是 CA 机构，中间那些坏蛋同学就是传输链路，用以标明传输链路很不靠谱，有很多中间人想要搞破坏，或者偷窥我们的信息。）

只不过，HTTPS 的细节更多些，但大体的思路和我们今天传纸条是一致的。

最后，比较官方的总结就是：

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。

数据是被对称加密传输的，对称加密过程需要客户端的一个秘钥，为了确保能把该秘钥安全传输到服务器端，采用非对称加密对该秘钥进行加密传输。

总的来说就是，对数据进行对称加密，对 对称加密所要使用的秘钥 进行非对称加密传输。

• 服务端的公钥和私钥，用来进行非对称加密
• 客户端生成的随机秘钥，用来进行对称加密

---

---

想了解更多http相关知识，推荐一本书：

这本书对互联网基盘——HTTP协议进行了全面系统的介绍。

作者由HTTP协议的发展历史娓娓道来，严谨细致地剖析了HTTP协议的结构，列举诸多常见通信场景及实战案例，最后延伸到Web安全、最新技术动向等方面。

这本书的特色是在讲解的同时，辅以大量生动形象的通信图例，能更好地帮助读者深刻理解HTTP通信过程中，客户端与服务器之间的交互情况。

读者可通过这本书快速了解并掌握HTTP协议的基础，前端工程师分析抓包数据，后端工程师实现REST API、实现自己的HTTP服务器等过程中所需的HTTP相关知识点本书均有介绍。

这本书适合Web开发工程师，以及对HTTP协议感兴趣的各层次读者。

参考资料：
HTTPS理论基础及其在Android中的最佳实践

HTTPS 加密了什么内容？ - 知乎