【WEB】网络传输中的信息安全 - 加密、签名、数字证书与HTTPS

1. 概述

本篇主要是讲解讲一些安全相关的基本知识（如加密、签名、证书等），以及HTTPS如何实现的信息安全传输 不涉及复杂的底层逻辑。

在CS架构中，客户端和服务端之间的网络交互一般是使用HTTP协议来完成的，在HTTP协议的请求体和响应体中会包含一次请求的报文（或者说参数），而这些参数往往是明文传输的，有可能会被有心之人拦截，从而获取到参数中的敏感或保密的信息。因此，HTTPS(Hyper Text Transfer Protocol Secure) 应运而生，它在 HTTP（超文本传输协议）的基础上通过传输加密和身份认证保证了传输过程的安全性。

2. 网络传输安全

2.1.什么是中间人攻击

在开篇中提到了HTTP协议是不安全的，这种不安全主要体现在两个方面：信息泄露、信息伪造，在客户端和服务器中间，有一个中间人可以接收到响应传输的信息。

• 信息泄露：中间人可以获取到传输过程中的敏感、保密信息。
• 信息伪造：中间人可以将自己伪造成客户端或服务器，发送虚假信息。

上述的情况，一般会被称为中间人攻击，在日常使用网络的过程中，如果没有注意网络的安全，例如：使用了未知的公用WiFi、使用了不安全的网络设备、木马感染、DNS劫持等，都容易遭到中间人攻击。

---

显然，我们不能只通过用户自行注意网络的使用来解决信息传输安全问题，所以我们应该建立安全的传输机制，涉及到两个重要的概念：加密和签名。

2.2. 加密和签名

2.2.1.加密算法

所谓加密，就是将原有明文信息通过加密算法转换成为一串没有确认含义，无法识别的字符，也就是密文信息，这样即使信息泄露出去，获取信息的人也无法识别其含义，起到保密的效果。

通过是否能将密文信息重新解密成明文信息的维度，将加密算法区分为：单向加密算法和双向加密算法。

• 单向加密算法：无法解密，常见的算法是MD5和SHA256，一般运用在生成摘要信息或保存用户密码等场景。
• 双向加密算法：可以解密，最常见的算法是AES与RSA，一般运用在信息传输中，保证信息传输的安全性。

在双向加密算法中，要达成解密的效果，会在加密和解密时使用到密钥，通过加解密是否使用同一个密钥，将双向加密算法区分为：对称加密算法和非对称加密算法。

• 对称加密：通过一把密钥加密和解密，客户端和服务端都持有相同的密钥。
• 非对称加密：将密钥分为公钥和私钥，公钥加密时只能用私钥解密，反之，私钥加密时，只能用公钥解密。两种加密方式使用场景不用，其中公钥加密是将信息转换为密文，防止信息泄露，而私钥加密是用于签名，用于身份认证（即确认是某个人、某个公司机构等发送的信息）。

对比一下对称加密和非对称加密，对称加密速度快，密钥安全性不高。非对称加密速度相对较慢，通过对外只暴露公钥的方式增强了密钥的安全性，同时由于其特性，还可以做身份认证。

---

说到这里，提一嘴脱敏，加密和脱敏容易混淆。
加密是将明文信息转换为密文信息，密文中无法提炼出有用的信息。
脱敏则是对原有的明文信息做部分修改覆盖，避免敏感信息暴露的同时，还保留了一部分有用的业务信息，常见的就是姓名、身份证、手机号等数据通过 * 替换掉中间一部分数据。

2.2.2.摘要

对传输的信息做加密是为了防止信息泄露，那么摘要和签名就是为了防止信息伪造。

所谓摘要，就是一串和内容相关的哈希值，通过单向加密算法，如SHA256，将原文生成生成一个256位的二进制串。只要原文发生了任何改动，这个摘要信息都将会完全不同。

通过这样的特性，在不需要对原文进行逐字逐句对比的情况下，快速的验证原文是否被修改了。
在一些开源软件的下载页面，除了源码包之外，还有摘要包下载，用户可以下载之后，用样的算法做摘要，通过比较摘要的值确认源码是否被修改。

---

当然，除了被有心人篡改了源码内容之外，摘要验证往往还会用于校验文件的完整性。（例如因为网络等原因导致源文件没有下载完整的情况）

2.2.3.签名

签名是一种更高级的安全措施，可以同时验证信息完整性和信息真实性，它是在摘要的基础上，通过非对称加密算法对摘要信息做了一次加密。

所谓信息的真实性，就是指信息来源于官方发布而不是由第三方篡改的。
拿上面的例子来说，由于SHA256是通用算法，第三方拿到源码包并篡改后，重新生成了一个摘要包，将这两个包都放在伪造的网站上，用户下载之后无法验证来源的真实性。在这种场景下，官方可以通过非对称加密算法，使用私钥对摘要做加密，用户下载了签名之后，通过官方发布的公钥进行解密，再将原始摘要与新生成的摘要做对比，以此来确认下载的源码的真实性。

不同的网站可能会使用不同的加解密算法，细节上有细微的差异，但大体的流程都如上图所示。在Maven的官网中，下载界面就可以下载这三种包：

通过上面的verify the signature以及KEYS可以获取到校验方法及对应的公钥。

2.3.数字证书

2.3.1.证书的使用

数字证书是一种包含了公钥、所属组织信息、证书颁发机构、证书签名等信息的数字文件。
如果做过金融支付相关的业务，对接过银行或者三方支付平台的话，或多或少都会接触当数字证书。
这样的证书，多数情况是的就是通过操作系统生成的一个自签名的证书文件。我们在按照接口文档写完代码之后，下一步就是互相交换数字证书，在后续的接口调用过程中，会使用到对方的数字证书做签名验证，防止支付中的关键信息被中间人篡改。

而在CS架构中，客户端想要获取证书，在第一次访问网站时会从服务器中拉取证书，这种情况下，自签名的数字证书无法保证通信的安全性。

在这种情况下，要保证信息传输的安全，客户端就需要有一种机制可以验证证书的合法性。
这种机制就是在当两方无法确认对方的身份时，引入一个权威的第三方做身份确认，而这里的第三方指的就是根证书。

2.3.2.根证书

所谓的根证书，就是各个权威的CA（Certificate Authority）机构的自签名证书，它们会预装在操作系统中的证书，用于浏览器或其他类型的客户端校验服务器提供的证书合法性。国内常见的CA机构有：CFCA、BJCA、SHECA等。

打开谷歌浏览器的证书管理，可以看到这样的内容：

点进去之后就可以看到预装的根证书了

企业机构可以通过权威的CA机构申请证书，将证书安装到服务器上，这样客户端就能校验出这个正式是否合法了。

2.3.3.证书链

处于根证书安全、管理的灵活性、业务需要等原因，企业申请的证书往往不是由根证书直接签发的，而是由一个层次关系：

这样的层次关系叫做证书链，在客户端访问服务器的时候，客户端会获取到服务器返回的证书链，再通过递归的方式一层层的向上校验，直到根证书校验通过。

2.4.HTTPS

在使用HTTPS协议时，客户端会通过TLS与服务器握手尝试建立一个安全连接通道，后续的请求都是通过这个通道来执行的。

这种设计方式既利用了非对称加密的安全性，又利用了对称加密的性能。后续的数据传输都是通过客户端生成的对称密码来进行加密和签名的。