Overview

API เกตเวย์ HTTP ที่ไม่ถูกต้องของ Google Safe Browsing

หมายเหตุ: เอกสารนี้ยังอยู่ระหว่างการพัฒนา ซึ่งเราจะปรับปรุงให้ดีขึ้นได้ในอนาคตอันใกล้นี้

Safe Browsing Oblivious HTTP Gateway API คือ API การรักษาความเป็นส่วนตัวที่สร้างขึ้นจากโปรโตคอล IETF RFC ชื่อ Oblivious HTTP, RFC 9458

ภาพรวม

Safe Browsing Oblivious HTTP Gateway API คือบริการของ Google ที่ช่วยให้แอปพลิเคชันไคลเอ็นต์ตรวจสอบ URL กับรายการทรัพยากรบนเว็บที่ไม่ปลอดภัยของ Google ที่อัปเดตอยู่เสมอ พร้อมการปกป้องความเป็นส่วนตัวเพิ่มเติม

ซึ่งทำได้โดยใช้โปรโตคอลขนาดเล็กที่เรียกว่า Oblivious HTTP หรือ OHTTP ซึ่งเป็นโปรโตคอลแบบไม่เก็บสถานะที่ไคลเอ็นต์ Google Safe Browsing สามารถใช้เพื่อเข้าถึง API ของ Google Safe Browsing V5 เพื่อรับการปกป้องที่แน่นหนาและการครอบคลุมที่มากขึ้นโดยไม่ส่งผลกระทบต่อความเป็นส่วนตัวของผู้ใช้

หมายเหตุ: ไม่สามารถเข้าถึง Google Safe Browsing V4 API ผ่านบริการนี้ได้

โปรโตคอล HTTP ของ Safe Browsing Oblivious

โปรโตคอล RFC

Oblivious HTTP เป็นโปรโตคอลที่ใช้ทรัพยากรน้อยซึ่งกำหนดไว้ใน RFC 9458 ซึ่งใช้สำหรับการเข้ารหัสและส่งข้อความ HTTP จากไคลเอ็นต์ไปยังเซิร์ฟเวอร์เป้าหมาย ซึ่งจะใช้บริการส่งต่อที่เชื่อถือได้ในลักษณะที่เป็นการลดการใช้ข้อมูลเมตาของเซิร์ฟเวอร์เป้าหมาย เช่น ที่อยู่ IP และข้อมูลการเชื่อมต่อสำหรับการระบุไคลเอ็นต์ โดยให้ความเป็นส่วนตัวและความปลอดภัยเพิ่มเติมจากโปรโตคอล HTTP/S ธรรมดา โปรโตคอลนี้ใช้ HTTP แบบไบนารีที่กำหนดไว้ใน RFC 9292 เพื่อเข้ารหัส/ถอดรหัสคำขอ/การตอบกลับ HTTP

ในระดับสูง รีเลย์จะอยู่ระหว่างทรัพยากรของไคลเอ็นต์และเกตเวย์ ซึ่งพร็อกซีการจราจรของข้อมูลของไคลเอ็นต์โดยการนำตัวระบุไคลเอ็นต์ทั้งหมดออก รวมถึงแอตทริบิวต์ที่ละเอียดอ่อนด้านความเป็นส่วนตัว เช่น ที่อยู่ IP ซึ่งจะปกปิดคำขอ HTTP ขาเข้าแก่บริการเกตเวย์อย่างมีประสิทธิภาพ ประโยชน์เพิ่มเติมของ OHTTP คือคำขอทั้งหมดจะได้รับการเข้ารหัสจากต้นทางถึงปลายทาง ซึ่งหมายความว่าคำขอ Google Safe Browsing ของลูกค้า (เช่น แฮชแบบตัดออกจากนิพจน์ URL) จะไม่แสดงต่อการส่งต่อ ดูตัวอย่างการใช้งานใน Chrome ได้ที่บล็อกโพสต์

สถาปัตยกรรมโดยรวมของบริการ
รูป: โฟลว์ OHTTP

ลูกค้าสามารถเลือกผู้ให้บริการส่งต่อรายใดก็ได้ (เช่น รวดเร็ว) เพื่อผสานรวมกับบริการ รีเลย์ต้องใช้การตรวจสอบสิทธิ์ Oauth 2.0 กับขอบเขตการให้สิทธิ์ต่อไปนี้เพื่อเข้าถึงบริการ


// OAuth Authorization scope: https://www.googleapis.com/auth/3p-relay-safe-browsing
ปลายทาง API
คีย์สาธารณะ OHTTP

ปลายทางนี้จะมีการกำหนดค่าคีย์สาธารณะ OHTTP ตามที่ระบุไว้ใน RFC 9458 ซึ่งไคลเอ็นต์จะใช้ในการเข้ารหัสคำขอ OHTTP


GET https://safebrowsingohttpgateway.googleapis.com/v1/ohttp/hpkekeyconfig?key=<API key>

คีย์ API ด้านบนไม่จำเป็นอย่างยิ่ง เซิร์ฟเวอร์จะไม่เปลี่ยนแปลงคีย์สาธารณะ OHTTP ตามคีย์ API ที่ระบุ นอกจากนี้ ไคลเอ็นต์จะตรวจสอบข้อเท็จจริงนี้ได้โดยใช้คีย์ API ที่ถูกต้องที่แตกต่างกันเพื่อเข้าถึงปลายทางนี้หรือไม่ได้ใช้คีย์ API เลย และการตรวจสอบว่าการตอบกลับมีคีย์สาธารณะ OHTTP เดียวกันจริงๆ อย่างไรก็ตาม ขอแนะนำให้ใช้คีย์ API เพื่อให้ไคลเอ็นต์ดูสถิติต่างๆ เช่น จำนวนคำขอใน Google Cloud Console ได้ เพื่อให้แก้ไขข้อบกพร่องได้ง่าย หากลูกค้าต้องการระบุคีย์ API โปรดดูเอกสารประกอบนี้เกี่ยวกับวิธีตั้งค่าคีย์ API

ตามที่ระบุไว้ในส่วนคําแนะนําด้านความเป็นส่วนตัว เพื่อให้บรรลุเป้าหมายความสอดคล้องที่สำคัญ เราขอแนะนําให้ผู้ให้บริการไคลเอ็นต์ตั้งค่าโครงสร้างพื้นฐานการกระจายคีย์แบบรวมศูนย์เพื่อดึงข้อมูลคีย์จากปลายทางนี้และแจกจ่ายไปยังแอปพลิเคชันไคลเอ็นต์ในภายหลัง

ตามหลักเกณฑ์การจัดการคีย์ คีย์จะหมุนเวียนในเซิร์ฟเวอร์เป็นประจำ ไคลเอ็นต์ควรรีเฟรชคีย์ กล่าวคือ ดึงข้อมูลและอัปเดตสำเนาคีย์ในเครื่องเป็นประจำบ่อยๆ เพื่อหลีกเลี่ยงความล้มเหลวในการถอดรหัส

ลูกค้าควรรีเฟรช (ดึงข้อมูลและอัปเดต) คีย์สาธารณะวันละครั้ง หากมีการใช้กลไกการเผยแพร่แบบรวมศูนย์ กลไกนี้ควรจะต้องดึงข้อมูลและแจกจ่ายคีย์วันละครั้ง

คำขอที่ห่อหุ้ม OHTTP

ปลายทางนี้จะแสดงคำขอ OHTTP ที่รวมอยู่ในเนื้อหา HTTP ของคำขอ POST โดยทำการถอดรหัสคำขอ จากนั้นเข้ารหัสการตอบกลับ OHTTP เพื่อส่งต่อกลับไปยังรีเลย์ในการตอบสนอง HTTP ไคลเอ็นต์ต้องมีส่วนหัวของคำขอ Content-Type เป็น message/ohttp-req ในคำขอ HTTP POST


POST https://safebrowsingohttpgateway.googleapis.com/v1/ohttp:handleOhttpEncapsulatedRequest?key=<API key>

หมายเหตุ: ตามคำแนะนำเกี่ยวกับ RFC ให้เข้ารหัสคำขอภายใน (โปรดดูเอกสารประกอบ V5 เกี่ยวกับวิธีสร้างคำขอ Google Safe Browsing) โดยใช้โปรโตคอล HTTP แบบไบนารี RFC 9292

ไลบรารีไคลเอ็นต์

Google Quiche มีการใช้งานฝั่งไคลเอ็นต์สำหรับทั้งโปรโตคอล OHTTP และ BHTTP ขอแนะนำให้ไคลเอ็นต์ใช้ไลบรารีเหล่านี้ โปรดดูรหัสเทียมด้านล่างเกี่ยวกับวิธีสร้างคำขอ OHTTP เพื่อเข้าถึง API

ตัวอย่างการใช้งานฝั่งไคลเอ็นต์

ไคลเอ็นต์จะดึงคีย์สาธารณะ HTTP ขององค์กรจากปลายทางคีย์สาธารณะ จากนั้นให้เริ่มต้นการกำหนดค่าคีย์คีช OHTTP แล้วกำหนดค่าไคลเอ็นต์คีช OHTTP


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);

ไคลเอ็นต์จะใช้การเข้ารหัส HTTP แบบไบนารีเพื่อสร้างคำขอ BHTTP เป็นขั้นตอนแรกก่อนที่จะเข้ารหัส


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);

จากนั้นไคลเอ็นต์จะเข้ารหัสคำขอ HTTP แบบไบนารีที่สร้างในขั้นตอนด้านบน


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();

เมื่อได้รับการตอบกลับจาก Relay ไคลเอ็นต์จะถอดรหัสการตอบกลับ การตอบกลับจะรวมส่วนหัวการตอบกลับแบบ Content-Type เป็น ohttp-res


auto ctx = std::move(ohttp_request).ReleaseContext(); auto ohttp_response = ohttp_client.DecryptObliviousHttpResponse("data included in body of http_response", ctx);

หลังจากถอดรหัสการตอบสนอง OHTTP สำเร็จแล้ว ให้ถอดรหัสเอาต์พุตโดยใช้ HTTP แบบไบนารี


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(); }