- 앱 서버가 사용자 IP를 알지 않고 요청을 처리할 수 있도록 Cloudflare가 관리형 OHTTP Gateway의 비공개 베타를 시작함
- 서로 다른 운영자가 맡는 릴레이는 사용자 IP만, 게이트웨이는 요청 내용만 보도록 분리해, 어느 한쪽도 누가 무엇을 요청했는지 함께 알 수 없게 함
- Cloudflare CDN이나 Workers를 사용하는 앱도 외부 릴레이와 연결해 도입할 수 있으며, 서버는 별도의 OHTTP 암호화 구현 없이 일반 HTTP 요청을 처리함
- 전 세계 엣지 네트워크에서 암호화 처리를 수행하고 자동 확장과 키 관리를 대행하며, 올가을 도메인별 유료 부가 기능으로 출시할 예정임
- 보호 대상은 IP 등 네트워크 식별 정보이며, 요청에 이메일이나 사용자 이름을 넣으면 익명성이 사라질 수 있어 앱에서도 식별 정보를 보내지 않도록 설계해야 함
- 일반적인 클라이언트와 서버 통신은 IP 주소와 TLS 지문 같은 사용자 데이터를 남김. 사용자는 추적이나 맞춤형 광고를 피하기 위해 VPN, 쿠키 비활성화, 광고 차단기 등에 의존하고, 개발자는 필요 이상으로 사용자 정보를 알게 됨
- OHTTP는 앱 백엔드가 사용자 IP 주소를 보지 않고 HTTP 요청을 받도록 설계된 IETF 표준임
- Cloudflare OHTTP Gateway는 비공개 베타를 시작했으며, 가을에 zone의 유료 부가 기능으로 출시할 예정임
- 몇 번의 클릭으로 활성화할 수 있는 셀프서비스 제품이며, 대기 명단 등록을 받고 있음
- 2022년에 출시한 OHTTP 릴레이 제품 Privacy Gateway는 역할을 명확히 하도록 Cloudflare OHTTP Relay로 이름을 변경함
- Flo Health는 앱의 Anonymous Mode에 OHTTP를 사용함
- Apple의 Private Cloud Compute는 AI 추론 요청을 사용자 신원과 분리하는 데 OHTTP를 사용함
- 일반적인 통신에서 앱 서버는 패킷의 출발지 IP 주소를 알 수 있고, 지원 TLS 버전이나 암호군을 이용해 클라이언트 지문을 만들 수 있음. 이런 신호로 여러 요청을 같은 사용자와 연결할 수 있음
- OHTTP 릴레이는 클라이언트 IP와 TLS 지문을 보지만, 이를 제거하고 암호화된 요청을 전달함
- 앱 서버에는 최종 사용자가 아닌 릴레이의 IP, ASN, TLS 정보, 위치가 보임
- 예를 들어 미국 캘리포니아주 캠벨에 있는 클라이언트 정보 대신 텍사스주 오스틴에 있는 릴레이 정보가 전달됨
- 여러 사용자가 같은 릴레이를 사용하면 앱 서버가 요청을 개별 사용자와 연결하기 어려워짐
- 단순 전달 프록시와 달리 OHTTP는 HPKE를 사용해 요청과 응답을 암호화 캡슐화함
- 릴레이에는 암호문만 보이며, 게이트웨이는 요청의 캡슐화를 해제하고 응답을 다시 캡슐화함
- 앱 서버는 OHTTP 암호화 처리를 직접 구현하지 않고 일반 HTTP를 처리함
- 이 이중 비공개 모델에서 릴레이는 클라이언트 식별 정보만, 게이트웨이와 앱 서버는 요청 내용만 보게 됨
- OHTTP 개인정보 보호 모델을 지키려면 릴레이와 앱 서버를 서로 공모하지 않는 별도 주체가 운영해야 함
- Flo Health의 Anonymous Mode는 개인 건강 데이터를 사용자 식별 정보와 연결하지 않고 이용할 수 있도록 함
- 개발자들의 사용하기 쉬운 개인정보 보호 인프라 수요가 커지고 있지만, 앱에 네트워크 개인정보 보호를 기본으로 넣는 작업은 여전히 어려움
- 자체 OHTTP 게이트웨이는 추가 네트워크 홉과 암호화 처리 때문에 지연이 커질 수 있으며, 안전하고 성능 좋은 서비스를 대규모로 운영하기도 어려움
- Cloudflare는 1.1.1.1과 iCloud Private Relay를 운영하는 기반 기술을 활용함
- 애니캐스트 방식으로 전 세계 엣지 네트워크의 모든 서버에서 Gateway를 실행해 릴레이와 게이트웨이 사이 지연을 최소화하도록 설계함
- CDN을 사용하는 경우 같은 Cloudflare 물리 서버에서 요청 복호화와 앱 요청 처리가 가능해 게이트웨이에서 원본 서버까지의 지연을 줄일 수 있음
- 기존에는 Cloudflare 뒤에서 앱 서버를 보호하는 고객이 Cloudflare OHTTP Relay까지 사용할 수 없었음
- Cloudflare가 클라이언트 메타데이터와 복호화된 요청 내용을 모두 보게 되어 신뢰 분리가 깨지기 때문임
- 새 Gateway는 이런 고객에게 외부 릴레이를 사용하는 선택지를 제공함
- Gateway는 zone의 /.well-known/ohttp-gateway 엔드포인트에서 OHTTP 요청을 받고, 서비스 용량을 자동으로 확장하거나 축소함
- 올바른 형식의 표준 OHTTP와 청크형 OHTTP를 모두 지원함
- Cloudflare는 요청을 청크 단위로 점진 처리할 수 있는 청크형 OHTTP를 성능상 권장함
- Gateway는 요청을 가로채 복호화하고, 앱 서버에 하위 요청을 보낸 뒤 응답을 암호화해 클라이언트로 반환함
- 일반 HTTP 요청은 Gateway를 거치지 않고 서버로 전달됨
- 게이트웨이를 zone에 결합해 다른 도메인을 대상으로 하는 오용을 막음
- example.com zone으로 보낸 요청은 foo.example.com이나 bar.example.com으로 향할 수 있지만 wikipedia.com으로는 보낼 수 없음
- HPKE 키 관리를 완전히 대행하며, /.well-known/ohttp-gateway에 대한 GET 요청으로 공개 키를 제공함
- 클라이언트는 개인정보 보호를 강화하기 위해 게이트웨이 요청에 사용하는 IP와 다른 IP로 키를 내려받을 수 있음
- 게이트웨이는 클라이언트 정보를 거의 알지 못하므로, 클라이언트 인증과 책임 있는 트래픽 전달을 릴레이에 의존함
- Cloudflare Access를 복호화 전에 실행해 신뢰할 수 있는 릴레이의 요청만 받도록 구성할 수 있음
- 표준 Access 정책으로 상호 TLS, 정적 서비스 자격 증명, 외부 사용자 지정 로직 등을 사용할 수 있음
- 실수로 릴레이와 게이트웨이를 모두 Cloudflare에서 운영해 신뢰 분리를 깨뜨리지 않도록, Cloudflare Workers나 Cloudflare 프록시 호스트에서 온 요청은 복호화를 거부함
- Cloudflare OHTTP Relay와 자체 게이트웨이 조합은 앱 서버가 Cloudflare 외부에 있고, 직접 게이트웨이를 운영할 수 있을 때 적합함
- Cloudflare OHTTP Gateway와 외부 릴레이 조합은 다음 경우에 적합함
- 앱 서버가 Cloudflare CDN 뒤에 있거나 Workers로 구축되어 있음
- Apple LiveCallerID SDK처럼 외부 클라이언트와 릴레이에서 오는 OHTTP 요청을 받아야 함
- 지연과 운영 부담을 줄이기 위해 관리형 게이트웨이를 원함
- 대기 명단 등록 양식으로 출시 알림을 신청하거나 기능 요청을 전달할 수 있음
- 개발자는 OHTTP 클라이언트를 구현해야 하며, ohttp.info와 샘플 클라이언트 라이브러리를 참고할 수 있음
- OHTTP는 네트워크 수준에서만 개인정보를 보호하며, 내부 요청 본문은 변경하지 않음
- 이메일 주소나 사용자 이름 같은 식별 정보를 본문에 보내지 않는 책임은 개발자에게 있음
- 릴레이도 별도로 준비해야 하며, 샘플 코드를 이용할 수 있음
- 릴레이는 어떤 인프라 제공자에서도 실행할 수 있지만, Cloudflare Gateway의 신뢰 분리 제약을 지켜야 함
- 핵심 과제는 클라이언트 식별 정보가 담긴 로그를 들여다보지 않는다는 약속을 사용자가 검증할 수 있도록 보장하는 것임
- 그렇지 않으면 릴레이의 클라이언트 정보와 앱 서버의 복호화된 요청을 연결할 수 있으므로, 전용 OHTTP 릴레이 제공자를 고려할 만함
- 배포 후에는 pvcli 클라이언트로 테스트와 디버깅을 수행할 수 있음