HTTP/HTTPS

Hyper Text Transfer

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是⼀种⽤于分布式、协作式和 超媒体信息系统的 应用层协议 （TCP/UDP为运输层协议）

HTTP协议：客户端和服务器在进行通讯时，发送的HTTP请求和响应应当具有的特定的格式

HTTP请求报文

HTTP请求报文是客户端（通常是Web浏览器）与服务器之间通信的基础。主要由三个部分组成：请求行 (Request Line)，请求头 (Request Headers)，请求正文 (Request Body)

不同于一些底层网络协议（如TCP/IP），后者可能会利用固定长度或特定位置的比特/字节来定义和区分字段，HTTP作为一种应用层协议，采用的是基于文本的格式，使得它更加灵活和易于人类阅读

请求行 (Request Line)包含三个字段：请求方法(如GET、POST等)、请求URI 和 HTTP版本

请求头 (Request Headers)：请求头用于描述请求的元数据，指导服务器如何处理和优化响应

请求正文 (Request Body) 中包含了要的数据，主要在POST、PUT等请求中使用。也可用来传输大量的数据，比如文件上传

常见请求头字段

HTTP请求头（Request Headers）包含了客户端发送给服务器的关于请求、客户端本身以及所需响应的信息。这些头部字段帮助服务器理解请求的具体细节，并据此做出适当的响应

1. Host：指定请求的目标主机名和端口号，这是HTTP/1.1强制要求的字段，用于支持虚拟主机服务

2. User-Agent： 提供了发起请求的用户代理（通常是浏览器）的信息，包括名称、版本号和其他属性。这有助于服务器根据不同的客户端特性定制响应内容

3. Accept：列出了客户端能够理解的内容类型（MIME类型，如text/html, application/json等），让服务器知道客户端期望接收的数据格式

4. Accept-Language：表示客户端偏好的自然语言，帮助服务器选择合适的语言版本返回给客户端

5. Accept-Encoding：客户端支持的内容编码方式（如gzip, deflate），允许服务器在传输时对数据进行压缩以节省带宽。

6. Connection：控制网络连接的行为，如keep-alive保持连接打开以便于后续请求，或close指示服务器立即关闭连接。

7. Content-Type：当使用POST或PUT方法时，指定请求体中的媒体类型，告知服务器客户端发送的数据格式。

8. Content-Length：标识请求体的大小（以字节为单位），仅当有请求体时适用

9. Authorization：包含认证凭据，用于验证客户端的身份，通常与Base64编码后的用户名和密码一起使用

10. Cookie：包含之前由服务器通过Set-Cookie头设置的cookie信息，使客户端可以向服务器发送状态信息

11. Referer：显示当前页面是从哪个页面链接过来的，有助于追踪用户的浏览路径

12. Origin：在跨域请求中指明请求来源，帮助服务器判断是否允许该请求

HTTP头部字段的数量并不是固定的，HTTP协议甚至允许自定义头部字段以满足特定需求

• HTTP头部字段不是通过位数来区分的，而是通过文本格式进行解析：每个HTTP头部字段都是一个名称: 值对，其中名称和值之间用冒号（:）加上空格分隔。字段名是大小写不敏感的

• 顺序无关性：头部字段的顺序一般不影响其含义，除了某些特定情况下的特殊字段（如Connection字段中的元素）

每个头部字段都以回车换行（CRLF, \r\n）结束。头部字段集合以一个额外的CRLF行（即两个连续的CRLF）结束，这标志着头部与可能跟随的实体主体之间的分界

HTTP响应报文

HTTP响应报文是服务器返回给客户端的消息，包含了请求的结果信息以及可能的资源数据。响应报文由三部分组成：状态行、响应头部和实体主体（可选）

状态行 (Status Line)：包含HTTP版本、状态码（如200）和状态消息（如ok）

响应头部 (Response Headers)：包含了一系列 名称: 值 对，提供了关于响应或其载荷的信息

空行 (Blank Line)：一个仅包含CRLF（回车换行）的行，用于标记头部字段的结束和实体主体的开始

常见的状态码

HTTP状态码是服务器对客户端请求的响应状态的数字代码。它们帮助客户端理解服务器处理请求的结果，并根据这些结果采取适当的行动

HTTP状态码分为五个类别，每个类别的第一个数字定义了响应的类别

1. 1xx（信息性响应）：请求已被接收，继续处理。
2. 2xx（成功响应）：请求已成功被服务器接收、理解和处理。
3. 3xx（重定向）：需要客户端采取进一步操作以完成请求。
4. 4xx（客户端错误）：请求包含语法错误或无法完成。
5. 5xx（服务器错误）：服务器在尝试处理请求时遇到错误。

下面是每种类别常见的HTTP状态码：

1xx - 信息性响应

• 100 Continue：客户端应继续其请求。
• 101 Switching Protocols：服务器理解并同意客户端升级协议的要求。

2xx - 成功响应

• 200 OK：标准的成功响应，表示请求已被成功处理。
• 201 Created：请求成功且服务器创建了一个新的资源。
• 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容。

3xx - 重定向

• 301 Moved Permanently：请求的资源已被永久移动到新位置，后续对该资源的请求都应指向给出的新URI。
• 302 Found：请求的资源临时从不同的URI响应请求。
• 304 Not Modified：资源未被修改，可以使用缓存的版本。

4xx - 客户端错误

• 400 Bad Request：由于明显的客户端错误（如请求格式错误），服务器无法处理请求。
• 401 Unauthorized：请求需要用户验证。
• 403 Forbidden：服务器理解请求但拒绝执行。
• 404 Not Found：请求的资源在服务器上不存在。
• 405 Method Not Allowed：请求方法对指定资源不适用。

5xx - 服务器错误

• 500 Internal Server Error：服务器遇到了未知情况，阻止了它完成请求。
• 501 Not Implemented：服务器不具备完成请求的功能。
• 502 Bad Gateway：作为网关或代理的服务器收到无效响应。
• 503 Service Unavailable：服务器暂时无法处理请求（可能是过载或维护）。
• 504 Gateway Timeout：作为网关或代理的服务器未能及时从上游服务器获得响应。

GET与POST

GET和POST的主要区别在于语义：GET用于获取数据，POST用于提交数据

• GET： 适用于获取数据，如查询、搜索等。 参数暴露在URL中，安全性较低。
• POST： 适用于提交数据，如表单提交、文件上传等。 参数在请求体中，安全性较高。

1. 语义区别：

• GET：用于获取数据。请求指定的资源，服务器解析后返回响应内容。
• POST：用于提交数据。请求服务器处理数据（如提交表单或上传文件），数据包含在请求体中。

2. 请求参数位置

• GET： 参数通常附加在URL后，使用?分隔URL和参数，参数间用&连接。
  • 例如：/api/data?id=1&name=test
• POST： 参数通常放在请求体中。例如：{"id": 1, "name": "test"}

注意：HTTP规范并未强制规定参数位置，上述做法是约定俗成的习惯。虽然可以在POST请求中通过URL传递数据，或者在GET请求中将数据放入请求体中，但这不符合常规使用习惯，并可能导致兼容性问题或安全隐患。

3. 浏览器行为

• GET： URL长度有限制（通常不超过2048字符）。 请求可被缓存和收藏。
• POST： 无URL长度限制。 请求不会被缓存，通常无法直接收藏。

HTTP工作流程

1. 域名解析： 用户在浏览器地址栏输入URL后，浏览器首先进行域名解析（依次查询浏览器缓存、操作系统缓存、hosts文件、DNS服务器）。

2. 建立TCP连接： 浏览器与服务器通过TCP三次握手建立连接。

3. 生成HTTP请求： 浏览器生成HTTP请求报文，向下经过：

   • 传输层（TCP）：拆包并添加TCP头部。
   • 网络层（IP）：添加IP头部。
   • 链路层：通过网卡发送到网络中。

4. 请求传输： 数据包在网络中经过多次中转，最终到达服务器。

5. 服务器处理请求： 服务器接收到数据包后，逐层解析：

   • 网络层（IP）：去掉IP头部。
   • 传输层（TCP）：去掉TCP头部并合并数据包。
   • 应用层（HTTP）：解析HTTP请求报文，识别请求的资源并生成HTTP响应。

6. 返回HTTP响应：服务器将HTTP响应报文向下经过：

   • 传输层（TCP）：拆包并添加TCP头部。
   • 网络层（IP）：添加IP头部。
   • 链路层：通过网卡发送到网络中。

7. 响应传输： 数据包在网络中经过多次中转，最终到达客户端。

8. 客户端接收响应： 客户端接收到数据包后，逐层解析：

   • 网络层（IP）：去掉IP头部。
   • 传输层（TCP）：去掉TCP头部并合并数据包。
   • 应用层（HTTP）：解析HTTP响应报文。

9. 渲染页面： 浏览器解析HTML内容，若遇到CSS、JS、图片等资源，则再次发起HTTP请求获取资源。 当所有资源加载完成后，浏览器渲染页面并呈现给用户。

HTTPS原理及应用

HTTPS协议是HTTP协议的安全版本，它通过在HTTP之上使用SSL/TLS协议来保护通信内容的安全性

HTTPS报文格式

HTTPS 本质上仍然是 HTTP，但增加了 SSL/TLS 加密层，报文结构与 HTTP 相似，主要区别在于：

1. 端口号不同：HTTP 使用 80 端口，而 HTTPS 使用 443 端口。
2. 传输方式不同：
   • HTTP：明文传输，容易被中间人攻击（如窃听、篡改）。
   • HTTPS：使用 SSL/TLS 加密，数据经过加密后传输，确保安全性。
3. 握手阶段（SSL/TLS Handshake）：
   • HTTP 直接请求-响应。
   • HTTPS 需要先进行 SSL/TLS 握手，协商加密方式，建立安全连接后再传输数据。

HTTPS加密机制

HTTPS 结合了 对称加密（Symmetric Encryption） 和 非对称加密（Asymmetric Encryption），充分利用二者的优点。

对称加密（Symmetric Encryption） ：发送方与接收方使用 相同的密钥 进行加密和解密。速度快，适合大数据量传输，但密钥管理复杂。常见算法：

• AES（Advanced Encryption Standard，高级加密标准）：目前主流对称加密算法。
• DES（Data Encryption Standard，数据加密标准）：已被认为不安全。
• 3DES（Triple DES，三重数据加密）：比 DES 安全，但速度慢。

✅ 速度快，适合大数据量传输。
❌ 需要安全管理密钥，密钥泄露后数据易被破解。

在HTTPS中，对称加密主要用于加密大量的数据传输，因为它的速度较快

非对称加密（Asymmetric Encryption） ：使用 公钥（Public Key） 进行加密，使用 私钥（Private Key） 进行解密（或者反向操作）。 适用于身份认证、密钥交换，但速度慢。 常见算法：

• RSA（Rivest-Shamir-Adleman）：常用的非对称加密算法。
• ECC（Elliptic Curve Cryptography，椭圆曲线密码学）：比 RSA 更高效，适用于移动设备。
• Diffie-Hellman（DH）：主要用于密钥交换，而非加密。

✅ 密钥管理相对简单，可用于身份认证。
❌ 计算量大，加解密速度慢，不适合大数据量传输。

SSL/TLS握手流程

HTTPS 主要使用 非对称加密传输密钥，然后使用 对称加密传输数据，结合了二者的优点。

• SSL（Secure Sockets Layer）是早期的安全协议，而TLS（Transport Layer Security）是SSL的后继者，提供了更高级别的安全性

• TLS 1.3 是 TLS 协议的最新版本，相较于 TLS 1.2，它在性能和安全性方面有显著提升：

  1 更快的访问速度

  • TLS 1.2：需要 2-RTT（两次往返） 完成握手。
  • TLS 1.3：仅需 1-RTT（一次往返） 完成握手，支持 0-RTT 模式，进一步减少延迟。
  • 性能提升：TLS 1.3 的握手时间减半，访问速度更快，尤其对移动端用户友好。

  2 更强的安全性

  • 移除不安全的加密算法：TLS 1.3 删除了 RSA 密钥传输、CBC 模式密码、RC4 流密码、SHA-1 哈希函数等易受攻击的算法。
  • 强制前向安全性：TLS 1.3 仅支持前向安全的密钥交换机制（如 ECDHE）。
  • 减少明文暴露：ServerHello 之后的所有握手消息都加密传输，减少了明文暴露的风险。

  3 简化与优化

  • 废弃不必要功能：TLS 1.3 不再支持重协商、压缩和静态 RSA 密钥交换。
  • 更简洁的协议设计：减少了握手步骤和复杂性，提高了协议的健壮性。

目前，主流浏览器均已支持 TLS 1.3：

• Chrome：从 Chrome 70 开始默认支持 TLS 1.3。
• Firefox：从 Firefox 63 开始默认支持 TLS 1.3。
• Safari：从 Safari 12.1 开始支持 TLS 1.3。
• Edge：基于 Chromium 的 Edge 浏览器默认支持 TLS 1.3。

总结

• TLS 1.3 的优势：
  • 更快的握手速度（1-RTT，支持 0-RTT）。
  • 更强的安全性（移除不安全的加密算法，强制前向安全性）。
  • 更简洁的协议设计。
• TLS 1.2 的局限性：
  • 握手时间较长（2-RTT）。
  • 支持不安全的加密算法（如 RSA 密钥传输、SHA-1）。
• 未来趋势：
  • TLS 1.3 已成为主流，逐步取代 TLS 1.2。
  • 随着浏览器和服务器对 TLS 1.3 的支持普及，HTTPS 的性能和安全性将进一步提升。

通过对比 TLS 1.2 和 TLS 1.3 的握手过程，可以清晰地看到 TLS 1.3 在性能和安全性上的显著优势。随着互联网安全需求的不断提高，TLS 1.3 将成为 HTTPS 通信的标准协议。

数字证书

为了验证服务器的身份，HTTPS使用数字证书来确保客户端与正确的服务器进行通信。数字证书通常包含以下信息：

• 服务器的身份信息。
• 发行该证书的认证机构（CA）。
• 公钥。
• 有效期。
• CA的数字签名。

Digital Signature

数字签名（Digital Signature）： 确保 数据完整性 + 身份认证。流程：

1. 发送方计算消息的哈希值（Message Digest）。
2. 使用私钥对哈希值进行加密，生成 数字签名。
3. 接收方用发送方的公钥解密 数字签名，并计算消息的哈希值进行对比，验证消息是否被篡改。

常见算法：

• RSA 签名
• ECDSA（基于椭圆曲线的数字签名算法）

完整性校验

HTTPS协议使用消息认证码（MAC）或数字签名来确保数据的完整性和防止中间人攻击。TLS协议使用散列函数来生成MAC，这有助于检测数据在传输过程中是否被篡改。

SHA1
C71D49A6144772F352806201EF564951BE55EDD5

下载完成后务必进行SHA1校验（推荐使用iHasher），与网站核对一致后再使用。

散列函数（Hash Function）：将原始数据转换为固定长度的哈希值（不可逆）。 主要用于 数据完整性校验，防止数据被篡改。 常见算法：

• MD5（已不安全）
• SHA-256（Secure Hash Algorithm 256-bit）（主流）
• SHA-3（更强的哈希算法）

HTTPS内容总结

HTTPS 通过 SSL/TLS 加密、身份认证、完整性校验，大幅提升了 Web 传输的安全性，是现代网络安全通信的基础

1. 防窃听（Eavesdropping）：数据加密（对称 + 非对称）。
2. 防篡改（Tampering）：消息摘要（SHA-256）。
3. 防冒充（Impersonation）：数字签名 + 证书验证。

更多关于加密的内容参照：密码学合集

HTTPS使用==混合加密==来结合对称加密和非对称加密的优点。具体流程如下：

1. 建立连接：客户端向服务器发起HTTPS连接请求。
2. 交换公钥：服务器将自己的公钥发送给客户端。
3. 生成会话密钥：客户端使用服务器的公钥加密一个随机生成的对称密钥（会话密钥），然后发送给服务器。
4. 加密数据传输：服务器收到会话密钥后，使用自己的私钥解密得到会话密钥，之后所有数据都使用这个会话密钥进行对称加密和解密。

HTTPS抓包及解密

HTTPS 虽然通过加密保护了数据传输的安全性，但在某些情况下（如未正确验证证书或密钥泄露），仍然可能被攻击者解密。

• mitmproxy 是一个强大的工具，用于拦截和修改 HTTP/HTTPS 流量，适合安全测试和调试。
• Wireshark 结合 SSLKEYLOGFILE 可以解密 HTTPS 流量，用于深度分析网络通信。

mitmproxy 用于拦截和修改流量，适合实时分析和调试。Wireshark 用于深度分析网络流量，结合 SSLKEYLOGFILE 可以解密 HTTPS 流量。两者结合可以更全面地分析网络通信的安全性。

中间人攻击与捕获密钥，参照视频：抓包解密https — mitmproxy与wireshark

1. 中间人攻击（MITM）简介 中间人攻击是一种网络攻击方式，攻击者通过拦截通信双方的流量，窃取或篡改数据。

2. 利用 mitmproxy 进行中间人攻击

mitmproxy 是一个强大的开源工具，支持 HTTP 和 HTTPS 流量的拦截、修改和重放。以下是使用 mitmproxy 进行中间人攻击的步骤：

2.1 安装 mitmproxy

• 通过 pip 安装：
  bash 复制

  pip install mitmproxy

• 或者从 mitmproxy 官网 下载适合操作系统的版本。

2.2 启动 mitmproxy

• 在终端运行以下命令启动 mitmproxy：
  bash 复制

  mitmproxy

• 默认监听端口为 8080。

2.3 配置客户端代理

• 在需要监控的设备或浏览器上，设置代理服务器为运行 mitmproxy 的机器 IP 地址及端口（如 192.168.1.100:8080）。

2.4 安装 mitmproxy 根证书

• 为了解密 HTTPS 流量，客户端需要信任 mitmproxy 的根证书。
• 在客户端浏览器中访问 http://mitm.it/，下载并安装适合操作系统的根证书。
• 安装完成后，mitmproxy 可以解密并查看 HTTPS 请求的内容。

2.5 拦截和查看流量

• 启动 mitmproxy 后，所有经过代理的 HTTP/HTTPS 流量都会显示在 mitmproxy 的交互界面中。
• 可以查看请求和响应的详细信息，甚至修改数据包。

3. 使用 Wireshark 捕获和解密 HTTPS 流量

Wireshark 是一个网络协议分析工具，可以捕获和分析网络流量。结合 SSLKEYLOGFILE，Wireshark 可以解密 HTTPS 流量。

3.1 启用 SSLKEYLOGFILE

• SSLKEYLOGFILE 是一个环境变量，用于导出 TLS 会话密钥。
• 在启动目标应用程序（如浏览器）之前，设置环境变量：
  • Windows：
    cmd 复制

    set SSLKEYLOGFILE=C:\path\to\sslkeylog.log

  • Linux/macOS：
    bash 复制

    export SSLKEYLOGFILE=/path/to/sslkeylog.log

• 确保目标应用程序重启后生效。

3.2 配置 Wireshark

1. 打开 Wireshark，进入 Edit -> Preferences -> Protocols -> TLS。
2. 在 (Pre)-Master-Secret log filename 选项中，浏览并选择刚才设置的 SSLKEYLOGFILE 路径。
3. 应用更改后，Wireshark 将使用日志文件中的密钥解密捕获的 TLS 流量。

3.3 捕获和解密流量

• 启动 Wireshark，选择需要捕获的网络接口。
• 开始捕获流量，Wireshark 会自动解密 HTTPS 流量（前提是 SSLKEYLOGFILE 已正确配置）。

注意事项

• 证书验证：确保客户端正确验证服务器证书，避免中间人攻击。
• 密钥保护：SSLKEYLOGFILE 包含敏感信息，需妥善保管，防止泄露。