[HTTP/HTTPS] HTTP与HTTPS协议

Posted 2020-12-17 ycx95

协议

写于2020.7.14

1. HTTP

HTTP（HyperText Transfer Protocol：超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。 简单来说就是一种发布和接收 html 页面的方法，被用于在 Web 浏览器和网站服务器之间传递信息。HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。

HTTP 默认工作在 TCP 协议 80 端口，用户访问网站 http:// 打头的都是标准 HTTP 服务。

HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

1.1 HTTP安全隐患

一般http中存在如下问题：

• 请求信息明文传输，容易被窃听截取。
• 数据的完整性未校验，容易被篡改
• 没有验证对方身份，存在冒充危险

2. HTTPS的提出

为了解决上述HTTP存在的问题，HTTPS 应运而生，它被公认的三大优势有：

1. 数据加密，防窃听
2. 身份验证，防冒充
3. 完整性校验，防篡改

简单而言,可以理解HTTPS=HTTP+SSL/TLS.

HTTPS（HyperText Transfer Protocol over Secure Socket Layer：超文本传输安全协议）：一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

• 1、TCP 三次同步握手
• 2、客户端验证服务器数字证书
• 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥
• 4、SSL 安全加密隧道协商完成
• 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

2.1 SSL/TLS

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

SSL发展史（互联网加密通信）

1. 1994年NetSpace公司设计SSL协议（Secure Sockets Layout）1.0版本，但未发布。
2. 1995年NetSpace发布SSL/2.0版本，很快发现有严重漏洞
3. 1996年发布SSL/3.0版本，得到大规模应用
4. 1999年，发布了SSL升级版TLS/1.0版本，目前应用最广泛的版本
5. 2006年和2008年，发布了TLS/1.1版本和TLS/1.2版本

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

SSL/TLS 协议作用在传输层和应用层之间，对应用层数据进行加密传输。

2.2 HTTPS传输流程

HTTPS传输流程如下:

1. TLS握手阶段: 协商对称密钥$sk$
2. 数据通信阶段: 使用 $sk$ 对数据进行对称加密

$sk$ 密钥协商常见的方法有如下三种方式：

1. 基于非对称加密算法
2. 基于专用密钥交换算法，常见有 DH、ECDH 等
3. 基于共享的 secret，常见有 PSK，SRP 等

在TLS握手，数据加密通信之前，需要验证身份，验证身份的主要原因是为了解决中间人攻击问题。简单的讲，“中间人”在客户端和服务端都不知情的情况下，夹在双方之间窃听甚至篡改通信信息。比如，在 HTTPS 的握手阶段，一端向对端发送请求，对端返回自己的公钥；而一端未验证对方的身份和公钥，直接协商密钥。“中间人”看到了这个漏洞，夹在中间截获了对端的公钥，替换成了自己的公钥。正是这步“拿错了公钥”或者说“信错了对端”，使得 HTTPS 为加密（密钥协商的非对称加密和通信数据的对称加密）所做的努力全部泡汤。

2.3 HTTPS证书数据结构

在 HTTPS 中，“确保对端身份正确”即“确保拿到的公钥正确”，而在网络通信中所谓的“身份”，一般指的是通信一端的域名、IP 地址甚至是Mac 地址。所以，数字证书同时包含了通信一端的身份信息和公钥信息。

但是数字证书会在网络中传输（由被要求验证身份的一端通过网络传给另一端），这就意味着证书也可能会被窃取篡改。这个时候权威的 CA 机构就出马了，他想了个办法：加了一个“防伪标识”— 数字签名。数字签名生成过程是首先对原文作哈希，把一段不定长的文本映射成固定长度的字符空间，接着再用 CA 机构的私钥$K_{pri_CA}$对这段定长字符做加密。大大提高了整体的运算效率。

具体做法为：$signature = E(K_{pri_CA}, Hash(message))$

那数字证书长什么样呢？数字证书用于主体身份验证，数字证书=主体信息+数字签名。一张完整的数字证书包括：

• 主体必要信息：$version$, $serialNumber$, $signatureAlgorithm$, $issuer$, $validity$, $subject$, $subjectPublicKeyInfo$
• 主体的扩展信息：比如密钥标识符，证书策略
• 数字签名($signature$)：即指纹

具体抽象为：

2.4 如何使用数字证书

数字证书的使用主要包括：

• 申请证书，即需要被验证身份的一端，需要申请一份能够验证自己身份的证书
• 验证证书，即需要验证对方身份的一端，拿到证书后验证对端的身份

特别提醒，这张证书必须是由权威 CA 机构颁发的，且尚在有效期内；或者是一张信任的私人证书。

申请证书流程：

验证证书流程：接收证书的一端先对除数签名的其他部分做一次相同的哈希算法（证书中指明了哈希算法），得到这段文本的哈希映射，记作 H1；获取 CA 机构的公钥对数字签名属性做解码，得到了 CA 机构计算出的哈希映射，记作 H2。对比 H1 和 H2 两个字符串是否严格相等，若是，代表该证书的信息未被篡改，证书有效；否则，证书内容被篡改，证书无效。若证书有效，接受端会再进行对端的身份校验（验证域名），若身份验证通过，接收端会拿证书上的公钥（也是对端自己生产的非对称加密公钥）加密接下来整个 TLS 握手阶段的信息之后，发送给对端。

2.5 CA机构公钥怎么获取

提前内置。比如在windows环境下，根证书管理在 certmgr下，这些证书都有个特点：权威 CA 机构发布的根证书（Root Certificate）。根证书有以下几个特点：

• 没有上层机构再为其本身作数字签名
• 证书上的公钥即为 CA 机构发布的公钥
• 权威 CA 机构的自签证书

本地被内置了这么多的根证书，那要怎么知道我这份证书应该要用哪一个根证书来验证呢？回答：证书信任链。在信任链上有 3 类证书：根证书，中介证书和用户证书。其中，用户证书就是对端发过来的证书，或者说是用户向权威 CA 机构绑定了自己身份（主要指域名）和自己公钥的证书。中介证书可以理解由权威 CA 机构委派的代理机构签发的数字证书。

实际上，通过在证书链中（树形数据结构），从叶子节点搜索根证书，点击查看更多证书链知识，即DFS即可，具体描述如下：

1. 从用户证书开始。
2. 记“Issuer”字段的值为 i1，搜索本地证书，寻找由“Subject”为 i1 的证书。
3. 若没有找到，结束返回证书无效；否则，跳到步骤 4)。
4. 判断该证书的 Issuer 值是否等于 Subject 值。
5. 若是，则该证书是根证书，结束返回该证书；否则跳到步骤 6)。
6. 以该证书开始，跳转 2)（继续搜索）。

2.6 证书后缀代表什么

不同的后缀代表不同的涵义，主要从以下三个方面进行分析：

• 证书标准
• 证书编码格式
• 文件扩展名

首先是证书标准，数字证书的格式普遍采用的是 X.509 国际标准。

• X.509 是密码学里公钥证书的格式标准。X.509 证书已应用在包括 TLS/SSL 在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，对文档进行数字签名。

其次是证书编码格式，X.509 标准的证书文件具有不同的编码格式：PEM 和 DER。

1. PEM格式，全称Privacy Enhanced Mail，文本格式存储

• 内容：$-----BEGIN quad XXX----中间部分是BASE64编码-----END quad XXX-----结尾$

• 作用：通常，PEM 格式可以存储公钥、私钥、证书签名请求等数据。

• 查看：openssl x509 -in xxx.pem -text -noout

2. DER格式，全称Distinguished Encoding Rules，二进制存储，因此文件结构无法直接预览，只能通过如下命令查看：html openssl x509 -in xxx.der -inform der -text -noout

当然，PEM和DER格式的证书之间可以相互转换：

PEM转DER：openssl x509 -in xxx.pem -outform der -out xxx.der
DER 转为 PEM：openssl x509 -in xxx.der -inform der -outform pem -out xxx.pem

最后，根据文件扩展名，可以分为一下几类：

• 证书：存放数字证书，X.509 标准，格式可能是 PEM 或 DER。 $.crt$ $.cer$
• 密钥：用来存放一个 RSA 公钥或私钥，这类文件不是 X.509 标准，但是是 PEM 或 DER 格式。 $.key$
• 证书+密钥：可同时存放证书和 RSA 公钥。 $.pem$ $.der$ $.p12$
• 证书请求：并不是证书，而是证书签名请求。 $.csr$

2.7 HTTPS中哈希使用

哈希，键值对数据结构，通过哈希函数把一个空间映射到另一个空间。

HTTPS 的的哈希一共用在 2 个地方：

1. 证书的数字签名：其主要目的是减少非对称加密算法在长文本上的开销
2. 对称加密的Message Digest：数据通信阶段，SSL/TLS 会对原始消息（message）做一次哈希，得到该消息 message 的摘要，称为消息摘要（Message Digest）。对端接受到消息后，使用协商出来的对称加密密钥解密数据包，得到原始消息 message；接着也做一次相同的哈希算法得到摘要，对比发送过来的消息摘要和计算出的消息摘要是否一致，可以判断通信数据是否被篡改。

2.8 HTTPS通信流程

本小节通过图详细介绍了HTTPS通信流程

3. 一些概念

3.1 数字签名

将报文按双方约定的HASH算法计算得到一个固定位数的报文摘要。在数学上保证：只要改动报文中任何一位，重新计算出的报文摘要值就会与原先的值不相符。这样就保证了报文的不可更改性。将该报文摘要值用发送者的私人密钥加密，然后连同原报文一起发送给接收者，而产生的报文即称数字签名。可理解为：

1. $Hash(message)$
2. $E(K_{pri}, Hash(message))$

3.2 数字证书

参见2.3节，数字证书就是互联网通讯中标志通讯各方身份信息的一系列数据，提供了一种在Internet上验证您身份的方式，其作用类似于司机的驾驶执照或日常生活中的身份证。它是由一个由权威机构—–CA机构，又称为证书授权，（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。

HTTP响应状态码

状态码分类：

• 1XX- 信息型，服务器收到请求，需要请求者继续操作。
• 2XX- 成功型，请求成功收到，理解并处理。
• 3XX - 重定向，需要进一步的操作以完成请求。
• 4XX - 客户端错误，请求包含语法错误或无法完成请求。
• 5XX - 服务器错误，服务器在处理请求的过程中发生了错误。

常见状态码：

• 200 OK - 客户端请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 302 - 临时跳转
• 400 Bad Request - 客户端请求有语法错误，不能被服务器所理解
• 401 Unauthorized - 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
• 404 - 请求资源不存在，可能是输入了错误的URL
• 500 - 服务器内部发生了不可预期的错误
• 503 Server Unavailable - 服务器当前不能处理客户端的请求，一段时间后可能恢复正常。