Cloudflare, OHTTP Gateway 공개 베타 출시
Cloudflare Ohttp Gateway
Cloudflare가 OHTTP Gateway의 클로즈드 베타를 시작했다. 기존 OHTTP Relay와 달리 Gateway는 Cloudflare가 직접 운영해, 앱 서버가 Cloudflare 뒤에 있는 고객도 신뢰 분리 원칙을 지키며 OHTTP를 도입할 수 있다. 글로벌 엣지 네트워크에 배포돼 지연을 최소화하고, Cloudflare Access로 릴레이 인증을 지원한다. 관심 있는 고객은 대기자 명단에 등록할 수 있다.
우리는 인터넷 전반의 프라이버시 기준을 높이기 위해 노력하고 있으며, OHTTP 같은 프로토콜이 도움이 될 수 있다고 믿습니다. 단, 도입이 충분히 쉬워야 합니다.
HN 토론
76- robertlagrant
Cloudflare의 평소 훌륭한 글쓰기보다는 조금 떨어지네요.
그건 그렇고 — 구글 추적 코드가 삽입된 웹사이트에는 확실히 도움이 안 되겠죠? 어차피 그런 사이트들이 당신을 추적하는 종류의 사이트인데?
- simondotau
Cloudflare가 비밀 CIA 작전이라고 생각할 이유는 전혀 없습니다. 사실 그렇지 않다고 생각할 충분한 이유가 많다는 것도 확신합니다. 하지만 만약 그렇다면, Cloudflare가 하는 거의 모든 일은 CIA 작전에서 기대할 수 있는 것과 정확히 일치합니다.
- jt2190
> 한편, 일부 앱 개발자들은 사용자에 대해 알고 싶지 않은 것 이상으로 알게 됩니다: 전형적인 클라이언트-서버 교환은 클라이언트의 IP 주소나 TLS 지문 같은 사용자 데이터 흔적을 남깁니다. 이러한 수준의 가시성은 부담이 될 수 있습니다.
여기서 "부담"에 대해 누군가 설명해 줄 수 있나요? 제가 떠올리는 시나리오는 "이제 로그 파일을 안전하게 저장해야 하는데 그건 정말 귀찮은 일이다" 같은 겁니다. 하지만 이게 제가 이걸 사용할 이유의 가장 좋은 예시는 아닌 것 같네요. (수정: Signal 같은 서비스를 위한 보안 메시징 서버?)
- 0x073
Cloudflare가 인터넷의 절반을 위한 게이트웨이라면, 나머지 절반은 Meta, Google, Microsoft입니다. 저는 제가 방문하는 웹사이트에 제 IP를 공유하는 게 어떤 거대 기술 기업들에게 공유하는 것보다 낫습니다.
하지만 어쩌면 제가 프라이버시를 잘못 이해하고 있는 걸 수도 있겠네요.
- nirui
> 클라이언트와 앱 서버만 평문을 볼 수 있고, 릴레이는 암호문 덩어리만 봅니다. "게이트웨이"가 릴레이와 앱 서버 사이에 위치해 이 모든 암호화를 처리합니다 — 요청을 캡슐 해제하고, 응답을 캡슐화합니다 — 그리고 앱 서버는 평범한 HTTP만 처리합니다.
암호화와 복호화를 원본 서버(RFC에서는 Target Resource라고 함)와 클라이언트가 처리하도록 하는 oblivious 암호화 방식을 설계하면 더 낫지 않을까요? 중간에 있는 누군가가 그 데이터를 처리하도록 하는 대신에요?
그들의 현재 설계는 공개 익명 SOCKS5 서버(TLS 트래픽을 복호화하지 않음)에 연결해서 Cloudflare 뒤에 호스팅된 웹사이트에 접속하는 것과 크게 다르지 않아 보입니다. 아마 똑같이 작동할 겁니다. 왜냐하면 누군가는 익명 SOCKS5 서버를 호스팅하는 것과 같은 방식으로 "OHTTP Relay"를 호스팅해야 하니까요.