网络传输安全及HTTPS原理分析
网络传输安全问题分析
一直知道http协议是不安全的明文数据，https是基于ssl加密的安全的通信方式。但是后来又知道了https也可以抓包，也就是说并不是绝对安全的，但是没有仔细研究。直到前阵子打算自己写个升级后台，第一关就是服务器安全和权限控制，才去深入地了解一下网络安全这块的内容，在此记录一下自己的理解方式。
我们知道信息安全大致可以分为存储安全、使用安全、传输安全，其中传输安全是面临威胁最直接的一种。因为在信息传输过程中，信息交换双方是开放的 、传输的链路是不确定的、双方的身份也是未知的，非常容易遭受各种形式的攻击。比如，信息窃取，信息篡改，身份伪装（也叫中间人攻击 Middle Attack）等，接下来我们从最原始的通信模式开始，通过安全威胁的方式及其解决办法的展开讨论，来解释HTTPS通信过程和安全方案。
1.明文传输
服务器和客户端都以明文的方式进行通信。
明文传输模式
明文传输模式，数据一旦在链路上被人截取，比如通过代理的模式，信息直接就泄露了，并且还可能被篡改。
明文传输漏洞
所以我们需要对明文进行加密。
2.对称加密
对称加密即加密和解密使用同一个秘钥，常见的对称加密有DES、DES3算法等，其示意图如下
对称加密示意
3.对称加密传输
服务器和客户端要进行对称加密方式的密文通信，首先要交换加密秘钥，否则另外一方无法解密信息。
对称加密传输
在这种模式下面，虽然之后的信息交换是以加密的方式进行的，但是在秘钥交换的时候，必须是明文的，一旦秘钥被窃取，后续的加密数传输，也就等同于明文传输了，如下：
对称加密传输漏洞
4.非对称加密
对称加密方式，无法解决秘钥传输问题，也因此无法满足信息加密传输的需求，所以后来密码学上又发展出了非对称加密算法。在非对称加密算法中，加密和解密使用不同的秘钥，用其中一个秘钥加密的数据，只能用另外一个解密。这种特性，使得其中一个秘钥可以对外公开，也称作公钥，另一个就称作私钥。信息经过公钥加密，只有私钥持有者才解密，这样就解决了秘钥传输的问题。对称加密的过程如下：
非对称加密示意
5.单向非对称加密传输
为了解决对称加密传输中，秘钥公开传输带来的安全漏洞，我们采用非对称加密算法对信息进行加密后传输。先考虑只有一端有非对称加密的情况，比如服务端，那么传输的过程如下。
单项非对称加密示意
可以看到，为了让客户端能够理解服务端返回的信息，服务端必须要使用私钥对返回的信息进行加密，因为服务端的公钥是明文传输的，服务端返回的数据是可以被解密和窃取的，过程如下：
单项非对称加密传输漏洞
在因为服务端的公钥是可以获取的，所以服务端返回的数据，如果用自己的私钥加密和明文传输是没有区别的。如果在客户端对数据进行加密，所面临的问题也是一样的，所以单向非对称加密只能满足单向加密传输的需求。
6.双向非对称加密
假如通信双方都各持有一对加密秘钥，并要求接收的数据都使用自己公钥进行加密，那么就形成了双向非对称加密。
双向非对称加密示意
在这种通信模式下，即使双方的公钥和加密信息被第三者拦截，因为第三者没有私钥，因此不会造成信息泄露，至此我们彻底解决了信息窃取的安全问题。但是，是否这种传输模式已经没有问题了呢，并非如此。我们从一开始到现在讨论的都是信息窃取的问题，这种模式虽然已经解决了这个问题，但是并没有解决身份伪装的问题。比如，假如一开始服务器通信的就是第三方伪装的客户端，那么通信过程就依然完全暴露在第三方的视野中，如下:
双向非对称加密通信问题
同样，客户端可能遭遇第三者伪装的服务端的钓鱼通信。
7. 身份证明问题
现在我们知道通信双方都需要一种方法，能够证明自己的身份，来解决第三者伪装攻击的问题。那么有没有这种办法或者技术手段呢，这貌似无从下手。
我们来抽象一下问题，假如A与B要进行通信，B具有不确定性，即任何能够证明自己身份合法的对象，都可以与A通信。因此A事先对于B的身份没有任何已知的信息，完全依赖B在通信时提供的凭证F。那么问题变成了：提供怎样的凭证F能够证明B是合法的呢？
假设凭证F要求包含最小的信息集合为F={F1,F2,F3,...,Fn},我们要求对于任意 Fi 属于 F都是合法的就可以证明F合法。那么怎么证明信息Fi是合法的呢？答案是无解。因为A对B没有任何已知的信息，即使F1再进行拆分，它依赖的信息，依然无法形成凭证，只能将证明问题进行转移。因此无论提供怎样的凭证F，都无法让B直接对A证明自身的合法。
因此我们需要引入一个A信赖的第三方作为公证，来验证B的身份。因为这个A是抽象的通信端，因此A的问题B也同样需要解决，那么这个第三方公证，需要被AB同时信任。
8. 即时公证的双向非对称加密传输
在即时公正的双向非对称加密传输过程中，通信双方要事先在公正方处进行身份和公钥注册。在通信开始之前，通信双方首先要与公正方交换公钥，以便后续加密认证过程，其次请求双方的公钥和身份信息，然后申请公证，如果公证成功，则认可对方的公钥，后续使用公钥进行双方通信。
公证双向非对称加密传输
到此为止，通信模式好像接近完善了，但是其实还有几个问题：
（1）公证方身份伪装问题
通信双方和公正方依然存在公钥交换过程，也就是公正方也可能是伪装的，所谓的身份认证问题，只是从认证通信对方，转移到了认证公正方这里，并没有得到解决，示意如下:
公正方伪装漏洞
既然这个问题是由公正方与通信方的公钥交换引起的，那我们是否可以取消这个过程呢?答案是肯定的,因为公正方本身就需要是一个权威的机构，而不像通信方一样具有不确定性。事实上，现在的浏览器和服务端程序，都内置了公正方的信息，或者依赖系统信任的公正方的信息。
这里会有一个潜在的问题，假如这些内置的信息，被篡改了，那么身份伪装是不是就依然可行了呢？是这样的，所谓的https抓包正是基于这个原理，但是这并不代表https是不安全的通信协议，因为浏览器和服务器系统的通信证书是可以管控的，正常用户使用的客户端，肯定依赖的是正确的公正方信息，那么在这个条件下，通信的过程就是安全的。请注意，这里有两个对象，容易让人混淆。我们说安全是针对正常的用户而言的，而通信模式漏洞，是在恶意攻击情况下，针对通信端程序而言的，因此在网络通信程序的设计上，不能够因为使用了HTTPS，而对通信安全掉以轻心，还是要做好数据审查和权限管理。
（2） 即时公证的并发和成本问题
公正方在通信过程中，承担了中间人的角色，在真实的网络请求中，会遇到并发和成本问题。因此我们考虑将依赖公正方的即时的认证过程，变成通信双方的离线的校验过程。那么怎么设计呢？
在即时公正的模式下，通信双方的认证信息是存储在公正方这里的，这是导致需要实时访问的根本原因。那么我们能不能将身份信息，加以处理，带上我们公证方的认证结果，做成凭据，再还给通信方，只要提供这个凭据就对方就能通过认证呢。
那么这个凭据要求：
- 包含了公正方和注册方的身份信息
- 能够证明是公正方颁布，而无法伪造
- 颁布之后，凭证的内容无法修改
这个公正方叫做CA机构，而这个凭据就叫CA证书。
（3）加密效率问题
非对称加密虽然能解决秘钥传输问题，单它有个弊端，就是加解密计算量大，效率低。因此不适用于频繁的、大数据量的信息交换。因此我们在完成身份认证之后，不能一直使用非对称加密进行通信，而是协商一个堆成加密的秘钥，使用对称加密交换信息。
HTTPS通信原理介绍
待续。
