Linux网络-HTTPS协议

HTTPS

• 零、前言
• 一、HTTPS协议
• 二、加密方式
• 三、中间人攻击
• 四、PKI
• 五、数字签名技术

零、前言

本章是继HTTP协议后的一篇关于HTTPS协议的拓展

一、HTTPS协议

• 概念及介绍：

1. HTTP请求无论是用GET方法还是POST都是不安全的，使用HTTP协议传输的数据都是在网络里面裸奔（可以通过抓包工具抓到）
2. HTTPS是身披SSL外壳的HTTP，是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，对数据包进行加密和解密
3. HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性

注：TLS是传输层加密协议，前身是SSL协议，有时候两者不区分

二、加密方式

加密的方式可以分为对称加密和非对称加密

• 对称加密和非对称加密：

1. 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密
2. 采用公钥和私钥来的加密方法，用公钥进行加密，用私钥进行解密，这种加密方法称为非对称加密（公钥是进行公开的，私钥是自己进行私有的）

• 示图：

• 注意：

1. 在数据传输的过程中，使用对称加密解密比非对称加密解密的网络通信效率高
2. 对于非对称式加密的私钥解密只能保证单向通信的安全，也就是说，如果想要双方建立安全的信道需要两对公钥和私钥
3. 对称加密的效率更高，但双方要进行对称加密通信，就需要双方进行协商秘钥：如果进行协商秘钥时，使用明文进行协商的话就没有进行加密的必要了；而对协商秘钥的内容进行加密也不太适合，毕竟对方没有拿到秘钥无法进行解密
4. 所以要高效安全的网络通信，使用非对称式加密进行秘钥协商，使用对称式加密进行数据传输

• 秘钥协商过程：

• 注意：

1. server端发送公钥的时候，网段中的主机都可以收到，但是私钥只有server端有，其他人都只有公钥，client端发送的报文只有私钥可以解密，也就保证了client端数据到server端方向的安全性
2. 上述秘钥协商虽然没什么问题，但是依旧存在不安全的问题，例如中间人攻击问题

三、中间人攻击

• 概念：

所谓中间人攻击就是服务器传递给客户端的公钥可能被攻击者替换，这样安全性就荡然无存了

• 示图：

• 上图流程：

1. 客户端向服务器端发起连接请求，期望获取服务器的公钥，攻击者劫持了这个请求
2. 攻击者然后再向服务器端发送请求，服务器生成密钥对，将公钥发送给客户端，实际上是发送给攻击者
3. 攻击者自己生成一对密钥对，然后将攻击者的公钥发送给客户端
4. 客户端通过攻击者的公钥加密密钥块并发送给服务器对称秘钥，实际上是发送给攻击者
5. 攻击者用自己的私钥解密了密钥块D，再用服务器的公钥加密后发送给服务器端
6. 服务器端接收到请求后，用自己的私钥解密出密钥块D
7. 客户端使用密钥块加密数据并发送给服务器端，实际上是发送给攻击者
8. 攻击者使用密钥块解密出明文，客户端相当于泄露了隐私，攻击者使用密钥块加密明文后发送给服务器
9. 服务器使用密钥块加密数据并发送给攻击者，攻击者使用密钥块解密出明文数据，此时客户端和服务器端的加密数据被成功破解

• 解决措施：

1. 在TLS/SSL协议中，客户端无法确认服务器端的真实身份，客户端访问https://www.example.com，接收到一个服务器公钥，但是无法确认公钥是不是真正属于http://www.example.com。公钥只是一串数字，需要有一种手段去认证公钥的真正主人，解决方案就是PKI
2. 公开密钥算法中，所有的网络通信都会存在中间人攻击，这是务必要记住的一点，在HTTPS协议中必须引入PKI技术解决身份验证的问题，PKI技术的核心就是证书
3. 简单地说，PKI技术能够确保客户端接收到的服务器公钥（比如http://www.example.com网站的公钥）确实是http://www.example.com网站的公钥

四、PKI

• 示例解释：

1. 在中国，某个公民去银行办理业务，银行首先需要确认公民的身份，可是公民无法自己证明自己
2. 国家的管理机构想到了一个好的方法，每个公民都要遵纪守法，为了确认公民的身份，国家给每个公民发了一张身份证，身份证上包括公民的姓名、年龄、地址、身份证号等关键信息
3. 公民去银行办理业务的时候，使用身份证证明自己的身份，可为什么银行一定要信任身份证呢？因为身份证是国家签发的，身份证具有法律效应，银行机构作为这个法治国家的一部分，必须信任国家，这是基础条件，所有的信任都有一个基本前提
4. 但是身份证只是一张卡片，卡片可能被伪造（想到中间人攻击了吗？），实际上身份证的签署有复杂的技术基础，银行有专门的技术去校验身份证的真伪，总结来说，银行充分信任国家这个监管机构，也信任国家签发的身份证，一旦公民和身份证确认是一致的，等于是确认了公民的真实身份
5. 如果公民拿着中国的身份证去国外银行办理业务，国外银行是不能进行身份认证的，原因就在于国外银行只信任本国的法律，没有义务信任别国的制度，这也进一步证明信任是相对的，是建立在一定基础上的

• PKI主要部分组成：

1. 服务器实体：公民相当于服务器实体，服务器实体就是HTTPS网站的提供者
2. 客户端（浏览器）：银行相当于客户端（浏览器）
3. CA机构：在HTTPS中，国家相当于CA机构，CA机构会向服务器实体签发一张证书（身份证）。和身份证一样，CA机构会签发一张证书（可以理解为就是一张身份证），证书中包含了一些关键信息，比如服务器的主机、服务器的公钥

注：浏览器基于对CA机构的信任，有方法校验服务器的身份，和身份证不一样的是，互联网上的证书就是普普通通的文件，客户端如何校验证书呢？如何确认用户的身份呢（银行校验身份证的技术）？解决方案就是数字签名技术

五、数字签名技术

• 申请证书流程：

1. 服务器实体希望发布一个HTTPS网站（https://www.example.com）
2. 服务器实体生成公开密钥算法的一对密钥，比如一对RSA密钥
3. 服务器实体生成一个CSR（Cerificate Signing Request）文件，CSR是证书签名请求文件，其中包含的重要信息是网站的域名（http://www.example.com）、RSA密钥对的公钥、营业执照，然后将CSR文件发送给CA机构申请证书
4. CA机构收到CSR文件后，核实申请者的身份，最简单的核实就是校验域名（http://www.example.com）的拥有者是不是证书申请者
5. 一旦审核成功，CA机构用自己的密钥对（比如ECDSA密钥对）的私钥签名CSR文件的内容得到签名值，然后将签名值附在CSR文件后面得到证书文件，证书文件中除了包含申请者的信息，还包括CA机构的信息，比如包括CA机构采用的签名算法（比如ECDSA签名算法）、CA机构的名称
6. 最终CA机构将证书文件发送给服务器实体

• 客户端验证证书流程：

1. 浏览器向服务器端发送连接请求https://www.example.com
2. 服务器接收到请求后，将证书文件和RSA密钥对的公钥发送给浏览器
3. 浏览器接收到证书文件，从中判断出是某CA机构签发的证书，并且知道了证书签名算法是ECDSA算法，由于浏览器内置了该CA机构的根证书，根证书包含了CA机构的ECDSA公钥，用于验证签名
4. 浏览器一旦验证签名成功，代表该证书确实是合法CA机构签发的
5. 浏览器接着校验证书申请者的身份，从证书中取出RSA公钥（注意不是CA机构的公钥）和主机名，假设证书包含的主机也是http://www.example.com，且连接阶段接收到的RSA公钥等同于证书中包含的RSA公钥，则表示浏览器成功校验了服务器的身份，连接的服务器确实是http://www.example.com主机的拥有者。一旦服务器身份校验成功，接下来就是进行密钥协商，协商出密钥块
6. 密钥协商算法大致就是：客户端生成一个随机值，这个值必须是随机的，不能被攻击者猜出，这个值就是会话密钥
7. 客户端使用服务器RSA密钥对的公钥加密会话密钥，并发送给服务器端，由于攻击者没有服务器的私钥，所以无法解密会话密钥
8. 服务器端用它的私钥解密出会话密钥
9. 至此双方完成连接，接下来服务器端和客户端可以使用对称加密算法和会话密钥加密解密数据

注：由于中间人无法拥有CA机构的私钥，当对认证证书内容进行篡改时，接收端验证CA证书时使用CA机构的公钥解密比对就会出错，也就是身份认证失败，从而认定是中间人发送的数据

未经允许不得转载：木盒主机 » Linux网络-HTTPS协议