写在前面：
在正式了解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加锁我的内容，就只有小宇能解开了
这样，就保证了双向的通信安全！中间的坏同学们即无法阅读我们的内容，也无法篡改我们的内容了，因为会被我们发现。
目前为止，解决了内容被篡改和偷窥的问题
但是好景又不长，我们发现，这个双钥匙锁由于设计的太过复杂，导致加锁解锁的效率实在是太低了，每次传递一个纸条都要费好大的劲儿再解锁，极大的限制了我们每天交流的次数，不开心呐。
必须再想个解决方案：
单双钥匙相互配合
还记得当初那个单钥匙锁的效率就挺高的，只是因为传送钥匙的过程中容易被坏人偷看到，复制一份出来，就可以监听和篡改我们后续的通信了。
那我们能不能用双钥匙锁的安全性，把单钥匙锁的钥匙安全的传送给对方，然后再用单钥匙锁高效的进行通信呢？这样，安全性和效率就有了保证。
具体的方案为：
- 由小宇设计一个双钥匙锁，配两把钥匙C和D，然后把钥匙D给我
- 我这边准备一个单钥匙锁，配一个钥匙M，把它放在盒子里，用小宇给我的钥匙D加锁，传给小宇。
- 传递的过程中，由于钥匙D加锁的盒子只能用钥匙C解锁，所以中间人无法查看和篡改内容，最终钥匙M被安全传送到小宇那边。
- 此时，我们双方都有了钥匙M和与之对应的单钥匙锁，而且这个钥匙M谁都不知道
- 在此之后，我们用钥匙M去加密我们的信息，对方用钥匙M解密我们的信息，达成了安全通信的条件。
简单说就是，小宇给了我钥匙D，我用D加锁我的M传给小宇，之后我们用钥匙M进行对称加解锁的方式进行通信。这就是密码学中说的混合加密方式。
当然，中间的坏蛋可以在小宇给我钥匙D的时候，偷偷换成别的钥匙E，但我用E加锁我的钥匙M之后，小宇是无法用钥匙C解锁的，也就知道中间有人动了手脚，那就是有内鬼停止通信。
也就是说，中间人可以阻止我们的通信，但是却无法偷窥和篡改我们的通信内容了。
需要给自己点个赞了，居然在中间人完全不可靠的通信链路上，实现了安全的通信，这简直不可思议！
是不是觉得这个时候已经万事大吉了？
但是好景又不长。
有个又坏又聪明的坏蛋，居然也研究出来这种双钥匙锁的技术！
这些坏蛋给自己也准备了一个双钥匙锁，并且配置了两把钥匙X和Y。此时她在我们原来的通信方式上，做了这么个事情：
- 由小宇设计一个双钥匙锁，配置两把钥匙C和D，然后把钥匙D给我。
- 但是中间这个人没把钥匙D给我，而是把自己造的钥匙Y给了我（但我不知道，以为这是小宇给我的呢）
- 接下来，我这边准备一个单钥匙锁，配一个钥匙M，把它放在盒子里，用小宇给我的钥匙（其实是坏蛋给我的钥匙Y）加锁后传给小宇。
- 中间这个人收到加锁后的盒子，用自己的钥匙X轻松解了锁（因为这个锁是被Y锁的，X钥匙在坏蛋这里，所以坏蛋可以解锁），解锁后取出里面的钥匙M，坏蛋复制了一份，然后再用小宇的钥匙D加锁（第一步中坏蛋把小宇传的钥匙D私藏了）。
- 小宇用C解开了锁，得到里面的钥匙M（这个的确是我给我的，但是小宇不知道此时已经被坏人知道了，与此同时我也不知道这个事。）
- 于是我们用钥匙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协议感兴趣的各层次读者。
5260
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
