API cổng vào HTTP Oblivious HTTP của chế độ Duyệt web an toàn
Lưu ý: Tài liệu này hiện vẫn đang trong quá trình phát triển. Chúng tôi có thể cải thiện trong tương lai gần.
Safe Browsing Oblivious HTTP Gateway API là một API bảo đảm quyền riêng tư, được xây dựng dựa trên giao thức RFC của IETF có tên là Oblivious HTTP, RFC 9458.
Tổng quan
Safe Browsing Oblivious HTTP Gateway API là một dịch vụ của Google cho phép các ứng dụng khách kiểm tra URL theo danh sách tài nguyên web không an toàn được cập nhật liên tục của Google, đồng thời triển khai các biện pháp bảo vệ quyền riêng tư bổ sung.
Bạn có thể thực hiện việc này thông qua một giao thức gọn nhẹ có tên là Oblivious HTTP hoặc viết tắt là OHTTP. Đây là một giao thức phi trạng thái mà các ứng dụng khách của tính năng Duyệt web an toàn có thể sử dụng để truy cập vào các API Duyệt web an toàn của Google phiên bản 5. Đây là giao thức nhằm nhận được các biện pháp bảo vệ mạnh mẽ và tăng mức độ phù hợp mà không ảnh hưởng đến quyền riêng tư của người dùng.
LƯU Ý: Bạn không thể truy cập API Duyệt web an toàn của Google phiên bản 4 thông qua dịch vụ này.
Giao thức HTTP Oblivious của chế độ Duyệt web an toàn
Giao thức RFC
Oblivious HTTP là một giao thức gọn nhẹ được xác định trong RFC 9458, dùng để mã hoá và gửi thông báo HTTP từ máy khách đến máy chủ đích. Việc này sử dụng dịch vụ chuyển tiếp đáng tin cậy theo cách giảm thiểu việc máy chủ mục tiêu sử dụng siêu dữ liệu như địa chỉ IP và thông tin kết nối để nhận dạng ứng dụng, mang lại quyền riêng tư và tính bảo mật ở trên cùng giao thức HTTP/S thuần tuý. Giao thức này sử dụng HTTP nhị phân, được xác định trong RFC 9292, để mã hoá/giải mã các yêu cầu/phản hồi HTTP.
Ở cấp độ cao, Relay (Chuyển tiếp) nằm giữa tài nguyên Ứng dụng và Cổng vào proxy lưu lượng truy cập của ứng dụng bằng cách xoá tất cả giá trị nhận dạng ứng dụng, bao gồm cả các thuộc tính nhạy cảm về quyền riêng tư như địa chỉ IP, ẩn danh một cách hiệu quả các yêu cầu HTTP đến đối với dịch vụ Cổng vào. Lợi ích bổ sung của OHTTP là tất cả yêu cầu đều được mã hoá hai đầu, có nghĩa là các truy vấn Duyệt web an toàn của khách hàng (tức là các hàm băm bị cắt bớt của biểu thức URL) không hiển thị cho Relay. Tham khảo bài đăng trên blog để biết ví dụ về cách triển khai trong Chrome.
Khách hàng có thể chọn bất kỳ nhà cung cấp dịch vụ Chuyển tiếp nào (ví dụ: Nhanh chóng) để tích hợp với dịch vụ. Trình chuyển tiếp phải sử dụng phương thức xác thực Oauth 2.0 với phạm vi uỷ quyền sau để truy cập vào dịch vụ.
// OAuth Authorization scope:
https://www.googleapis.com/auth/3p-relay-safe-browsing
Điểm cuối API
Khoá công khai OHTTP
Điểm cuối này sẽ cung cấp cấu hình khoá công khai OHTTP như chỉ định trong RFC 9458. Máy khách sẽ sử dụng cấu hình này để mã hoá yêu cầu OHTTP.
GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>
Khoá API ở trên không hoàn toàn cần thiết; máy chủ không thay đổi Khoá công khai OHTTP dựa trên khoá API đã cung cấp. Khách hàng có thể tìm hiểu thông tin này bằng cách sử dụng nhiều khoá API hợp lệ để truy cập vào điểm cuối này hoặc hoàn toàn không dùng khoá API nào, đồng thời kiểm tra để đảm bảo rằng phản hồi thực sự chứa cùng một khoá công khai OHTTP. Tuy nhiên, để dễ dàng gỡ lỗi, bạn nên sử dụng khoá API để khách hàng có thể xem số liệu thống kê, chẳng hạn như số lượng yêu cầu trên Google Cloud Console. Nếu ứng dụng có ý định cung cấp khoá API, hãy tham khảo tài liệu này để biết cách thiết lập khoá API.
Như đã nêu trong phần đề xuất về quyền riêng tư, để đạt được các mục tiêu về tính nhất quán chính, Nhà cung cấp dịch vụ khách hàng nên thiết lập cơ sở hạ tầng phân phối khoá tập trung để tìm nạp khoá từ điểm cuối này rồi phân phối khoá đó cho các ứng dụng khách.
Theo hướng dẫn quản lý khoá, các khoá sẽ được xoay vòng thường xuyên trên máy chủ. Ứng dụng nên thỉnh thoảng làm mới khoá, tức là tìm nạp và cập nhật bản sao cục bộ của khoá để tránh lỗi giải mã.
Ứng dụng nên làm mới (tìm nạp và cập nhật) khoá công khai một lần mỗi ngày. Nếu đang sử dụng cơ chế phân phối tập trung, cơ chế này phải đảm bảo tìm nạp và phân phối khoá một lần mỗi ngày.
Yêu cầu đóng gói OHTTP
Điểm cuối này sẽ phân phát yêu cầu OHTTP có trong phần nội dung HTTP của yêu cầu POST, bằng cách giải mã yêu cầu, sau đó mã hoá phản hồi OHTTP để được chuyển tiếp trở lại Relay trong phản hồi HTTP. Ứng dụng phải bao gồm tiêu đề của yêu cầu Content-Type dưới dạng message/ohttp-req trong yêu cầu POST qua HTTP.
POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>
LƯU Ý: Theo hướng dẫn trên RFC, mã hoá yêu cầu bên trong (tham khảo tài liệu phiên bản 5 về cách tạo yêu cầu Duyệt web an toàn) bằng giao thức HTTP nhị phân, RFC 9292.
Thư viện ứng dụng
Google Quiche có các phương thức triển khai phía máy khách cho cả hai giao thức OHTTP và BHTTP. Ứng dụng nên sử dụng các thư viện này. Hãy tham khảo mã giả dưới đây để biết cách xây dựng yêu cầu OHTTP để truy cập API.
Ví dụ về cách triển khai phía máy khách
Ứng dụng tìm nạp khoá công khai Oblivious HTTP từ điểm cuối khoá công khai. Sau đó, hãy khởi chạy cấu hình khoá OHTTP của quiche như vậy và khởi chạy ứng dụng khách OHTTP của quiche.
auto ohttp_key_cfgs = quiche::ObliviousHttpKeyConfigs::ParseConcatenatedKeys(std::string public_key);
auto key_config = ohttp_key_cfgs->PreferredConfig();
auto public_key = ohttp_key_cfgs->GetPublicKeyForId(key_config.GetKeyId())
auto ohttp_client = quiche::ObliviousHttpClient::Create(public_key, key_config);
Ứng dụng sẽ sử dụng chế độ mã hoá HTTP nhị phân để tạo Yêu cầu BHTTP làm bước đầu tiên trước khi mã hoá.
quiche::BinaryHttpRequest::ControlData bhttp_ctrl_data{
.method = "POST",
.scheme = "https",
.authority = "safebrowsing.googleapis.com",
.path = "/v5/hashes:search?key=<API key>&hashPrefixes=<HASH prefix 1>&hashPrefixes=<HASH prefix 2>",
};
quiche::BinaryHttpRequest bhttp_request(bhttp_ctrl_data);
Sau đó, ứng dụng sẽ mã hoá yêu cầu Binary HTTP được tạo ở bước trên.
auto bhttp_serialized = bhttp_request.Serialize();
auto ohttp_request = ohttp_client.CreateObliviousHttpRequest(*bhttp_serialized);
// Client must include this in POST body, and add `Content-Type` header as "message/ohttp-req".
auto payload_include_in_post_body = ohttp_request.EncapsulateAndSerialize();
Sau khi nhận được phản hồi từ Relay, ứng dụng sẽ giải mã phản hồi. Phản hồi sẽ bao gồm tiêu đề phản hồi Content-Type dưới dạng ohttp-res.
auto ctx = std::move(ohttp_request).ReleaseContext();
auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);
Sau khi giải mã thành công phản hồi OHTTP, hãy giải mã đầu ra bằng HTTP nhị phân như vậy.
auto bhttp_response = BinaryHttpResponse::Create(ohttp_response.GetPlaintextData());
if (bhttp_response.status_code() == 200) {
auto http_response = bhttp_response.body();
auto response_headers = bhttp_response.GetHeaderFields();
}