网络安全与Https原理解析

2020-07-26  本文已影响0人  RainMi

http协议是现在网络通信中最常用的协议之一，但是由于http协议本身并没有考虑网络安全方面的问题，因此很多基于http协议的应用都存在安全隐患。因此，我们有必要了解这些安全问题及解决方法，以保证我们的应用安全稳定的运行。本文简单的介绍了网络通信中存在的常见问题和以及解决这些问题的一些技术，并简介了https协议的工作原理。

http协议存在的安全问题

http协议本身是基于tcp/ip协议的，因此传输的数据很可能会在某个网络节点被他人截获，而且http本身并没有考虑通信时的一些安全问题，因此，在使用http协议进行通信时会存在很多安全隐患，概括的来说，这些安全问题可以分为以下几种：

网络安全中常用的技术

加密算法

为了解决网络通信中的安全性问题，我们一般会使用加密算法对传输的数据进行加密。加密算法一般分为对称加密和非对称加密：

与非对称加密相比，对称加密最大的优点是执行速度快，秘钥便于管理，但是由于对称加密在加密和解密时使用的是同一个秘钥，因此如何在互联网上安全的分发秘钥是非对称加密最大的问题，虽然使用非对称加密可以对传输的内容进行加密，却无法保证秘钥在传输途中不被截获。

由于非对称加密的公钥是可以公开的，解密时所需的私钥无需再互联网上分发，因此非对称加密相对来说更加安全。且非对称加密使用的秘钥长度一般较长，破解难度相对较大，但也导致非对称加密的执行速度较慢，不适合对大量数据进行加密。

信息摘要

虽然使用加密技术能够保证解惑者无法直接读取到截获的内容，但却无法解决数据在传输过程中被篡改的问题。如果数据在传输过程中被黑客篡改，然后黑客也使用相关的加密技术对被篡改的数据进行加密，那么最终接受者在获取到数据时，依然无法判断拿取的数据是否已经遭到篡改。

我们通常使用信息摘要算法来解决数据的完整性问题。摘要算法采用单向Hash函数将需加密的明文"摘要"成一串固定位数的密文，当原文内容发生改变时，计算得到的摘要信息也会变得不同。发送者同时将原文和原文的摘要发送给接受者，接受者接收到数据后，再用同样的摘要算法对获取的原文内容进行计算，然后用得到的特征信息和发送来的特征信息进行比较，如果相同，说明数据没有被篡改。


使用信息摘要验证完整性.png

常用的信息摘要算法如下：

数字签名

虽然使用信息摘要可以保证传输数据的完整性，但是如果发送的数据和信息摘要都被黑客截获并修改，那么最终接受者仍然无法辩解获取的数据是否和最初的发送者是否一致。为了解决这个问题，就要使用数字签名技术。

使用数字签名技术可以验证数据发送方的身份，本质上也是使用的非对称加密算法：A向B发送数据，A先使用自己的私钥进行加密，得到一串数字签名，然后将原本的数据和数字签名同时发送给B，B拿到发送来的数字签名后，如果想要对数字签名进行解密，就只能使用A的公钥进行解密，如果解密成功，就说明得到的数据确实是A发送的。

数字签名通常和信息摘要技术配合使用，一般将计算出的信息摘要在进行数字签名，这样即使数据在发送途中被黑客截获，由于黑客无法得到原本发送者的私钥，也就无法对篡改后的数据进行签名，这样既保证了数据的完整性，也验证了发送者的身份。

数字证书

使用加密算法、信息摘要和数字签名技术之后，虽然数据的保密性、完整性以及同新方身份的验证都有了一定的保障，但是假如与我们进行通信的一方本身就是他人伪装的，这样前面使用的加密、信息摘要和数字签名就都没有意义了，为了解决这个问题，就要用到数字证书技术。https之所以更加安全，很大程度上是因为https协议使用了数字证书技术。

简单的来说，数字证书就如同我们的身份证一般，当我们同某个人进行交流的时候，如何确定对方确实是我们想要交流的那个人？只需要让对方出示他的身份证即可。而身份证是由政府发放的，政府作为权威机构保证身份证的正确性。因此，在数字证书技术中，也要有一个第三方来充当这个权威机构的角色，这个第三方即数字证书认证机构，简称CA。如果我们想要在应用中使用https协议，那么我们首先需要向CA机构申请数字证书，申请流程如下：

  1. 向CA机构提交服务器端的公钥、服务器的域名、公司的相关信息等数据
  2. CA机构对申请人的身份进行验证通过之后会生成一个数字证书，证书中存放着服务器端的公钥等信息，然后使用信息摘要算法生成这个证书的信息摘要，最后再使用CA机构的私钥对信息摘要进行数字签名。前面我们说过，使用信息摘要配合数字签名技术，可以保证数据的完整性和验证对方的身份。
  3. CA机构将最终生成的证书和数字签名发放给申请人，申请人将证书等数据放在服务器端。

当客户端使用https与服务器端进行通信时，客户端会先下载服务器端部署的数字证书，然后使用CA机构的公钥（CA机构的公钥通常会预先内置在浏览器或操作系统中）对证书的数字签名进行解密，得到数字证书的信息摘要。如果对数字签名解密成功，则说明客户端拿到的数字证书确实是CA机构下发给服务端的证书，这样就能判断出对方确实是我们想要通信的对象。然后客户端会使用同样的信息摘要算法计算数字证书的信息摘要，并将计算出的信息摘要同对数字签名解密得到的摘要进行对比，如果相同，说明该证书没有遭到篡改，保证了获取到的服务器端公钥是完整的。


数字证书技术.png
自签名证书

除了向CA机构申请证书意外，我们其实也可以自己来生成数字证书，常用的如使用openSSL来生成证书，但是使用自签名证书时不安全的，因为没有了可信赖的CA机构的担保，客户端即使能够拿到自签名证书，也无法证明这个证书确实是真正的服务器发送的证书，很可能在网络传输过程中这个证书已经被掉包了。

如果网站的服务端使用的时自签名证书，当我们浏览网站时，浏览器会提示访问的网站不安全，通常会让用户自行选择是否继续访问。

自签名证书通常只在程序开发调试阶段使用，不建议在生产环境中使用。

HTTPS

https协议并非一种新的协议，而是在http协议的基础上加入了SSL、TSL等协议，使得网络通信变得更加安全。

https协议通信流程

https的通信流程可以概括为以下几步：


https协议通信流程.png

  1. 客户端向服务器发送ClientHello报文以开始SSL通信，该报文中包含了客户端所用的SSL的版本及加密组件列表

  2. 服务器端向客户端发送Server Hello报文，该报文中同样包含了服务器端的SSL版本及加密组件列表

  3. 服务器端发送Certificate报文，该报文中包含了服务器端的数字证书，客户端收到数字证书后会验证该证书的真实性

  4. 服务器发送Server Hello Done报文，最初的SSL握手结束

  5. 客户端发送Client Key Exchange报文，该报文中包含了客户端生成的一种被称为Pre-master secret的随机密码串，用于在之后的http通信中进行对称加密。并且该报文已经使用第三部中获取的服务器端公钥进行加密，防止了对称加密秘钥被获取。

  6. 客户端发送Change Cipher Spec报文，告知服务端之后的通信会使用第5步中的Pre-master secret密码进行加密

  7. 客户端发送Finish报文。

  8. 服务端同样发送Change Clipher Spec报文

  9. 服务端同样发送Finish报文

  10. 客户端和服务器端都发送了Finish报文之后，SSL连接便建立完成了。之后客户端发送普通的http请求，请求的内容会用之前的Pre-master secret进行对称加密

  11. 服务器响应客户端的http请求，并返回http响应，同样会使用Pre-master secret进行对称加密。

  12. 客户端断开连接，关闭TCP通信

https的优缺点：

很明显，https最大的优点就是安全，保证了数据的保密性、完整性，验证了通信方的身份。但是，由于https加入了SSL等协议，增加了握手次数，使得网络通信变得更加复杂，相比http，网络负载可能会变慢2-100倍，而且由于在通信中加入了大量的加密解密过程，增加了cpu的负担，加重了服务器的压力。因此，是否使用https协议，需要根据实际使用场景和业务需求，进行综合的评判。

参考资料：《图解HTTP》 上野宣 著

上一篇下一篇

猜你喜欢

热点阅读