Nginx: https解决安全问题
https原理
1 ）http协议存在的问题
- 数据使用明文传输，可能被黑客窃取 (需要信息加密)
- 报文的完整性无法验证，可能被黑客篡改 (需要完整性校验)
- 无法验证通信双方的身份，可能被黑客伪装 (需要身份认证)
2 ) https 原理
- 所谓 https, 其实只是身披TLS/SSL协议外壳的http
- HTTPS = HTTP + TLS/SSL
解决信息被窃听问题
1 ）数据使用明文传输，可能被黑客窃取
- 明文被截获非常不安全
1.1 加密算法
- 对称加密，常见算法：DES、AES、3DES
- 非对称加密，常见算法：RSA、DSA、ECC
1.2 关于对称加密
- 客户端，服务器都用同一把，密钥如何进行协商是一个问题
- 通过互联网传输，密钥如何保证不被窃听
- 优势
- 解密效率高
- 劣势
- 密钥无法实现安全传输
- 密钥的数目难于管理
- 无法提供信息完整性校验
1.3 关于非对称加密算法
- 优势
- 服务器仅维持一个私钥即可
- 劣势
- 公钥是公开的
- 非对称加密算法加解密过程中耗费一定时间
- 公钥并不包含服务器信息，存在中间人攻击的可能性
1.4 https 加密原理
- https 混合使用对称加密和非对称加密
- 在连接建立阶段使用非对称加密算法
- 内容传输阶段使用对称加密算法
- 上图简单描述，客户端发起一个https请求
- 服务端收到请求后，蒋公钥发给客户端
- 客户端验证公钥的合法性，不合法则显示警告
- 合法，则客户端生成一个伪随机数作为一个客户端的秘钥
- 客户端使用公钥加密这个伪随机数，发送到服务器端
- 服务器使用私钥解密这个被加密的伪随机数
- 这个时候，客户端和服务器端都存在伪随机数这个秘钥了
- 整个建立连接的过程结束
- 通信的时候，客户端和服务器端都使用这个伪随机数进行加密通信
- 由此，保证了安全和效率
2 ）报文的完整性无法验证，可能被黑客篡改
- 解决报文被篡改 — 数字签名
- 确定消息的确是由发送方签名发送过来，因为别人假冒不了发送方的签名
- 能确定消息的完整性，证明数据从未被其他人篡改过
2.1 数字签名的生成
- 经过上述过程，服务端会将签名和原文返回给客户端
2.2 数字签名的校验流程
- 客户端收到签名，使用公钥进行解密出消息摘要
- 客户端将消息摘要通过哈希算法计算出消息摘要
- 客户度将两个消息摘要进行对比
- 对比不一致，报文可能会被更改
- 对比一致，则没有问题
- 保证签名不被篡改，保证报文不会被篡改
- 通过数据签名，保证报文完整性的校验
2.3 数字签名的合法性验证
- 客户端是需要使用服务器的一个公钥，对数字签名进行解密的
- 从服务器收到这样一个数字签名，如何去验证它就是这台服务器返回的
- 在中间可能会被第三者把这个数字签名返回给我的
- 也就是说数字签名，在传输的过程中，可能会被替换
- 因为服务器公钥，任何人都是可以拿到
- 因此为了解决这样一个身份验证问题，需要引入CA这样一个概念
- 也就是说这个证书是谁来颁发的
2.4 CA 证书申请过程中做的事情
- 你申请的某一个域名，一定会归属于某一个组织
- 在申请证书的时候，会将组织信息，域名信息提交给CA(证书颁发机构)
- CA会通过一些线上的方式或者是线下的方式, 对你的这些信息进行验证
- 验证你这些信息是正确之后，就颁发这样一个证书
- 这些证书通样是包含了这样一些以下信息的
- 申请者的公钥
- 申请者的组织信息和个人信息等等
- 签发机构CA的信息
- 证书的一个有效时间，证书序列号等等。
- 同时它会会包含一个数字签名
- 至此，整个组织向CA就申请了这样一个合法的证书
- 给我们的服务器配上这样一个证书之后
- 我们的客户端向服务器发起请求的时候
- 我们服务器会将申请的这样一个证书，给返回给我们的客户端
- 客户端会读取的证书中相关的一个明文信息
- 同时它会采用一定的哈希算法去计算这样一个信息摘要
- 它计算完之后，能够利用对应CA的公钥去解密这样一个签名数据，对比证书的信息摘要，如果一致，就认为，这样一个证书是合法的，反之就认为是非法的