온라인 프라이버시의 부담은 오랫동안 사용자 몫이었다. 추적이나 타깃 광고를 피하려면 VPN을 쓰고, 쿠키를 끄고, 광고 차단기를 깔라는 식이다. 반대로 앱 개발자 입장에서는 원하지 않아도 사용자에 대해 너무 많이 알게 된다. 전형적인 클라이언트-서버 통신만으로도 클라이언트의 IP 주소나 TLS 핑거프린트 같은 흔적이 남기 때문이다. 클라우드플레어가 이번에 셀프서비스형 OHTTP 게이트웨이의 클로즈드 베타를 공개하고, 기존 'Privacy Gateway'를 'Cloudflare OHTTP Relay'로 이름을 바꾼 배경에는 이 비대칭을 기술로 풀어보려는 의도가 있다.
OHTTP가 나누는 두 개의 홉
OHTTP(Oblivious HTTP)는 앱 백엔드가 사용자 IP를 보지 않고도 HTTP 요청을 받을 수 있게 설계된 IETF 표준이다. 핵심은 요청이 서로 독립적으로 운영되는 두 개의 홉, 즉 릴레이(relay)와 게이트웨이(gateway)를 거친다는 데 있다. 릴레이는 암호화된 요청을 내용은 보지 못한 채 그대로 전달하면서 클라이언트 식별자를 떼어낸다. 게이트웨이는 암호화된 요청을 복호화하고 응답을 다시 암호화하는 작업을 맡아, 앱 서버가 OHTTP 요청을 평범한 HTTP처럼 처리할 수 있게 해준다. 릴레이와 게이트웨이의 신뢰를 분리하는 이 구조 덕분에 어느 한 주체도 클라이언트 식별자와 요청 내용을 동시에 보지 못한다.
요청과 응답은 단순 포워딩이 아니라 하이브리드 공개키 암호화(HPKE)로 캡슐화된다. 평문은 오직 클라이언트와 앱 서버만 볼 수 있고 릴레이에는 암호문 덩어리만 지나간다. 결과적으로 릴레이는 클라이언트 식별자만, 게이트웨이와 앱 서버는 요청 내용만 보는 '이중 차단(double-blind)' 모델이 성립한다. 여러 사용자가 같은 릴레이를 거치면 앱 서버는 어떤 요청이 누구에게서 왔는지 구분하기 어려워져 활동을 특정 개인에게 되짚는 능력이 제한된다.
왜 릴레이가 아니라 게이트웨이인가
클라우드플레어는 2022년 릴레이 제품을 먼저 내놓았고, Flo Health의 익명 모드나 애플의 Private Cloud Compute가 이를 활용한 사례로 언급된다. 그러나 이미 앱 서버를 클라우드플레어 뒤에 두고 있는 고객은 클라우드플레어가 운영하는 릴레이를 함께 쓸 수 없었다. 그럴 경우 클라우드플레어가 클라이언트 메타데이터와 복호화된 요청 내용을 모두 보게 되어 OHTTP의 프라이버시 모델이 깨지기 때문이다. 이런 고객에게는 릴레이가 아니라 게이트웨이가 필요하다.
게이트웨이를 직접 구축·운영하는 일은 생각보다 까다롭다. 프록시 구조는 홉이 하나둘 늘면서 지연이 생기고, 요청 복호화와 응답 암호화 비용까지 더해지면 자체 구축 환경의 지연 손실이 상당해진다. 클라우드플레어는 1.1.1.1이나 iCloud Private Relay를 떠받치는 인프라를 근거로 자신들이 이 문제를 풀기에 유리하다고 본다. 애니캐스트 방식 덕분에 게이트웨이가 글로벌 엣지의 모든 서버에서 돌아가 릴레이-게이트웨이 홉 지연을 줄이고, CDN을 함께 쓰면 복호화와 앱 서버 처리가 같은 머신에서 이뤄져 게이트웨이-오리진 지연도 아낀다는 설명이다.
개발자가 실제로 마주할 설정
게이트웨이는 존(zone)의 유료 부가 기능으로 제공되며, 클라이언트는 /.well-known/ohttp-gateway 엔드포인트로 OHTTP 요청을 보낸다. OHTTP가 아닌 트래픽은 게이트웨이를 거치지 않고 그대로 서버로 간다. 표준 OHTTP와 청크 방식을 모두 지원하는데, 요청을 조각 단위로 점진 처리할 수 있는 청크 방식이 성능상 권장된다. 키 관리는 전면 위임되어 공개 HPKE 키 설정을 GET 요청에 대한 응답으로 제공한다. 또한 게이트웨이를 존에 바인딩해 특정 존으로 온 요청이 임의의 외부 도메인을 겨냥하지 못하게 막아 악용을 차단한다.
릴레이 인증도 설계에 들어가 있다. 게이트웨이는 설계상 클라이언트를 거의 알지 못하므로 릴레이가 책임 있게 트래픽을 전달한다고 신뢰할 수밖에 없다. 클라우드플레어는 복호화 전에 제로 트러스트 제품인 Access가 먼저 작동하도록 해 상호 TLS, 정적 서비스 자격증명, 커스텀 외부 로직 같은 표준 정책으로 들어오는 트래픽을 인증하게 했다. 나아가 고객이 실수로 릴레이와 게이트웨이를 모두 클라우드플레어에서 돌려 신뢰 분리를 깨는 상황을 막기 위해, 게이트웨이는 Workers나 클라우드플레어의 프록시 호스트에서 온 요청은 복호화를 거부한다.
남는 한계
주의할 지점도 분명하다. OHTTP는 네트워크 수준의 프라이버시를 제공할 뿐 요청 본문은 건드리지 않는다. 따라서 이메일이나 사용자명 같은 식별 정보를 본문에 담지 않는 책임은 전적으로 개발자에게 있다. 릴레이 역시 '가져와서 써야' 하며, 어떤 인프라에서도 돌릴 수 있지만 클라이언트 식별자가 담긴 로그를 들여다보지 않겠다고 사용자에게 검증 가능하게 약속하는 일이 핵심 난제로 남는다. 이를 스스로 보장하기 어렵기 때문에 전용 릴레이 제공자를 찾게 되는 것이다. 자체 서버를 클라우드플레어 뒤에 두거나 Workers로 만든 경우, 혹은 애플 LiveCallerID SDK처럼 서드파티 클라이언트와 릴레이로부터 OHTTP를 받는 용도라면 게이트웨이가 더 맞는 선택이라는 게 회사의 정리다. 현재는 대기자 명단을 통한 클로즈드 베타 단계이며, 가격과 정식 출시 조건은 아직 공개되지 않았다.