HTTP代理原理与浅析TLS

January 15, 2024

HTTP 代理

可以简单地使用下面的代码来观察请求内容

require("net")
    .createServer((socket) => {
        socket.pipe(process.stdout);
        socket.end();
    })
    .listen(9980);

注意 HTTP 协议自身的换行符是 CRLF，即 \r\n

对于 HTTP 流量，要求代理直接解析并转发 HTTP 请求（RFC7230）

curl -x 127.0.0.1:9980 http://example.net/pathname -d "post_body"

与普通的 HTTP 请求不同的是，路径处是完整的 URL，这样代理才知道要请求的 URL
有一些请求头是发送给代理的，例如下面的 Proxy-Connection

POST http://example.net/pathname HTTP/1.1
Host: example.net
User-Agent: curl/8.4.0
Accept: */*
Proxy-Connection: Keep-Alive
Content-Length: 9
Content-Type: application/x-www-form-urlencoded

post_body

对于非 HTTP 流量，HTTP 代理可承载任意 TCP 流量（RFC7231#section-4.3.6）

下以 HTTPS 举例，但注意此时相当于隧道代理，转发的流量对代理来说是透明的（即代理只管原样转发流量）

curl -x 127.0.0.1:9980 https://example.net/pathname -d "post_body"

客户端首先向代理发送 CONNECT 请求，路径处指定的是目标 TCP 的主机地址（域名:端口）

此时的请求头都是发送给代理的指令。CONNECT 请求是普通的 HTTP 请求，可以复用已有的 HTTP 机制，
比如需要认证的 HTTP 代理可以是 RFC7235 描述的 HTTP 身份验证实现的。

CONNECT example.net:443 HTTP/1.1
Host: example.net:443
User-Agent: curl/8.4.0
Proxy-Connection: Keep-Alive

代理需要与目标 TCP 服务器建立连接，并向客户端返回

HTTP/1.1 200 Connection established
（这一行是空行，再次强调换行符是 \r\n 即 0x0D0A）

（注意上面的空行，这是因为响应头发送完毕，接下来的内容作为响应体传输）

表示已成功建立连接，可以开始转发 TCP 流量
注意此时代理保持了与目标服务器和客户端的 TCP 连接

此后代理只需要双向原样转发 TCP 流量即可

代理与客户端建立的 HTTP 连接，实际上只是借用了 HTTP 的原语发送代理指令而已，
一旦代理指令发送完毕，此时的 HTTP 连接直接视为 TCP 连接，因此是双向 TCP 连接（而 HTTP 是单向的）
只不过从报文的顺序来说，对于建立的 HTTP 连接，转发的流量处于 HTTP 的请求体

简单实现如下：

import http from "node:http";
import url from "node:url";
import net from "node:net";

http.createServer((req, res) => {
    // 转发 HTTP 流量
    // 简单起见，不识别和添加请求头
    console.log("转发HTTP", req.url);
    http.request(
        req.url!,
        {
            headers: req.headers,
        },
        (hRes) => {
            res.writeHead(hRes.statusCode!, hRes.headers);
            hRes.pipe(res);
        }
    ).on("error", () => res.end());
})
    .on("connect", (req, socket, head) => {
        // 转发任意 TCP 流量
        // 简单起见，省略错误处理
        console.log("转发任意TCP", req.url);
        const { hostname, port } = url.parse("//" + req.url, false, true);
        const targetSocket = net
            .connect({ host: hostname!, port: Number(port) }, () => {
                socket.write("HTTP/1.1 200 Connection Established\r\n");
                socket.write("\r\n");
                targetSocket.pipe(socket);
            })
            .on("error", () => {
                socket.end();
            });
        socket.pipe(targetSocket);
    })
    .listen(9980, () => console.log("Proxy listen at http://127.0.0.1:9980"));

TLS

TLS流程如下：

图解：https://tls13.xargs.org/

客户端 C 选定一组加密算法（密钥交换算法），并生成客户端不重数（随机数）发送给服务器 S（不重数用于防止重放攻击）
- TLS1.3 时，C 可以猜测 S 支持的加密算法（例如 C 先前已与 S 建立过 TLS 连接），并直接发送一种加密算法待 S 确认（若成功，则减少一次 RTT 开销）
- 对于 HTTPS，还会根据 TLS 的 SNI 扩展发送目标服务器域名
服务器 S 选择支持的加密算法和生成的服务端不重数，连同 S 的证书，发送给 C
C 使用 CA 公钥鉴别 S 的证书。C 生成预主密钥 PMS，用 S 的公钥加密发送给 S
S 使用私钥解密得到预主密钥 PMS（此时 C 和 S 均持有相同的 PMS）。
C 和 S 使用已商定的算法，均使用 PMS+客户端不重数+服务端不重数，生成主密钥 MS
主密钥 MS 划分为四个密钥，之后 C 和 S 会分别使用其中两个（C/S 的会话密钥、C/S 的 MAC 密钥）（MAC 密钥用于计算 MAC 散列）
C 向 S 发送全部握手阶段报文的 MAC 散列
S 向 C 发送全部握手阶段报文的 MAC 散列
分别确认 MAC 一致（没有被中间人篡改）后完成握手
TLS 中，C 或 S 发送的每一块数据称为记录（record），实际发送的数据块算法如下
- MAC 散列 = MAC 密钥加密(明文记录 + MAC 密钥 + 记录的序号)
- 实际发送数据块 = 类型 + 版本 + 长度 + 会话密钥加密(明文记录 + MAC 散列)
通过上面的类型字段来关闭 TLS 连接（而不是直接通过 TCP 的 FIN 报文，防止截断攻击）

注意到 HTTPS 相当于 TLS 承载 HTTP，浏览器还会验证服务器证书声称的 FQDN(Fully Qualified Domain Name) 是否与 SNI 目标域名一致

←Back to home

This work is licensed under CC BY-NC-SA 4.0