Giao thức bảo mật tầng truyền vận TLS 1.3 bảo vệ tính toàn vẹn và bí mật của nội dung gói tin trước sự nhòm ngó của nhà mạng và các thiết bị định tuyến trung gian. Tuy nhiên, đằng sau lớp mã hoá đó vẫn tồn tại một điểm yếu về siêu dữ liệu (metadata): máy chủ đích luôn nhìn thấy địa chỉ IP gốc của thiết bị gửi yêu cầu.

Trong các tương tác thông thường, việc lộ địa chỉ IP được xem là điều kiện cơ bản của giao tiếp mạng. Thế nhưng đối với các tác vụ nhạy cảm—như gửi câu lệnh truy vấn tới mô hình trí tuệ nhân tạo (AI), gửi báo cáo chẩn đoán lỗi phần cứng, tra cứu toạ độ định vị hoặc gửi dữ liệu sinh trắc học—địa chỉ IP trở thành một mã định danh kiên cố. Bằng cách tổng hợp mốc thời gian và địa chỉ IP, hệ thống máy chủ đích hoàn toàn có thể xây dựng hồ sơ hành vi chi tiết của từng cá nhân ngay cả khi người dùng không đăng nhập tài khoản.

Các giải pháp máy chủ uỷ quyền truyền thống (như HTTP Forward Proxy hay SOCKS5) chỉ đơn thuần dời điểm quan sát: bên vận hành proxy khi đó sẽ thấy cả địa chỉ IP của bạn lẫn nội dung đích đến. Nhằm giải quyết triệt để vấn đề này, tổ chức IETF đã chuẩn hoá tiêu chuẩn RFC 9458 (Oblivious HTTP - OHTTP), kết hợp cùng RFC 9180 (Hybrid Public Key Encryption - HPKE) và RFC 9292 (Binary HTTP).

+--------------------------------------------------------------------------+
|                  KIẾN TRÚC OBLIVIOUS HTTP THEO RFC 9458                  |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+        1. Gửi gói tin mã hoá (HPKE)     +------------+ |
|    |            | --------------------------------------> |   Trạm     | |
|    |   Máy      | <-------------------------------------- | chuyển tiếp| |
|    |   khách    |        4. Trả về kết quả mã hoá (HPKE)  |  (Relay)   | |
|    | (Client /  |                                         +------------+ |
|    | AI Agent)  |                                               |        |
|    +------------+                                   2. Chuyển   |3. Gửi  |
|          |                                          tiếp gói    |kết quả |
|          | (Địa chỉ IP máy khách CHỈ Relay nhìn thấy)   mã hoá  |mã hoá  |
|          | (Nội dung mã hoá bằng khoá của máy chủ đích)         v        |
|          |                                                +------------+ |
|          +----------------------------------------------> |  Máy chủ   | |
|                 (Ranh giới mật mã đầu-cuối)               |   đích     | |
|                 Máy chủ giải mã nội dung qua HPKE         |  (Target)  | |
|                 Máy chủ CHỈ THẤY IP CỦA TRẠM CHUYỂN TIẾP  +------------+ |
|                                                                          |
+--------------------------------------------------------------------------+

Nền tảng mật mã học: Mã hoá lai HPKE và Binary HTTP

RFC 9458 hoạt động dựa trên nguyên tắc tách biệt độc lập giữa hai thực thể hạ tầng: Trạm chuyển tiếp (Relay) và Máy chủ đích (Target). Relay chuyển tiếp các khối dữ liệu mã hoá mà không có khả năng đọc nội dung; Target xử lý dữ liệu giải mã nhưng hoàn toàn không biết địa chỉ IP của người gửi.

Nguyên lý bảo mật này được xây dựng trên hai trụ cột kỹ thuật:

1. Đóng gói dữ liệu Binary HTTP (RFC 9292)

Các yêu cầu HTTP thông thường bao gồm các dòng văn bản tiêu đề và phần thân dữ liệu. Trong OHTTP, toàn bộ yêu cầu—gồm phương thức, đường dẫn, tiêu đề và nội dung—được chuyển đổi thành một mảng byte nhị phân thu gọn theo chuẩn RFC 9292 (BHTTP):

+--------------------+--------------------------------+--------------------+
| Điều khiển khung   | Tiêu đề được chỉ mục hoá       | Thân dữ liệu       |
| (GET /api/v1/query)| (Host: target.example.com ...) | (Binary payload)   |
+--------------------+--------------------------------+--------------------+

Việc chuẩn hoá sang Binary HTTP giúp loại bỏ hoàn toàn các sai khác về định dạng tầng truyền tải trước khi thực hiện mã hoá.

2. Cơ chế mã hoá lai HPKE (RFC 9180)

Để ngăn Relay đọc trộm nội dung, máy khách mã hoá gói tin Binary HTTP bằng khoá công khai của Máy chủ đích. Máy chủ đích công bố cấu hình khoá OHTTP chứa:

  • key_id: Mã định danh 1 byte phân biệt các phiên bản khoá khi xoay vòng khoá.
  • kem_id: Cơ chế đóng gói khoá (ví dụ 0x0020 cho DHKEM trên đường cong Curve25519).
  • kdf_id: Hàm phái sinh khoá (như 0x0001 cho HKDF-SHA256).
  • aead_id: Thuật toán mã hoá dữ liệu có xác thực (như 0x0001 cho AES-128-GCM hoặc 0x0003 cho ChaCha20-Poly1305).
  • public_key: Chuỗi byte khoá công khai của Target.

Áp dụng chế độ Base Mode trong HPKE, máy khách tạo cặp khoá tạm thời $(sk_E, pk_E)$. Sau đó tính toán khoá bí mật chia sẻ với khoá công khai $pk_T$ của Target:

$$ ext{SharedSecret} = ext{DH}(sk_E, pk_T)$$

Sử dụng hàm HKDF, máy khách phái sinh khoá mã hoá AEAD $K_{ ext{req}}$ và chuỗi ngẫu nhiên $N_{ ext{req}}$:

$$(K_{ ext{req}}, N_{ ext{req}}) = ext{KeyDerivation}( ext{SharedSecret}, ext{info})$$

Toàn bộ gói tin Binary HTTP được niêm phong thành bản mã $C_{ ext{req}}$:

$$C_{ ext{req}} = ext{Seal}(K_{ ext{req}}, N_{ ext{req}}, ext{aad}, ext{BinaryHTTPRequest})$$

Gói tin mã hoá gửi đến Relay mang kiểu MIME message/ohttp-req, có cấu trúc: [KeyID (1 byte)] || [KEM ID (2 bytes)] || [KDF ID (2 bytes)] || [AEAD ID (2 bytes)] || [enc (32 bytes)] || [Bản mã]

Do chỉ có Target nắm giữ khoá riêng tương ứng với $pk_T$, Relay không thể can thiệp hay đọc nội dung bên trong mà không làm hỏng tính toàn vẹn của mã AEAD.

+--------------------------------------------------------------------------+
|                  DỮ LIỆU CÁC THỰC THỂ THU THẬP ĐƯỢC                      |
+--------------------------------------------------------------------------+
| Thực thể    | Biết địa chỉ IP gốc? | Đọc được nội dung?    | Đọc kết quả?|
+-------------+----------------------+-----------------------+-------------+
| Nhà mạng    | Có                   | KHÔNG (TLS mã hoá)    | KHÔNG       |
| Trạm Relay  | Có (hoặc IP VPN)     | KHÔNG (Bản mã HPKE)   | KHÔNG       |
| Máy chủ đích| KHÔNG (Chỉ thấy Relay| CÓ (Giải mã BHTTP)    | CÓ          |
+--------------------------------------------------------------------------+

Vòng đời xử lý giao dịch Oblivious HTTP

Quy trình gửi và nhận dữ liệu trong OHTTP diễn ra qua năm giai đoạn tuần tự:

  1. Lấy cấu hình khoá: Máy khách thu thập cấu hình khoá OHTTP của máy chủ đích thông qua bản ghi DNS HTTPS hoặc các điểm truy vấn danh bạ khoá uy tín.
  2. Đóng gói mã hoá: Máy khách chuyển đổi yêu cầu sang Binary HTTP, tạo cặp khoá tạm thời HPKE, niêm phong dữ liệu và tạo khối nhị phân message/ohttp-req.
  3. Chuyển tiếp qua Relay: Máy khách gửi gói tin tới Relay qua phương thức HTTPS POST /relay. Relay kết thúc kết nối TLS của máy khách, xoá bỏ các tiêu đề chứa IP gốc và chuyển tiếp gói tin mã hoá tới Target qua một kết nối HTTP mới.
  4. Giải mã và xử lý tại Target: Máy chủ đích đối chiếu key_id, giải mã phần khoá đóng gói enc để khôi phục khoá chia sẻ, mở niêm phong bản mã và trích xuất yêu cầu Binary HTTP. Máy chủ xử lý nghiệp vụ (như tính toán suy luận AI) và đóng gói kết quả thành Binary HTTP phản hồi.
  5. Mã hoá phản hồi: Máy chủ đích phái sinh khoá phản hồi $K_{ ext{res}}$ từ ngữ cảnh HPKE đã thiết lập, mã hoá phản hồi thành khối message/ohttp-res và gửi về Relay. Relay chuyển tiếp nguyên vẹn khối dữ liệu về máy khách để giải mã.

Sự kết hợp chiến lược giữa RiceGuard và Oblivious HTTP

Mặc dù OHTTP hoạt động ở tầng ứng dụng (L7), việc kết hợp giao thức này với hệ thống đường hầm mạng Layer 3 (như giao thức RiceGuard của VPNRice) mang lại lớp bảo vệ kép:

  1. Vô hiệu hoá nguy cơ lập hồ sơ tại Relay: Khi định tuyến qua RiceGuard, kết nối từ máy khách tới Relay bắt nguồn từ các cụm máy chủ VPN cổng ra dùng chung thay vì địa chỉ IP nhà mạng dân dụng. Ngay cả khi Relay bị xâm nhập, kẻ tấn công cũng không thể liên kết kết nối với hộ gia đình hay thuê bao di động cụ thể.
  2. Ngăn chặn rò rỉ DNS trong tra cứu khoá: Quá trình tra cứu DNS của Relay và Target được cô lập hoàn toàn trong không gian mạng (namespace) của RiceGuard, tránh việc nhà mạng viễn thông phân tích thời điểm bắt đầu phiên làm việc OHTTP.
  3. Bảo mật tối đa cho AI Agent và Telemetry: Các tác tử trí tuệ nhân tạo cục bộ khi thực hiện gọi công cụ (tool-calling) ra bên ngoài có thể chuyển lưu lượng qua OHTTP trên nền RiceGuard, đảm bảo nhà cung cấp dịch vụ AI không thể lưu trữ dấu vết địa chỉ mạng của người dùng.

Cài đặt mẫu: Trình đóng gói OHTTP Client (Go)

Dưới đây là đoạn mã nguồn mẫu minh hoạ cách máy khách đóng gói yêu cầu Binary HTTP bằng thư viện HPKE chuẩn trước khi gửi tới Relay:

package main

import (
	"bytes"
	"crypto/rand"
	"fmt"
	"io"
	"net/http"

	"github.com/cloudflare/circl/hpke"
)

type OHTTPEncapsulator struct {
	suite    hpke.Suite
	targetPK hpke.PublicKey
	keyID    uint8
}

func NewOHTTPEncapsulator(keyID uint8, kemID hpke.KEM, kdfID hpke.KDF, aeadID hpke.AEAD, rawPubKey []byte) (*OHTTPEncapsulator, error) {
	suite := hpke.NewSuite(kemID, kdfID, aeadID)
	pk, err := suite.KEM().Scheme().UnmarshalBinaryPublicKey(rawPubKey)
	if err != nil {
		return nil, fmt.Errorf("không thể phân tích khoá công khai: %w", err)
	}
	return &OHTTPEncapsulator{
		suite:    suite,
		targetPK: pk,
		keyID:    keyID,
	}, nil
}

// EncapsulateRequest đóng gói mảng byte Binary HTTP thành khối message/ohttp-req
func (oe *OHTTPEncapsulator) EncapsulateRequest(bhttpReq []byte) ([]byte, hpke.Context, error) {
	sender, err := oe.suite.NewSender(oe.targetPK, []byte("message/bhttp request"))
	if err != nil {
		return nil, nil, fmt.Errorf("lỗi khởi tạo HPKE sender: %w", err)
	}

	enc, ctx, err := sender.Setup(rand.Reader)
	if err != nil {
		return nil, nil, fmt.Errorf("lỗi thiết lập HPKE: %w", err)
	}

	ciphertext, err := ctx.Seal(nil, bhttpReq)
	if err != nil {
		return nil, nil, fmt.Errorf("lỗi niêm phong dữ liệu: %w", err)
	}

	// Cấu trúc gói tin: [KeyID (1)] [KEM (2)] [KDF (2)] [AEAD (2)] [enc] [bản mã]
	var buf bytes.Buffer
	buf.WriteByte(oe.keyID)
	buf.Write([]byte{0x00, 0x20}) // DHKEM(X25519, HKDF-SHA256)
	buf.Write([]byte{0x00, 0x01}) // HKDF-SHA256
	buf.Write([]byte{0x00, 0x01}) // AES-128-GCM
	buf.Write(enc)
	buf.Write(ciphertext)

	return buf.Bytes(), ctx, nil
}

func SendToRelay(relayURL string, targetURL string, ohttpPayload []byte) ([]byte, error) {
	req, err := http.NewRequest("POST", relayURL, bytes.NewReader(ohttpPayload))
	if err != nil {
		return nil, err
	}
	req.Header.Set("Content-Type", "message/ohttp-req")
	req.Header.Set("Target", targetURL)

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("lỗi gửi gói tin tới relay: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("relay từ chối xử lý: mã HTTP %d", resp.StatusCode)
	}

	return io.ReadAll(resp.Body)
}

Các khía cạnh đánh đổi trong thiết kế hạ tầng

Khi triển khai Oblivious HTTP trong quy mô sản xuất thực tế, các kiến trúc sư hệ thống cần cân nhắc ba yếu tố kỹ thuật then chốt:

  • Độ trễ truyền tải: Do gói tin phải đi qua hai chặng mạng vật lý (Khách hàng $ o$ Relay $ o$ Target) kèm theo thao tác đóng gói mật mã, độ trễ khứ hồi tăng thêm khoảng 20–45 ms. Vì vậy, OHTTP phát huy hiệu quả tối ưu cho các tác vụ telemetry, truy vấn AI độc lập và API nhạy cảm hơn là lướt web tương tác thời gian thực.
  • Khả năng lưu bộ đệm (Caching): Cơ chế bộ đệm biên CDN thông thường dựa trên việc đọc đường dẫn URL. Do các gói tin OHTTP là bản mã hoàn toàn, các trạm trung gian không thể lưu bộ đệm trừ khi có giải pháp gắn nhãn đặc thù.
  • Độc lập vận hành giữa Relay và Target: Tính toàn vẹn của mô hình sẽ sụp đổ nếu Relay và Target thuộc cùng một đơn vị sở hữu hoặc chia sẻ nhật ký kết nối. Việc bảo đảm hai thực thể này nằm ở hai pháp nhân và khu vực địa lý độc lập là điều kiện tiên quyết.

Tiêu chuẩn RFC 9458 Oblivious HTTP khẳng định rằng sự riêng tư trên Internet hiện đại không đòi hỏi phải từ bỏ nền tảng web sẵn có. Bằng cách thực thi ranh giới bảo mật bằng toán học mật mã, OHTTP mang lại sự bảo vệ kiên cố cho dữ liệu người dùng.