记录我的愚蠢行为以及排查过程以及浅层理解https的保密原理

引子

噩兆

23年2月9日，我的平板终于回到了我的手中，百般喜悦地用了一下午，然后去造一顿汉堡王犒劳自己。

晚上回到家中，继续使用时去发现软件，游戏等不能登录，b站不能刷视频，却能看视频，太奇怪了！

迷茫

一开始我以为是网络的问题，总共试了3个wifi，都不行；以为是设置问题，恢复网络的出厂设置也不行。诡异的是，QQ能发消息，但看不见消息记录里的图片，能传文件，但稍微大一点的文件都不行，真是奇怪。于是我便准备洗漱，第二天去店里看看。

退路

但是我转念一想，马上就要开学了，好不容易在开学前拿回来，我才不想又送去维修！于是便想看看能不能用线连从电脑传文件，如果能的话，至少不会影响我学习。

曙光

连上电脑，只能查看DCIM，不能传文件进去。这时我很绝望，于是就随便看看DCIM里的照片，想找找安慰，结果我的照片有一个2022年4月的文件夹，那时我还没没买平板呢！打开一看，是我今天一些网络错误的截图，这就有趣了！

真相大白

为什么今天的截图会在2022年4月的文件夹里呢？原来是我更改了系统的时间，用来登录一些游戏。而时间一改，https就起作用了。经过学习后，我认为应该是在验证数字证书一块出现了错误，拒绝了访问，而由于不是所有地方都用的https，所以会出现有些地方能用有些地方不能用的情况。

一点点https保密原理

来自知乎顾伊凡YGY，具体的加密算法还得等到之后课堂的学习。

如果在网上以明文传输，被人截获过后信息就泄露了。防人截获很难，所以我们可以给传输的信息加密，这样就算被截获别人也不知道是什么。

对称加密

服务器生成一个密钥，以明文传给浏览器，浏览器用密钥将文件加密后再传输，服务器收到后再用密钥解密，不知道密钥的人无法解密。

问题来了，如果在一开始传输密钥时，密钥被截获了，那后来就没有秘密可言了。于是便有了非对称加密。

非对称加密

非对称是指的加密和解密不用同样的密钥，一个叫公钥，一个叫私钥。公钥加密的东西只能用私钥解开，私钥加密的东西只能用公钥解开。

服务器将公钥传给浏览器，浏览器用公钥加密文件后传给服务器，服务器再用私钥解密，这样就保证了浏览器到服务器的数据安全。但是从服务器到浏览器使用私钥加密，用公钥解密，如果从一开始截获了传输的公钥，那么从服务器到浏览器这个方向的文件就没法保证安全。

改良版非对称加密

既然普通的非对称加密能保证一个方向的数据安全，那如果来两个非对称加密是不是就能保证两个方向的安全呢？答案是是的（也许）

如果服务器生成一组公钥A和私钥A’，浏览器生成一组公钥B和私钥B’，然后彼此把自己的公钥传给对方，传输文件时再用对方的公钥加密，解密时用自己的私钥解密，这样解密用的密钥就都没传经历传输，就不会被截获，也就保证了安全。

但是实际上却并没用这种方案，为什么呢？先抛去可能出现的安全问题不谈，非对称加密非常耗时，而其在你实际使用时并不仅仅是一段传输，会有很多传输形成一条链来给你呈现内容，太耗时可不行。那我们想，对称加密没用这么耗时，哪能不呢将对称加密和非对称加密结合以做到又快又安全呢？答案是可以的。

对称与非对称结合

设想一下，服务器生成一组公钥和私钥，将公钥传输给浏览器，浏览器临时生成一个用于对称加密的密钥X用公钥将其加密，再传输给服务器，服务器再用私钥解开密钥X这样浏览器和服务器就都拥有了密钥X而且这个密钥X没有被泄露，大功告成！

但是，仍然不安全，为什么呢？这就要提到中间人攻击

中间人攻击

我们知道，传输的数据还是会被挟持，只不过内容被加密了。在上面这个情境下，黑客先劫持到服务器发送的公钥，然后将浏览器收到额公钥改为自己的公钥H，当然黑客持有对应的私钥H’。这时浏览器糊里糊涂地用公钥H加密对称密钥X再发送，又被黑客劫持，黑客再用自己的私钥H’解出密钥X，然后用之前劫持的服务器的公钥将其加密，并传回给服务器，服务器是不知道黑客干了这些事的，于是便用解出来的密钥X与浏览器进行数据传输，以为自己很安全，但密钥X已经被泄露了。对于改良版非对称加密也是一样的道理，黑客只需要准备两组公钥私钥，充当中间人，服务器发来公钥A，收着，改为发自己的公钥H1给浏览器，浏览器发来公钥B，收着，改为自己的公钥H2发给服务器，服务器给浏览器传输数据，先用自己的私钥H1’解密，然后用公钥B加密再传给浏览器，这样就得到了服务器到浏览器的数据，从浏览器到服务器是一样的。所以还是不安全。

怎么解决呢？问题出在服务器的公钥被替换了，所以要保证浏览器接受的公钥是服务器传输的公钥，也就是要一个证明，于是就出现了“数字证书”与“数字签名”。

保证公钥没被替换

数字证书

就像身份证一样，由公安局颁发给我们，证明我们是谁。“数字证书”也由相应的权威机构颁发给网站，这个权威机构就是CA机构（Certificate Authority），由他们颁发证书给网站，证书里包含了网站信息，公钥信息。一开始就传输这个证书，这样就可以证明公钥没被篡改。那么有人会问：万一证书被篡改了怎么办？所以数字证书也需要一个防伪措施，而这就是“数字签名”。

数字签名

为了生成数字签名，CA机构先生成自己的一组公钥与私钥，然后将网站的证书进行hash用以缩短长度，提高效率，接着用私钥加密签名后和证书一起组成数字证书。那浏览器如何验证真伪呢？收到数字证书后，得到明文和签名，将明文进行hash得到S，然后用CA机构的公钥对签名进行解密得到S’，如果证书没有被篡改，那么S和S’应该是相同的，如果不同就立即终止访问。这个时候可能有人问，CA机构的公钥哪里来？因为这是权威机构，所以说，他们的公钥在安装系统时或安装浏览器时就会预装这些权威机构的公钥。

而且数字证书是会更新的，这样就保证了数据传输的安全

这时回到我的经历，我修改了系统时间，而数字证书在制作时是与时间相关的，那么再验证数字证书这一步就会卡住。经我实验，只是把时间向前调几天，一两星期是没问题的，这说明调到的去年4月不在数字证书有效期内，于是便出现了那些诡异的情况。

每次传输数据都需要生成密钥不会很慢吗？

会，所以浏览器生成密钥后服务器会将其储存起来，并给他一个session ID，这样下次这个浏览器再想访问时只需要附上相应的session ID就行了，大大提高了效率。

总结

这次通过自己造成的问题简单学习了https的保密原理，还是很有收获的。

By the way 如果你因为各种原因修改了系统时间，请一定记住把它改回来，不然https就会早晚教你做人！