HTTP安全与HTTPS协议

目录

Http协议的安全问题

常见的加密方式

防止窃听

单向散列函数

单向散列值的特点

加密与解密

对称加密与非对称加密

对称加密的密钥配送问题

密钥配送问题的解决 

非对称加密

前言：

公钥与私钥

非对称加密过程

混合密码系统

前言：

混合密码——加密

加密步骤

混合密码——解密

解密步骤

数字签名

前言

在数字签名技术中，有以下两种行为

数字签名过程

过程改进

 数字签名的作用

非对称加密与签名公钥私钥的角色

公钥的合法性

证书

前言

证书的使用

证书的注册和下载

HTTPS

前言

SSL/TLS

SSL/TLS工作在那一层

SSL协议功能

HTTPS的通信过程

TLS 1.2的连接

1.client Hello（方向：客户端到服务器）

2.server Hello（方向：服务器到客户端）

3.certificate（方向：服务器到客户端）

4.server key exchange（方向：服务器到客户端）

5.server Hello Done（方向：服务器到客户端）

6.client key exchange（方向：客户端到服务器）

7.change cipher spec（方向：客户端到服务器）

8.finished（方向：客户端到服务器）

9.change cipher spec（方向：服务器到客户端）

10.finished（方向：服务器到客户端）

Http协议的安全问题

前言：HTTP协议默认是采取明文传输的，因此会有很大的安全隐患

常见的提高安全性的方法：对通信内容进行加密后再进行传输

常见的加密方式

• 不可逆：单向散列函数（MD5、SHA）
• 可逆：对称加密（DES、3DES、AES等）、非对称加密（RSA）
• 其他：混合密码系统、数字签名、证书

防止窃听

理解：发送方和接收方提前约定好加密解密方式，发送方将明文进行加密后变为密文在网上传输，接收方接收到密文后进行解密得到明文

单向散列函数

前言：单向散列函数，可以根据消息内容计算出散列值，其也被称为消息摘要函数或哈希函数，输出的散列值也被称为消息摘要或指纹

注意：散列值的长度和消息的长度无关，无论消息是1bit、10M、100G，单向散列函数都会计算出固定长度的散列值，但是拿到散列值推不回去以前是什么数据内容（单向性）

单向散列值的特点

• 根据任意长度的消息，计算出固定长度的散列值
• 计算速度快，能快速计算出散列值
• 消息不同，散列值也不同（哪怕只有1bit的区别，也会产生完全不同的散列值）
• 具备单向性

加密与解密

过程：

1. 加密：使用密钥通过某种算法将明文加密成密文
2. 解密：使用密钥通过某种算法将密文转化为明文 

对称加密与非对称加密

• 对称加密：加密中的密钥和解密中的密钥是同一把密钥
• 非对称加密：加密中用到的密钥和解密中用到的密钥是不同的

对称加密的密钥配送问题

总结：在对称加密的消息传输的过程中，加密的信息和密钥容易被黑客窃听，最终导致消息的泄露

密钥配送问题的解决 

• 实现共享密钥（私下共享）
• 密钥分配中心（KDC）
• Diffie-Hellman密钥交换
• 非对称加密

非对称加密

前言：

• 在非对称加密中，密钥分为加密密钥、解密密钥两种，他们并不是同一个密钥
• 非对称加密的加密与解密速度相对于对称加密来说很慢

公钥与私钥

• 公钥：一般是公开的用于加密，因此该密钥也称为公钥，因此非对称加密称为公钥密码
• 私钥：由消息接受者自己保管的用于解密，不能公开，因此也被称为私钥

非对称加密过程

1. 由消息的接收者生成一对公钥、私钥
2. 将公钥发送给消息的发送者
3. 消息的发送者使用公钥加密信息
4. 消息接收者使用私钥解密信息

注意：

• 公钥和私钥是一一对应的，不能单独生成
• 一对公钥和私钥统称为密钥对
• 由公钥加密的密文，必须使用与公钥对应的私钥才能解密，由私钥加密的密文，必须使用与该公钥对应的私钥才能解密

混合密码系统

前言：

• 对称加密不能很好的解决密钥配送问题
• 非对称加密解密速度比较慢

含义：混合密码系统是将对称加密和非对称加密的优势相结合的方法

注意：网络上的密码通信所用的SSL/TLS都运用了混合密码系统

混合密码——加密

会话密钥：通信时随机产生的临时密钥作为对称加密的密钥，用于加密信息提高速度

加密步骤

1. 首先，消息发送者要拥有消息接收者的公钥
2. 生成会话密钥，作为对称加密的密钥加密信息
3. 用消息接受者的公钥，加密会话密钥
4. 将前两步生成的加密结果一并发给消息接收者 

混合密码——解密

解密步骤

1. 消息接收者用自己的私钥解密出会话密钥
2. 再用第一步解密出来的会话密钥解密消息

数字签名

前言

以下场景alice给bob发消息（我喜欢你）但是出现了以下情况

这里alice发的内容可能是被篡改的，或者有人伪装的，或者本来就是alice发的，但是它可以否认，那么bob如何确定这段消息的真实性呢？

注意：数字签名并不是用来数据加密的，而是要保证数据的可靠性的

在数字签名技术中，有以下两种行为

• 生成签名：由消息的发送者完成，通过“签名密钥”生成
• 验证签名：由消息的接收者完成，通过“验证密钥”来验证

数字签名过程

整个过程：

1. 发送者生成一对密钥对，同时使公钥让接收者知道
2. 发送者将要发送的消息用自己的私钥进行加密，进而变成签名
3. 发送者将消息及签名一并发送给消息接收者
4. 接收者收到消息及签名后，用发送者的公钥进行解密签名得到数据
5. 将解密的数据与消息比较，若一致则签名验证成功

注意：一般数字签名不会对整个消息进行加密解密，这样的话效率太慢 

过程改进

整个过程：

1.  发送者生成一对密钥对，同时使公钥让接收者知道
2. 发送者将消息通过单向散列函数计算出散列值
3. 发送者用自己的私钥将这个散列值进行加密得到签名
4. 发送者将消息及签名一并发送给接收者
5. 接收者用公钥解密签名得到散列值1
6. 接收者对消息进行散列计算得到散列值2
7. 接收者对比两个散列值，若散列值一致则签名验证成功

 数字签名的作用

• 确认消息的完整性
• 识别消息是否被篡改
• 防止消息发送人否认

非对称加密与签名公钥私钥的角色

• 既然是加密，那肯定是不希望别人知道我的信息，所以只有我才能解密（公钥负责加密。私钥负责解密）
• 既然是签名，那肯定不希望有人冒充我发信息，所以只有我才能签名（私钥负责签名，公钥负责验签）

公钥的合法性

前言：若遭遇了中间人攻击，那么公钥将是可以伪造的，如何验证公钥的合法性（证书）

简单理解：中间人Mallory对接收人的公钥以及发送者的密文进行了劫持，将自己的公钥发送给发送人， 接收发送人发送过来的密文并将密文篡改发送给接收人（这里公钥被篡改了）

证书

前言

说到证书首先会联想到驾驶证、毕业证、英语四六级证等等，都是由权威机构认证的，而密码学中的证书全程叫做公钥证书，跟驾驶证类似，里面有姓名、邮箱等个人信息，以及此人的公钥并由认证机构（certificate authority）施加数字签名

注意：

• CA就是能够认定"公钥确实属于此人"并能够生成数字签名的个人或组织
• 一些认证机构的公钥已经被集成到浏览器当中了

证书的使用

证书的注册和下载

HTTPS

前言

含义：HTTPS（hyperText transfer protocol secure），译为超文本传输安全协议，常称为HTTP over TLS、HTTP over SSL、HTTP Secure；其是由网景公司于1994年提出的，其是以安全为目标的HTTP通道，简单讲就是HTTP的安全版本。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

注意：

• HTTPS的默认端口号为443
• HTTPS协议需要ca申请整数，一般免费证书很少，需要交费。
• HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供了合理的防护
• SSL/TLS也可以用在其他协议上（FTP——FTPS、SMTP——SMTPS）

SSL/TLS

• SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证，使用数字签名确保完整性，使用加密确保私密性，以实现客户端和服务器之间的安全通信。该协议由两层组成：SSL记录协议和SSL握手协议
• TLS：（Transport Layer Security）传输层安全协议，前身是SSL

SSL/TLS工作在那一层

SSL协议功能

• 保证传输数据的保密性
• 保证传输数据的完整性
• 实现通信双方的互相身份认证

HTTPS的通信过程

• TCP的三次握手
• TLS的连接
• HTTP请求和响应

TLS 1.2的连接

注意：图片中省略了中间产生的一些ACK确认

1.client Hello（方向：客户端到服务器）

• 所用TLS版本号
• 支持的加密组件列表（加密组件是指所使用的加密算法及密钥长度等）
• 一个client随机数

2.server Hello（方向：服务器到客户端）

• TLS版本号
• 从客户端加密组件里面中选择好的加密组件
• 一个server随机数

3.certificate（方向：服务器到客户端）

• 服务器的公钥证书（被CA签名过的）

4.server key exchange（方向：服务器到客户端）

• 用以实现ECDHE算法（一种密钥交换算法）中的一个参数（Server Params——为了防止伪造，该参数经过了服务器私钥签名）

5.server Hello Done（方向：服务器到客户端）

• 告知客户端，协商部分结束

到目前为止，客户端和服务器通过明文共享了 client random、server random、server params（客户端使用服务器的公钥进行验证），而且客户端也拿到了服务器的公钥证书，之后客户端就开始通过浏览器内置的CA公钥来验证证书的有效性，若证书没问题就可以拿到证书里面的服务器公钥

6.client key exchange（方向：客户端到服务器）

• 用以实现ECDHE算法的另一个参数（client params）

到目前为止，客户端和服务器都含有ECDHE算法需要的两个参数：server params、client params；此时客户端和服务器都可以使用ECDHE算法；这时根据这两个参数计算出一个随机密钥串：Pre-master secret，然后结合client random、server random、Pre-master secret生成一个主密钥，最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥等（采用对称加密的方式——客户端发送的数据用客户端会话密钥加密，服务器收到该密文也用客户端会话密钥进行解密，反之亦然）

7.change cipher spec（方向：客户端到服务器）

• 告知服务器：之后的通信会采用计算出来的客户端会话密钥进行加密

8.finished（方向：客户端到服务器）

• 告知服务器，该TLS连接差不多了
• 包含连接至今全部报文的整体校验值（摘要），（用客户端会话密钥）加密后发送给服务器

注意：这次握手协商是否成功要以服务器是否能够正确解密该报文作为判断标准

9.change cipher spec（方向：服务器到客户端）

• 告知客户端：之后的通信会采用计算出来的服务器会话密钥进行加密

10.finished（方向：服务器到客户端）

• 告知客户端，该TLS连接差不多了
• 服务器将数据用服务端会话密钥加密发送给客户端

到此为止，客户端服务器都验证加密解密没问题，握手正式结束；后面开始传输（session密钥）加密的HTTP请求和响应