파이어폭스가 차단한 슈퍼쿠키를 알아봅시다.

파이어폭스 85 버전 업그레이드 이후 나온 공지를 통해 “Cracks down Supercookies – 슈퍼쿠키 단속 한다.”라고 밝혔습니다.

수많은 브라우저들과 광고 차단 프로그램들이 그동안 기본적으로 쿠키를 손쉽게 차단해주었고 우리에게도 익숙한 부분이지만, 슈퍼쿠키라니?? 맛있어 보입니다.

슈퍼쿠키 엄청 큰 쿠키인가요?

쿠키는 우리가 웹사이트에 접속하고 활동할때 생기는 정보가 담긴 파일 입니다. 인터넷을 하다 보면 여기저기서 보이는 광고에서 내가 아까 검색했던 물건이 나오거나 내가 평소 관심을 갖고 보던 물건이 올라오는 경험을 많이 해보셨을텐데요. 모두 광고회사가 쿠키를 활용한 방법 입니다.

슈퍼쿠키는 방문 기록이나 쿠키 삭제 버튼을 눌러서 청소를 해도 찾거나 삭제하기 힘든 곳에 숨어서 비슷한 역할을 하는 스파이같은 녀석입니다. 슈퍼쿠키가 만들어지면 사생활 보호 모드로 들어가도 정보 추적이 가능하고 쿠키 생성을 거부한 곳에서도 못된 짓을 할수 있다고 하네요.

그리고 우리가 수동으로 신경써서 없애버리지 않는다면 계속 숨어서 기생한다고 합니다.

HSTS(HTTP Strict Transport Security, 접속자가 HTTPS 보안 접속을 강제할 수 있게 해주는 역할)가 보안을 위해 나온 또 하나의 기능인데 슈퍼쿠키는 이것도 활용한다고 하네요.

HTTPS 접속을 강제로 시키려면 해당 도메인이 저장 및 설정이 되어있어야 하는데, 이 정보가 유저의 방문 기록 추적 도구로 악용이 될 가능성도 있다고 하니 나날이 복잡해져가는 환경에 피로감이 느껴집니다.

HSTS와는 다른 HPKP(HTTP Public Key Pinning), 중간자 공격(여기에선 중간에서 인증서를 탈취 및 변조를 통해 빈틈을 노리는 것)을 막기 위해 최종 서버의 인증서를 통해 암호화 통신을 할 수 있도록 고정(Pinning)하는 것도 있지만 이 역시 악용이 될 수 있다고 해요.

예전 글들을 보면 HSTS 설정을 하면 슈퍼쿠키를 막을 수 있다고 하지만 슈퍼쿠키가 브라우저 핑거프린트, Etags, 플래시 저장소, 로컬 저장소, HSTS 플래그, 각종 캐쉬 파일 등을 통해서 식별 정보를 저장한다고 하는데 공격 수비 모두 넘사벽 굇수형님들의 영역이라 저같은 일반인들은 읽기에도 벅찹니다.

중요한것은 파이어폭스가 슈퍼쿠키를 차단해주겠다고 발표했다는것.

슈퍼쿠키는 완벽하게 제거나 차단이 될까?

“Firefox 85에서 변경 한 사항은 추적기가 웹사이트에서 사용할 수있는 기능을 제거함으로써 캐시 기반 슈퍼 쿠키의 효율성을 크게 줄였습니다.”라고 이야기하는 것을 보면 아직 완벽하진 못한듯 하지만 이런 시도 자체가 너무나 감사한 부분이라고 생각합니다.

저의 사적인 감정을 조금 섞어서 이야기 하면 파이어폭스는 앞으로도 계속 존재해줘야하는, 우리가 꼭 지켜야할 웹브라우저라고 생각합니다.(파이어폭스는 기부도 받습니다. https://donate.mozilla.org/ko/)

다시 슈퍼쿠키 이야기로 돌아와서.. 파폭이 슈퍼쿠키를 추적 및 차단하는 방법과 원리는 제가 전부다 알순 없지만. 발표된 내용을 보면 교차 사이트 추적을 차단하는 캐시 파티셔닝을 도입하여 ‘슈퍼 쿠키’를 단속한다고 합니다.

우선 아래의 캐시들을 모두 파티셔닝 됩니다.

HTTP 캐시, 이미지 캐시, DNS 캐시, HTTP 인증 캐시, 스타일 시트 캐시, 파비콘 캐시, HSTS 캐시, OCSP 캐시, 글꼴 캐시, Alt-Svc 캐시, TLS 인증서 캐시 등

Cache를 파티셔닝과 슈퍼쿠키는 무슨 관계?

웹페이지 로딩 성능을 높이려면 3R 즉 Request, Resource, Rendering을 줄여야 하는데 웹브라우저들 역시 성능 향상을 위해 이런 부분을 활용 합니다.

예를 들어서 A 커뮤니티 사이트에서 어떤 유머짤을 봤고, B 사이트 돌아다니다 같은 이미지를 봤다면 따로따로 이미지를 받아오는게 아니라 두번째는 로컬에 저장된 이미지가 있으니 그걸 불러오는 방식입니다.

슈퍼쿠키는 이런 공유 리소스를 통해서 정보를 얻기도 한다고 합니다. 그래서 파이어폭스 85부터는 같은 이미지라 하더라도 각각 사이트별로 캐시를 따로 관리한다는 것 입니다.

위에 나열한 다른 캐시들도 이런 부분을 위해서 파티셔닝이 된다는 것. pooled connections, prefetch connections, preconnect connections, speculative connections, and TLS session identifiers 등도 모두 마찬가지 입니다.

그럼 반대로 성능 향상을 위해 리소스를 공유했던 부분을 다시 분할 관리하게 된다면 느려지는게 아닐까? 라고 생각이 될수있어요. 평균적으로 0.09%~0.75%이며 최대 1.32%까지 차이가 난다고 하니 평균적으로 우리가 거의 체감할 수 없는 수준입니다.

간단(?)하게 알아봤습니다. 왜냐면 제가 아는게 많지 않거든요. ㅎㅎ