안드로이드17, ECH 기본 탑재로 ISP조차 접속 사이트 못 보게 막는다

HTTPS는 오랫동안 “브라우징을 안전하게 지켜준다”고 알려졌지만, 정작 어떤 웹사이트에 접속했는지는 그동안 인터넷 서비스 제공업체(ISP)에게 그대로 노출됐다. 암호화 연결이 시작되기 직전 오가는 첫 신호에 목적지 사이트 주소가 평문으로 담겨 있었기 때문이다. 구글은 8월 27일(현지시각) 안드로이드17에 담긴 네트워크 보안 개선 사항 네 가지를 정리해 공개했다. 그 중 핵심은 암호화된 클라이언트 헬로(Encrypted Client Hello, ECH)를 운영체제 차원에서 기본 탑재한 것이다. 안드로이드는 이 표준을 개별 브라우저나 앱이 아니라 OS 전체에 심은 첫 주요 모바일 플랫폼이 됐다.

HTTPS에 뚫려 있던 SNI라는 구멍

TLS 핸드셰이크(암호화 연결을 맺기 위한 사전 협상 절차)의 첫 메시지인 클라이언트헬로(ClientHello)에는 서버 이름 지시자(Server Name Indication, SNI)라는 필드가 있다. 이 필드는 접속하려는 사이트의 호스트명을 담고 있다. 서버가 암호화를 시작하기 전 어떤 인증서를 내줘야 하는지 판단하려면 반드시 필요한 정보다. 문제는 이 필드가 암호화되지 않은 평문 그대로 오간다는 점이다. SNI는 2003년 RFC 3546으로 규정됐다. 하나의 IP 주소로 여러 HTTPS 도메인을 운영하는 공유 호스팅을 위해 만들어진 설계였지만, 이후 수년간 ISP가 이 메타데이터로 광고 사업을 벌이는 결과로 이어졌다.

2021년 미국 연방거래위원회(FTC)가 미국 모바일 인터넷 시장의 약 98%를 차지하는 주요 ISP 6곳을 조사한 보고서가 이를 뒷받침한다. 보고서에 따르면 이들 업체는 도메인·브라우징 메타데이터를 지속적으로 수집해 위치 정보, 앱 사용 내역, 기기 간 신호와 결합한 뒤 타깃 광고 플랫폼을 통해 수익화하고 있었다. 일부 ISP는 브라우징 기록을 TV 시청 기록과 결합해 광고 타깃팅에 활용했고, 실시간 위치 데이터를 자동차 판매원이나 보석보증업체 같은 제3자 고객사에 공유한 사례도 확인됐다. VPN을 쓰거나 완전히 암호화된 HTTPS 사이트에 접속해도 이 감시망을 피할 수 없었다. SNI 필드가 암호화된 페이로드 바깥에 위치했기 때문이다.

ECH, 진짜 목적지를 가짜 뒤에 숨긴다

ECH는 TLS 1.3의 확장 기능으로 지난 3월 IETF 표준 RFC 9849로 공식 발행됐다. 클라우드플레어(Cloudflare), 패스틀리(Fastly), 모질라(Mozilla)와 학계 연구자, 표준화 기구가 여러 해에 걸쳐 함께 개발했다. 방식은 클라이언트헬로 메시지를 두 개로 쪼개는 것이다. 바깥쪽 헬로(ClientHelloOuter)는 암호 방식이나 TLS 버전 같은 민감하지 않은 정보와 함께, 실제 목적지 대신 콘텐츠 전송 네트워크(CDN)를 가리키는 공용 이름을 담는다. 안쪽 헬로(ClientHelloInner)에는 진짜 목적지 호스트명이 담기는데, 목적지 서버가 DNS에 공개한 공개키로 암호화된다. 이 값을 풀 수 있는 건 해당 개인키를 가진 목적지 서버뿐이다. 중간에서 트래픽을 들여다보는 통신사나 와이파이 운영자, 패킷 감청 프로그램은 바깥쪽 껍데기만 보게 된다.

서버는 암호화된 안쪽 헬로를 자신의 키로 풀어보고, 성공하면 실제 요청을 처리한다. 복호화에 실패하거나 서버가 ECH를 지원하지 않으면 바깥쪽 헬로가 일반 연결처럼 처리된다. 클라이언트는 서버 응답에 담긴 작은 확인 신호로 자신의 진짜 요청이 통과됐는지, 아니면 가짜 이름과만 통신했는지 판단한다. 프라이빗 DNS까지 함께 켜두면 통신사나 와이파이 운영자는 어떤 CDN이 트래픽을 처리하는지, 데이터가 얼마나 오갔는지만 볼 수 있을 뿐 구체적으로 어떤 사이트나 앱에 접속했는지는 알 수 없게 된다.

안드로이드17, OS 전체에 기본 내장…검열 우회 테스트도 통과

크롬과 파이어폭스는 각각 버전117(2023년 9월), 버전118(2023년 9월)부터 이미 ECH를 지원해왔다. 안드로이드17은 이를 브라우저 단위가 아니라 운영체제 차원으로 끌어올렸다는 점에서 다르다. API 레벨37(안드로이드17)을 대상으로 하는 앱이 OkHttp 5.5.0이나 구글의 HttpEngine 같은 호환 네트워킹 라이브러리를 쓰면 별도 설정 없이 ECH 보호가 자동으로 적용된다. 다만 아직 낡은 라이브러리를 쓰는 개발자의 앱은 이 보호를 이용자에게 전달하지 못한다. 구글은 파트너들과 함께 전환을 앞당기는 작업을 진행 중이라고 밝혔다.

ECH만으로는 구조적 약점이 남는다. 일부 연결만 ECH를 쓰면 관찰자가 트래픽 형태만 보고 ECH 적용 연결을 골라내 선택적으로 차단할 수 있다. 이런 방식은 검열 당국이나 네트워크 중간 장비가 표준 확산을 막는 데 쓸 수 있는 전략이다. 안드로이드17은 이를 막기 위해 ECH 그리스(ECH GREASE)를 기본 탑재했다. 실제 목적지 정보가 없더라도 ECH를 지원하지 않는 서버로 가는 연결에도 가짜 ECH 확장을 무작위로 덧붙이는 방식이다. 겉에서 보면 모든 연결이 똑같은 모양을 하게 돼, 진짜 ECH와 가짜 ECH를 구분할 수 없다.

알파벳(Alphabet)의 기술 인큐베이터 지그소(Jigsaw)는 이 방식을 전 세계 상위 1만 개 웹도메인, 202개국, 러시아·중국을 포함한 740개 통신사 대상으로 검증했다. 그 결과 표준 TLS 대비 연결 실패가 전혀 없었고, 네트워크 방해율은 사실상 0%로 나타났다. ECH 표준 공동 저자이자 크립토그래피 컨설팅(Cryptography Consulting LLC) 설립자인 닉 설리번(전 클라우드플레어 리서치 총괄)은 “안드로이드의 ECH 지원은 인터넷에 남아있던 가장 큰 구조적 개인정보 보호 구멍 중 하나를 닫는 중요한 발걸음”이라고 말했다. 시그널(Signal) 최고기술책임자 에런 크레트(Ehren Kret)도 “사용자 보호를 위한 결정적 진전”이라며 개발자들에게 생태계 전반의 도입을 앞당겨달라고 요청했다.

남은 빈틈…ISP는 여전히 접속 시점과 트래픽량은 본다

ECH가 막는 건 호스트명뿐이다. DNS 조회 과정은 프라이빗 DNS를 함께 켜지 않으면 여전히 평문으로 노출된다. 브라우저 핑거프린팅 같은 다른 추적 수단도 별도로 막아야 한다. 통신사나 와이파이 운영자는 ECH가 적용된 연결에서도 목적지 IP 주소, 접속 시각, 오간 데이터량 같은 메타데이터는 계속 볼 수 있다. 이 정보만으로도 어떤 서비스에 접속했는지 추정할 수 있는 경우가 있다는 점은 한계로 남는다.

기능이 잘 동작하는지 확인하려면 별도의 설정 화면에서 토글을 찾을 필요는 없다. 크롬이나 파이어폭스에서 crypto.cloudflare.com/cdn-cgi/trace에 접속해 응답에 나오는 sni= 항목을 확인하면 된다. 값이 encrypted로 표시되면 해당 연결에서 ECH가 정상 작동했다는 뜻이다. 다만 이 방법은 상대 사이트가 ECH를 지원할 때만 유효하며, 지원하지 않는 사이트로 테스트하면 실제로는 정상 작동 중이어도 결과가 다르게 나올 수 있다.