一文搞懂网络安全通信机制

涉及到的名词

1. HTTP与HTTPS
2. 安全套接字SSL
3. 公钥加密与私钥加密
4. 中间人攻击
5. 身份认证
6. 数字签名
7. HASH函数

今天学习了高级网络程序设计这门课，里面提到了一些自己在密码学中也会遇到的概念，写一篇博客，算是对自己基础的巩固。

假设浏览器中用户想要与服务器进行通信，它们的通信内容肯定不希望被第三方看到，否则就相当于裸奔了。

 

1.首先想一想，我们为什么需要加密？
由于HTTP的内容是明文传输的，明文数据会经过中间代理服务器，路由器，wifi，通信服务商等等多个网络节点，如果信息在传输过程中被劫持，那么传输的内容就完全暴露了。劫持者还可以篡改传输的信息并且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。
 

2.对称加密
加密的方式有两种，首先一种就是对称加密，它可以对加密后的信息进行解密，和我们日常生活中的钥匙很类似。对称加密的密钥只有一个，既可以用于加密也可以用于解密。
 

3.对通信双方用对称加密可行吗？
假如说，通信双方各自持有密钥，没有第三个人知道，那当然是可行的，除非密钥可以被破解。
但最大的问题是这个密钥怎么让传输的双方知道呢？而且没有第三个人知道？

4.什么是非对称加密
非对称加密就是有两把密钥，通常一把叫做公钥，一把叫做私钥，用公钥加密的内容必须要用私钥才可以解开，同样，私钥加密的内容只能有公钥才可以解开。
 

讲到这里，就有思路了，当客户机在向服务器发送请求的时候，我们可以让它们用公钥加密方案来进行传输，首先服务器把自己的公钥信息公开，任何用户都可以使用公钥进行加密，然后给服务器发送的信息只有服务器采用自己的私钥来解开。这就保证了信息交换的安全性，如图：

 

5.一直使用非对称加密是否可行？
鉴于非对称加密的机制，可以保证信息安全的到达服务器，可是反过来，当服务器想要给客户机发送响应信息的时候，这条路径的安全性怎么保证呢？
 

6.改良一下非对称加密是否可行？
在服务器响应客户机的时候，假如说继续使用非对称加密，那么服务器就需要存储用户的公钥，发送信息之后，用户再用自己的私钥进行解密，这种方法也可以实现安全通信，问题在于：一个用户一个公钥，那么如果成百上千万的用户公钥，如果都由服务器来存储的耗资巨大！！！

刚才介绍了对称加密，好像到目前还没有派上什么用场。
 

7.非对称加密+对称加密是否可行？
既然非对称加密耗时，那么非对称加密+对称加密结合的方式可以吗？
一定要尽量减少非对称加密的次数。

看一下接下来的设计过程：
某网站拥有用于非对称加密的公钥pk，私钥sk。
浏览器向网络服务器请求，服务器把公钥pk发送给浏览器。
浏览器随机生成一个用于对称加密的密钥Key。用公钥pk加密以后发送给服务器。
服务器拿到以后用私钥sk进行解密，得到密钥Key。
这样双方都有了对称密钥Key了，而且别人并不知道密钥Key。

很完美HTTPS基本就是采用了这种方案。如图：

 

但是这个方案是否有漏洞呢？如果你是攻击者，你会怎么攻击它呢？

 

8.中间人攻击

假如说在数据传输过程中，中间人劫持了数据，此时他的确无法得到浏览器生成的密钥Key。因为这个密钥本身就被公钥A加密了，只有服务器才有私钥sk揭开它。然而中间人却完全不需要拿到私钥sk就可以干坏事。如图：

 

过程分析：
某网站有用于非对称加密的公钥pk1，私钥sk1：
浏览器向网站服务器请求服务器把公钥pk1发送给浏览器。
接下来重点来了！！！
假如说中间有一个黑客或者叫恶意用户，或者叫中间人，他劫持到了公钥pk1，然后保存下来，把数据包中的公钥换成了自己伪造的公钥pk2，当然他也有自己的公钥对应的私钥sk2。然后把pk2发送给浏览器。
浏览器生成一个用于对称加密的密钥Key，用公钥pk2（浏览器并不知道公钥被替换了）加密后发送给了服务器。

中间人劫持到浏览器使用pk2加密的信息，使用sk2进行解密，这就拿到了浏览器的密钥key。然后神不知鬼不觉的再把用服务器的公钥pk1加密后的key发送给服务器。服务器拿到数据之后，再用自己的私钥sk1进行解密，也得到了密钥key。

中间人有了浏览器用于对称加密的密钥key以后，服务器与浏览器之间传输的数据就可以被完完全全解密了。

如图所示：

 

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥key。根本原因在哪里呢？

在于浏览器无法确认收到的公钥是不是网站自己的。因为公钥本身就是明文传输的，难道还得对公钥的传输进行加密吗？
这显然不太可能，怎么解决这个问题呢？

 

9.如何证明浏览器收到的公钥一定就是该网站的公钥呢？
其实所有证明的源头都是一条或者多条不证自明的公理，可以联想一下数学上的公理。由这些公理推导出一切。比如现实生活中，若想要证明某一个身份证号一定是小明的，可以看他的身份证，而身份证是由政府作证的。这里的公理就是政府的可信机构（比如说公安局），这个也是社会正常运作的前提条件。

那么能不能类似地有一个机构充当互联网世界的公理呢？

让它作为一切证明的源头，给网站颁发一个身份证？

当然可以，CA机构就是专门来做这件事情的。它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

10.数字证书是如何防止中间人攻击的呢？
网站在使用HTTPS之前，需要向CA机构申领一份数字证书，证书里面含有证书持有者信息，公钥信息等等。服务器把证书传输给浏览器，浏览器从证书里面获得公钥就行了。如图：

中间人想要以浏览器B的身份获得同样的信息就会很困难了。
但是中间人能否伪造或者篡改B的证书呢？

证书就如同身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书”本身的传输过程中，如何防止被篡改？

对应于生活中，办理假身份证的人，在早些年非常多，那么国家是怎么防止这种现象的呢？如何证明身份证的真实性，想明白这个，证书的工作原理也就弄清楚了。

很简单，只需要给身份证加上一个全球唯一的时间戳就好了。或者叫防伪技术。
 

11.如何防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比如对证书内容和签名是否一致就能判断是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫做数字签名。

12.如何来制作数字签名？hash函数来了！
CA机构拥有非对称加密的私钥和公钥。
CA机构对证书明文数据T进行hash。
（这里介绍一下hash函数的作用：它可以把一长串字符串hash成固定长度的数据，而且如果有人稍微改动了字符串中的一个bit，那么所得到的hash结果就有着天壤之别。)
对于hash后的值用私钥加密，得到数字签名S。
明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那么浏览器拿到服务器传来的数字证书以后，如何验证它是不是真的呢？

 

13.浏览器验证数字证书的过程？
拿到证书，得到明文T，签名S。
用CA机构的公钥对S进行解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。下面会介绍）得到S1。
用证书里面指明的hash算法对明文进行hash得到T1。
显然通过上面的步骤，T1应当等于S1，除非明文或者签名被篡改。所以此时比较S1是否等于T1，等于则表明证书可信。
 

14.中间人有可能篡改该证书吗？
假设中间人篡改了证书的原文，由于它没有CA机构的私钥，所以无法得到此时加密后的签名，无法相应地篡改签名。浏览器收到该证书后发现原文和签名解密后的值不一致，则说明证书已经被篡改。证书不可信，从而终止向服务器传送信息，防止信息泄露给中间人。既然不可能篡改，有没有办法把整个证书掉包呢？
 

15.中间人有没有可能掉包真个证书呢？

假设有一个网站B也拿到了CA机构认证的证书，他想劫持网站A的信息。于是它成为中间人拦截到了A传送给浏览器的证书，然后替换成了自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，仔细一想，这确实也会导致上文“中间人攻击”那里提到的漏洞？

但是，证书里面包含了网站A的所有信息，包括域名，浏览器把证书里的域名与自己请求的域名对比一下就知道有没有被掉包了。

这就是整个安全通信机制，了解了这些，再去学密码学里面的数字签名，身份认证，HASH函数，公钥密码学，就有的放矢，知道了它们的应用，再去理解，就会很有帮助！