TLS 세션 재개: 당신을 추적하는 속도 최적화
왕복 한 번을 아끼려고, 브라우저는 서버가 다음 방문 때 자기를 알아보게 한다 — 쿠키 항아리 밑, TLS 계층에서. 수년간 그 최적화는 슈퍼쿠키였고, 그게 고쳐진 과정은 신원이 실제로 어디서 새는지에 관한 교훈이다.
블로그
프로토콜, 보안 사건, 그리고 인터넷이 실제로 작동하는 방식. 147편.
시팅덕스: 등록기관을 건드리지 않고 도메인을 빼앗다
훔친 비밀번호도 없었고 등록기관 기록도 그대로였다. 그런데도 수만 개 도메인이 넘어갔다 — 누구든 요청만 하면 존을 내주는 DNS 제공자에게 위임해 둔 탓이었다.
폴리필 공격의 정체는 도메인 매매였다
뚫린 서버는 없었다. 2024년 2월 어떤 회사가 polyfill.io 도메인을 샀고, 넉 달 뒤 그 도메인은 10만 개가 넘는 사이트에 조용히 악성코드를 뿌렸다. 공격은 곧 그 구매였다.
이메일 인증은 더 이상 선택이 아니다
20년 동안 SPF·DKIM·DMARC는 무시해도 되는 권고였다. 그러다 14개월 만에 지메일·야후·아웃룩이 그것을 입장료로 바꿨다 — SMTP는 1바이트도 건드리지 않고.
0-RTT: TLS 1.3에서 유일하게 리플레이 보호를 되판 기능
TLS 1.3은 거의 모든 걸 더 안전하게 만들었다. 그런데 0-RTT early data는 설계상 리플레이가 된다 — 그리고 이걸 '안전하게' 쓰는 표준 방법은 대부분의 앱이 깨는 약속 위에 서 있다.
당신의 인증서 체인은 깨져 있고, 크롬이 숨겨 준다
적지 않은 HTTPS 사이트가 불완전한 인증서 체인을 보낸다. 그래도 크롬에선 멀쩡히 열린다 — 크롬이 빠진 조각을 몰래 받아 오기 때문이다. 그러지 않는 모든 클라이언트에서 버그가 터진다.
빠진 밑줄 하나와 24시간 시계
2024년, DigiCert는 검증 단계에서 밑줄 하나가 빠진 걸 발견하고 24시간 안에 인증서 8만 3천 장을 폐기해야 했다. 한 고객은 그걸 막으려 법원에 갔다. 진짜 이야기는 그 오타가 아니다.
DNSSEC 채택률은 레지스트리 할인 지도다
.nl 도메인은 60% 안팎이 DNSSEC를 켜는데 .com은 4%쯤이다. 프로토콜 때문이 아니다. 돈을 따라가라 — 채택률은 레지스트리가 등록기관에 서명 값을 치르는지를 따라간다.
글루 레코드: DNS의 부트스트랩 역설
example.com을 찾으려면 그 네임서버에 물어봐야 하는데, 그 네임서버는 example.com 안에 산다. 모든 도메인 뿌리에 놓인 순환 의존성이다. 그리고 그걸 푸는 건 대부분 고장 나기 전까진 눈에 띄지도 않는, 작고 깨지기 쉬운 장치 — 글루 레코드다.
이제 폐기된 인증서 전부가 당신 브라우저 안에 들어간다
Firefox 137이 모두에게 CRLite를 켰다: 웹 전체의 인증서 폐기 목록을 수 메가바이트로 압축해 로컬에서 확인한다. 확률적 필터가 정확한 답을 내놓게 만드는 트릭을 뜯어본다.
데비안 OpenSSL 사건: 두 줄, 그리고 32,767개의 키
거의 2년 동안 데비안과 우분투에서 OpenSSL로 만든 모든 키는 32,767개짜리 목록에서 고를 수 있었다 — 메모리 검사기 경고를 없애려던 정리 작업이 무작위성을 섞어 넣던 그 한 줄을 지웠기 때문이다.
존 전송은 당신의 DNS 지도를 통째로 넘긴다
DNS는 이름을 알아야 물어볼 수 있게 만든다 — 존 전체를 목록으로 뽑는 명령은 없다. 단 하나, AXFR만 빼고. 이걸 열어 두면 낯선 사람이 네임서버에게 전화번호부 전체를 부쳐 달라고 요청할 수 있다.