Tor 써도 정체가 드러난다? 파이어폭스 IndexedDB에서 새어나온 식별자

익명성의 전제가 흔들렸어요

Tor 브라우저를 쓰는 이유는 단 하나, "추적당하지 않기 위해서"죠. 창을 닫고 새로 열면 완전히 다른 사용자처럼 보여야 하고, 툴바의 "새 신원(New Identity)" 버튼을 누르면 이전 세션과 연결고리가 끊어져야 해요. 그게 Tor가 약속하는 핵심 가치고요.

그런데 핑거프린트닷컴(Fingerprint.com) 연구팀이 최근 공개한 분석에 따르면, 파이어폭스 기반 Tor 브라우저에서 이 모든 격리를 뚫고 같은 브라우저를 식별할 수 있는 안정적인 ID가 남는다고 해요. 프라이빗 창을 새로 열어도, 신원을 갱신해도 그대로 유지되는 식별자예요. 뭐가 어떻게 된 일인지 차근차근 풀어볼게요.

문제의 범인은 IndexedDB

핵심 열쇠는 IndexedDB라는 브라우저 내장 데이터베이스예요. 이게 뭐냐면, 웹사이트가 사용자 브라우저에 대용량 구조화 데이터를 저장할 수 있도록 해주는 API인데요. 오프라인 웹앱, PWA 같은 걸 만들 때 자주 쓰죠. 원칙적으로 이 저장소는 "origin별로 격리"되고, 프라이빗 모드나 New Identity를 누르면 초기화되는 게 정상이에요.

그런데 연구팀이 발견한 건, 파이어폭스가 IndexedDB의 내부 파일 경로와 데이터베이스 이름을 만들 때 브라우저 프로파일 수준에서 공유되는 식별자를 활용한다는 거예요. 이 내부 식별자는 프라이빗 창을 열어도, New Identity 버튼을 눌러도 초기화되지 않고 남았어요. 결과적으로 추적자가 IndexedDB 관련 동작을 유도하는 자바스크립트를 페이지에 심어두면, 같은 브라우저에서 접속한 Tor 세션끼리 연결지을 수 있게 되는 거예요.

쉽게 비유하자면 이런 상황이에요. 가면을 쓰고 매번 다른 가명으로 가게에 들어갔는데, 신발에 찍힌 고유한 로고가 매번 같아서 점원이 "아, 이 분 또 오셨네"하고 알아보는 상황이요. 가명과 옷차림은 바뀌었지만 신발은 그대로였던 거죠.

이런 사이드 채널은 왜 자꾸 생길까

비슷한 종류의 이슈는 과거에도 여러 번 있었어요. HSTS(HTTPS 강제) 캐시를 악용해 사용자를 추적한 사례, TLS 세션 티켓을 통한 재식별, 폰트 렌더링 미세 차이를 이용한 캔버스 핑거프린팅 같은 것들이요. 사파리는 ITP(Intelligent Tracking Prevention)로, 파이어폭스는 ETP(Enhanced Tracking Protection)로 대응해왔지만, 브라우저 내부 구현의 "상태(state)"가 프로파일 단위로 누수되는 문제는 여전히 구석구석 숨어있어요.

Tor 프로젝트는 보통 파이어폭스 ESR 버전 위에 자체 보안 패치를 덧붙이는 방식인데, 이런 저수준 구현 이슈는 업스트림 파이어폭스가 고치기 전까지는 완전히 막기 어려워요. 보고된 이후 Mozilla와 Tor 팀 양쪽에 제보가 들어간 상태라고 해요.

웹 개발자가 챙겨야 할 점

이 뉴스가 우리에게 주는 교훈은 명확해요. 브라우저 스토리지 API의 격리는 생각보다 완벽하지 않다는 것, 그리고 내 서비스가 의도치 않게 사용자 식별에 기여할 수 있다는 것이에요. 특히 IndexedDB, localStorage, ServiceWorker 캐시 같은 지속성 저장소에 사용자 식별 가능한 메타데이터를 넣지 않는지 한 번 점검해보시면 좋겠어요.

보안이 중요한 서비스를 운영한다면, 익명성 보장이 필요한 사용자(내부 제보자, 활동가 등)에게 "Tor만으로 안심하지 말고 Tails OS처럼 세션 자체가 휘발성인 환경을 병행하라"고 안내하는 것도 좋은 가이드가 될 거예요.