Cloudflare OHTTP 게이트웨이 공개

AI 요약

Cloudflare가 OHTTP(Oblivious HTTP) Gateway 비공개 베타를 시작합니다. 고객은 유료 부가 기능으로 게이트웨이를 활성화하고, 자체 애플리케이션 서버에서 OHTTP 요청을 받을 수 있습니다. 기존 Privacy Gateway는 Cloudflare OHTTP Relay로 이름을 바꿉니다. 두 제품을 구분해 릴레이와 게이트웨이를 서로 다른 운영자가 맡도록 구성합니다.

OHTTP가 나누는 정보

일반적인 HTTP 연결에서는 애플리케이션 서버가 사용자 IP 주소와 TLS 지문을 봅니다. 이 정보가 요청 내용과 함께 남으면 여러 요청을 한 사용자와 연결할 수 있습니다. OHTTP는 클라이언트와 애플리케이션 서버 사이에 릴레이와 게이트웨이를 둡니다. 릴레이는 IP 주소 등 클라이언트 정보를 보지만 요청 내용은 암호문으로만 전달합니다. 게이트웨이는 요청을 복호화하고 응답을 암호화하지만, 클라이언트 IP 주소를 알지 못합니다. Hybrid Public Key Encryption(HPKE)을 사용해 릴레이가 요청 내용을 읽지 못하게 합니다. 따라서 한 운영자가 두 역할을 모두 맡지 않아야 사용자 식별 정보와 요청 내용을 한곳에서 연결하지 않는다는 OHTTP의 신뢰 분리가 유지됩니다.

릴레이와 게이트웨이 선택

Cloudflare OHTTP Relay를 쓰면 고객이 게이트웨이를 직접 운영해야 합니다. 애플리케이션 서버가 Cloudflare 밖에 있고 자체 게이트웨이를 운영할 수 있는 경우에 맞습니다. 반면 앱 서버가 Cloudflare CDN이나 Workers 뒤에 있거나, Apple LiveCallerID 같은 제3자 클라이언트의 OHTTP 요청을 받는 경우에는 관리형 Gateway를 선택할 수 있습니다. Cloudflare는 릴레이와 게이트웨이를 각각 다른 운영자에게 맡기는 구성을 제공합니다.

엣지 배치와 요청 처리

게이트웨이는 고객 도메인의 /.well-known/ohttp-gateway 경로에서 요청을 받습니다. Cloudflare가 OHTTP 요청을 가로채 복호화한 뒤 앱 서버에 하위 요청을 보내고, 응답을 암호화해 클라이언트로 돌려보냅니다. 일반 HTTP 요청은 게이트웨이를 거치지 않습니다. 표준 OHTTP와 청크형 OHTTP를 지원하며, 청크형은 요청을 나눠 처리해 성능을 높이는 방식으로 권장합니다. Cloudflare의 글로벌 애니캐스트 네트워크 전반에서 게이트웨이를 실행하고, 앱 서버가 Cloudflare에 있으면 게이트웨이와 원본 서버 사이의 지연도 줄인다는 설명입니다.

키 관리와 접근 제어

게이트웨이는 HPKE 공개 키를 관리하고, /.well-known/ohttp-gateway에 대한 GET 요청에 키를 제공합니다. 릴레이 인증에는 Cloudflare Access 정책을 적용할 수 있습니다. 상호 TLS, 정적 서비스 자격 증명, 외부 로직을 이용해 복호화 전에 요청을 인증합니다. 고객이 릴레이와 게이트웨이를 실수로 모두 Cloudflare에서 운영해 신뢰 분리를 깨는 상황을 막기 위해, Cloudflare는 Workers 또는 프록시된 호스트에서 온 요청을 복호화하지 않습니다. 또한 OHTTP는 네트워크 수준의 프라이버시만 다루므로 요청 본문에 이메일이나 사용자 이름 같은 식별 정보를 넣지 않는 일은 애플리케이션 개발자 몫입니다.

Hacker News 반응

• @shieldagent — OHTTP는 역할을 나누는 방식이 흥미롭습니다. 릴레이는 사용자가 누구인지 알고, 게이트웨이는 무엇을 요청했는지 알지만, 어느 쪽도 두 정보를 함께 알지 못합니다.
• @gsnedders — OHTTP는 같은 클라이언트의 여러 요청을 게이트웨이가 연결하지 못하게 하려는, 상태 없는 요청이라는 비교적 좁은 용도를 겨냥합니다. SOCKS5로도 비슷한 일을 할 수 있지만, 요청마다 새 TCP 연결을 만들고 TLS 세션 재개와 0-RTT를 막는 등 여러 부분을 신경 써야 합니다. OHTTP에서는 요청이 릴레이와의 TLS 연결 안에 있으므로 게이트웨이가 클라이언트의 TLS 지문을 보지 못합니다. DNS-over-HTTPS 같은 서비스에서는 클라이언트와 릴레이, 릴레이와 게이트웨이 사이의 연결을 오래 유지할 수 있어 지연도 줄어듭니다.
• @nirui — 게이트웨이가 암호화와 복호화를 맡는 대신, 클라이언트와 원본 서버만 복호화하도록 설계하는 편이 낫지 않나요? 지금 구조는 익명 SOCKS5 서버를 거쳐 Cloudflare 뒤의 웹사이트에 접속하는 방식과 크게 달라 보이지 않습니다.
  • @kccqzy — OHTTP에서 이중 암호화를 막는 요소는 없습니다. 게이트웨이가 한 번 복호화하고, 원본 서버가 HPKE 같은 방식을 써서 두 번째 암호화를 풀면 됩니다.
• @arshxyz — Cloudflare WAF는 TLS 지문을 활용한다고 했는데, OHTTP를 켜도 작동하나요? 작동한다면 Cloudflare가 클라이언트 메타데이터를 읽고 처리하되 애플리케이션 서버로 전달하지 않는다는 뜻인가요?
• @Joker_vD — 악용자를 IP로 차단하는 기능은 어떻게 구현하나요? 먼저 악용을 알아내고, 그 악용을 원래 IP나 다른 식별자와 연결해야 합니다.
  • @someonebaggy — 악용자는 주거용 프록시를 사면 되니, 원래도 IP만으로 차단하지 못합니다.
  • @yencabulator — 멀리 떨어진 데이터센터 몇 곳을 ASN과 IP 주소 기준으로 차단했더니, 제가 돕는 사이트의 봇 트래픽이 80% 넘게 줄었습니다. 악용자가 무조건 다른 곳으로 옮기는 건 아닙니다.
• @freedomben — 기술 분야의 프라이버시 개선은 반갑습니다. 다만 웹사이트가 프라이버시 기능을 추가하는 데 요금을 더 내게 하는 건, 전반적인 프라이버시를 높이려는 목표에 좋은 유인은 아닌 듯합니다.
  • @tclancy — 동의합니다. 그래도 비용을 낼 의사가 있는 곳에 도입 경로를 제공하고, 규모나 인기에 따라 사실상의 표준으로 자리 잡으면 좋겠습니다.
• @ranger_danger — 현재 프록시나 VPN 소프트웨어 중 OHTTP를 전송 방식으로 지원하는 제품이 있나요? 브라우저가 일반 웹사이트 요청에 OHTTP를 쓰는 경우도 궁금합니다.
  • @jon-wood — 최근 몇 년간 출시된 macOS와 iOS 기기에서 쓸 수 있는 iCloud Private Relay가 OHTTP를 사용해 방문 사이트에 사용자의 신원을 숨깁니다.

원문: Cloudflare Blog / 번역·요약: Trawling