요약

  • 사이트는 오류 없는 HTTPS 연결에서 Strict-Transport-Security를 보내고, 브라우저는 이후 방문에 적용할 규칙을 저장했다. RFC 6797은 아직 알지 못하는 호스트로 가는 첫 HTTP 요청을 중간자 공격의 틈으로 지목했다.
  • Chromium 팀은 2011년 Gmail로 향하는 최초 이동도 HTTPS로 처리하겠다고 발표했다. 2012년 RFC는 브라우저 제작사가 미리 담아 배포하는 HSTS 목록을 그 첫 방문 문제의 대응책으로 설명했다.

규칙은 답장에 실려 왔다

Collin Jackson과 Adam Barth는 2008년 ForceHTTPS 논문에서 사이트나 이용자가 브라우저에 엄격한 HTTPS 처리를 요구하는 방법을 제안했다. Firefox 확장 기능의 시험판은 비보안 연결을 HTTPS로 돌리고, 인증서 오류에서는 접속을 끊고, 안전하지 않은 삽입 콘텐츠를 막았다. 당시 브라우저는 설정이 엉성한 사이트와의 호환성을 위해 보안 경고를 클릭해서 넘길 수 있게 했다. 연구진은 그런 타협을 원치 않는 사이트의 의사를 브라우저가 따르게 하려 했다.

RFC 6797은 요청을 Strict-Transport-Security 응답 헤더로 정리했다. 브라우저는 오류 없는 HTTPS 연결에서 헤더를 받았을 때만 해당 호스트를 max-age 동안 기억하고 다음 요청을 HTTPS로 바꾼다. 헤더가 일반 HTTP로 오면 무시해야 한다. 열린 통신 구간을 장악한 공격자가 자신을 막을 규칙을 쓰거나 지우게 둘 수 없기 때문이다.

문제는 첫 답장이 오기 전이다. 사람이 도메인을 입력하거나 http 링크를 누를 때 브라우저가 그 사이트를 모르면 최초 요청은 보호되지 않은 채 나갈 수 있다. RFC는 이를 시작 단계의 중간자 공격 취약점이라고 불렀다. 서버의 명령은 답장에 있고, 첫 요청은 이미 길을 건넜다. 나중에 HTTPS로 옮겨도 그 요청을 되찾을 수 없다.

목록은 브라우저와 함께 출발했다

Chromium 보안팀의 2011년 6월 발표는 두 가지 방법을 보여줬다. Chromium 12에서는 숙련된 이용자가 원하는 도메인에 HTTPS를 강제할 수 있었다. Chromium 13에 대해서는 gmail.com이나 mail.google.com을 주소창에 프로토콜 없이 입력한 첫 이동까지 Gmail의 모든 연결을 HTTPS로 처리하겠다고 했다. 그 도메인의 인증서 오류도 경고를 클릭해 넘길 수 없게 한다고 설명했다. 사이트가 답하기 전에 브라우저가 이미 결정을 내린 셈이다.

RFC 6797의 12.3절은 사이트 관리자가 브라우저 제작사에 정책을 소프트웨어와 함께 배포해 달라고 요청할 수 있는 HSTS 사전 탑재 목록을 설명한다. Chromium의 HSTS 문서는 새로 설치한 브라우저나 저장 상태를 지운 브라우저에 남는 첫 방문의 틈과 목록의 역할을 적는다. 사이트는 HTTPS를 운영한다. 제작사는 어떤 이름을 사용자의 브라우저에 미리 넣을지 정한다.

이때부터 첫 요청은 소프트웨어 배포의 문제가 됐다. 서버 헤더는 안전하게 도착한 뒤의 방문을 다뤘고, 내장 목록은 도착 전의 방문을 다뤘다. 당시 Chromium 13의 목록과 첫 방문 트래픽 기록이 있으면 실제 보호 범위를 알 수 있다. 원문 기록만으로도 결정권이 어느 쪽으로 움직였는지는 분명하다.

출처