SPF ~all vs -all: 소프트페일 전염병
대부분의 도메인은 SPF 레코드를 ~all로 끝낸다. 실패한 메일을 받아들이라는 뜻이다. SPF 혼자서는 스푸핑을 막을 수 없게 만드는, 안전해 보이는 기본값이다.
더 읽기블로그
프로토콜, 보안, 그리고 인터넷이 실제로 작동하는 방식에 대하여.
DKIM 리플레이: 유효한 서명은 동의가 아니다
2025년 4월, no-reply@google.com에서 유효한 Google DKIM 서명과 DMARC 통과를 달고 피싱 메일이 도착했다. 아무것도 위조되지 않았다. 그게 바로 DKIM의 문제다.
더 읽기NSEC3는 당신의 DNS 존을 숨겨줄 거였다. 못 숨긴다.
이름이 존재하지 않음을 증명하는 DNSSEC의 장치가, 존재하는 이름 목록을 통째로 흘린다. NSEC3는 이름을 해시해 zone walking을 막으려 했지만 — 오프라인 크래킹이 그대로 뚫었다. RFC 9276이 왜 iterations를 0으로 두라고 하는지, 그리고 실제로 통하는 게 뭔지.
더 읽기.internal TLD, 10년 걸려서 나왔는데 절반짜리 해결책이다
ICANN이 2024년 7월 드디어 .internal을 사내망 전용으로 예약했다. .corp·.home을 괴롭히던 name collision 위험은 없앴지만, special-use domain이 아니라 그냥 '예약'이라 쿼리 유출은 여전히 당신 몫이다.
더 읽기BIMI: 그 브랜드 로고는 연 1,000달러의 값을 하는가
받은편지함의 로고는 매년 네 자릿수 비용이 든다 — 프로토콜이 비싸서가 아니라, 두 메일 사업자가 당신과 그림 한 장 사이에 인증기관을 세우기로 결정했기 때문이다.
더 읽기Public Suffix List: 쿠키가 어디까지 갈 수 있는지 정하는 파일
레지스트리가 끝나고 누군가의 웹사이트가 시작되는 지점을 DNS는 알려 주지 않는다. 그래서 웹 전체가 손으로 관리되는 텍스트 파일 하나에 그 경계를 맡긴다 — 쿠키, 인증서, 그리고 누가 누구를 사칭할 수 있는가까지.
더 읽기크롬은 이제 자기 루트 저장소를 돌린다
25년 동안 브라우저는 OS가 신뢰하는 것을 그대로 신뢰했다. 2022년 9월 크롬은 조용히 그 질문을 멈췄고, 2024년 11월 OS가 여전히 신뢰하는 CA 하나를 잘라냈다.
더 읽기이제 인증서 갱신 시점은 CA가 정한다
2020년 Let's Encrypt는 인증서 300만 장을 폐기해야 했지만 '갱신하라'고 알릴 방법이 없었다. 이제 RFC 9773이 된 ACME Renewal Information이 당신 스케줄에 CA의 다이얼을 달았다.
더 읽기Certificate Transparency는 이제 정적 파일로 돌아간다
10년간 모든 TLS 인증서는, 브라우저가 24시간 안에 온라인 상태를 유지하도록 강제하던 살아있는 append-only 암호 데이터베이스에 게시됐다. 2025년, 그 기계는 뜯겨 나가고 버킷 속 정적 파일 폴더로 대체됐다. 더 나은 설계다.
더 읽기인증 기관은 어떻게 죽는가
CA는 대개 해킹으로 죽지 않는다. Entrust는 현대적인 방식으로 죽었다 — 서류 작업으로. 늦은 폐기, 놓친 마감, 그리고 마침내 약속을 믿길 멈춘 브라우저 루트 프로그램.
더 읽기HPKP: 너무 위험해서 폐기된 보안 헤더
HTTP Public Key Pinning은 헤더 하나로 사이트의 TLS 키를 고정하게 해줬다. 동시에 내 도메인을 영구히 벽돌로 만들거나, 공격자가 인질로 잡게도 했다. 브라우저가 죽였다.
더 읽기당신의 시계는 보안 의존성이다
인증서 유효기간, HSTS, DNSSEC 서명, TOTP 코드 — 당신 보안의 놀랄 만큼 많은 부분이 사실은 '지금 몇 시인가'에 대한 주장이다. 그리고 지금 몇 시인지 정하는 프로토콜은 40년간 먼저 답한 놈을 믿어왔다.
더 읽기DNS 0x20: 무작위 대문자로 쓰인 스푸핑 방어책
2023년 구글 리졸버는 조용히 wikipedia.org 대신 wIKiPEDiA.oRG를 묻기 시작했다. 버그가 아니다 — 표준이 되지 못한 채 15년을 버틴 스푸핑 방어 해킹이고, 그럼에도 작동하며, 그 누구의 허락도 필요 없어서 배포됐다.
더 읽기DNS 쿠키: 아무도 켜지 않은 스푸핑 방어책
10여 년 전 DNS는 위조된 응답과 반사 공격을 막을 값싼 방어책을 얻었다. 당신의 리졸버는 거의 확실히 이걸 지원한다. 그리고 거의 확실히 요구하지는 않는다 — '지원'과 '요구' 사이의 그 틈이 이야기의 전부다.
더 읽기ACME: 인증서 발급이 API 호출이 된 과정
TLS 인증서를 받는 건 이메일, 서류, CSR을 웹 폼에 붙여넣는 일이었다. ACME는 그 전부를 새벽 3시에 스크립트가 돌리는 프로토콜로 바꿨다. 그 원리 — 그리고 우리가 맞바꾼 것.
더 읽기KeyTrap: DNSSEC의 '모든 키를 시도하라'가 버그였다
2024년 2월, 조작된 DNS 패킷 하나가 검증 리졸버를 몇 시간 동안 얼릴 수 있었다. 결함은 코딩 실수가 아니라 2000년부터 그대로였던 DNSSEC 명세의 MUST였다.
더 읽기HTTP/2 CONTINUATION Flood: 로그에 남지 않는 DoS
2024년 4월, 한 연구자가 단 하나의 TCP 연결로 Apache·Node.js·Tomcat을 무너뜨릴 수 있음을 보였다. 그 HTTP/2 프레임은 액세스 로그에 남지 않는다. 버그는 코드가 아니라 명세의 이음새에 있었기에 동시에 모든 곳에서 터졌다.
더 읽기BGP 하이재킹으로 남의 TLS 인증서를 위조할 수 있었다. 이제는 어렵다.
오랫동안 CA 근처에서 BGP 경로를 잠깐만 비틀 수 있으면, 소유하지도 않은 도메인의 진짜 브라우저 신뢰 인증서를 발급받을 수 있었다. 2025년, 업계가 마침내 이걸 훨씬 어렵게 만들었다. MPIC가 어떻게 작동하고, 무엇은 못 고치는지.
더 읽기루트 도메인엔 CNAME을 못 건다 (그 이유)
모든 CDN이 루트 도메인을 호스트명으로 향하게 하라고 한다. DNS는 1987년부터 바로 그걸 금지해 왔다 — 그래서 업계는 비표준 편법 더미를 쌓았고, 진짜 해결책은 아직 브라우저에서 안 먹는다.
더 읽기QNAME 최소화: 실제로 배포된 DNS 프라이버시 개선
예전엔 당신과 사이트 사이의 모든 DNS 서버가 당신이 입력한 전체 이름을 봤다 — TLD만 알면 되는 서버까지도. 리졸버 쪽 변경 하나가 그 대부분을 고쳤고, DNSSEC과 달리 누구의 허락도 구하지 않고 배포됐다.
더 읽기Let's Encrypt가 OCSP를 껐다. 아무도 몰랐다.
2025년 8월, 인터넷 최대 CA가 OCSP 응답 서버를 내렸다. 그런데 거의 아무것도 깨지지 않았다 — 온라인 인증서 폐기 확인은 이미 허울뿐이었으니까.
더 읽기SMTP 스머글링: 버그 하나가 SPF·DKIM·DMARC를 뚫었다
2023년 12월, 한 연구자가 원하는 누구든 사칭하는 메일을 보냈고 그 메일은 SPF·DKIM·DMARC를 모두 통과했다. 인증을 깬 게 아니다. 수신 서버가 하나의 연결을 두 통의 메일로 읽게 만들었다.
더 읽기Encrypted Client Hello는 생각보다 덜 감춘다
ECH는 HTTPS가 늘 흘리던 단 하나의 필드 — 사이트 이름 — 를 드디어 암호화한다. 하지만 당신 IP, DNS 조회, 그리고 숨는 군중의 크기가 그게 의미 있는지를 결정한다.
더 읽기HTTP/2 서버 푸시는 죽었다. Early Hints는 덜 함으로써 이겼다
서버 푸시는 HTTP/2의 간판 기능이었다. 브라우저가 묻기 전에 파일을 보낸다. Chrome은 2022년 이걸 뜯어냈다 — 사용률 0.7%, 게다가 자주 더 느려서. 그 자리를 대신한 것은 정반대로 동작했고, 그래서 이겼다.
더 읽기HTTP/2 Rapid Reset: 기능 하나가 DDoS 기록을 깼다
2023년 말, 2만 대짜리 봇넷이 Google·Cloudflare·AWS를 상대로 DDoS 기록을 세웠다. 무기는 대역폭이 아니었다. 설계대로 정확히 동작하는 HTTP/2 기능이었다.
더 읽기Happy Eyeballs: 망가진 IPv6를 숨기는 알고리즘
듀얼스택 클라이언트는 IPv4와 IPv6를 경주시켜 먼저 답하는 쪽을 쓴다. RFC 8305는 연결을 순식간처럼 만들었고 — 동시에 망가진 IPv6를 그걸 운영하는 사람들 눈에서 지워버렸다.
더 읽기Chrome은 DNS를 암호화했다. 검증한 적은 없다.
Chrome에서 보안 DNS를 켜면 리졸버로 가는 파이프가 암호화된다. 돌아온 답이 진짜라는 증명은 전혀 하지 않는다. 암호화와 인증은 다른 문제이고, 브라우저는 조용히 하나만 골랐다.
더 읽기"그냥 DMARC 추가하세요"는 최악의 조언이다
DMARC 레코드를 올리는 건 쉬운 5%다. 스푸핑을 실제로 막는 나머지 — alignment, 리포트 읽기, 집행까지의 느린 걸음 — 를 조언은 통째로 건너뛴다.
더 읽기GREASE: 일부러 아무 의미도 없게 만든 TLS 값들
당신 브라우저는 암호가 아닌 암호와 아무 일도 안 하는 확장을 서버에 하루 수십억 번 제안한다. 이름은 GREASE, TLS가 계속 변할 수 있게 지켜주는 유일한 장치다.
더 읽기TLS 설정을 DNS로 옮겼다. 그런데 DNS는 서명이 안 돼 있다
HTTPS DNS 레코드는 핸드셰이크가 시작되기도 전에 브라우저에 연결 파라미터를 넘긴다 — 어떤 프로토콜, 어떤 IP, 심지어 ClientHello를 암호화할 키까지. 대부분의 도메인에서, 그건 아무도 서명하지 않은 계층으로 도착한다.
더 읽기모든 DNS 제공자는 DNSSEC를 기본값으로 켜야 한다
DNSSEC의 진짜 문제는 암호학이 아니다. DNS 호스트와 등록대행자 사이의 2자 핸드셰이크를 거의 아무도 끝내지 않는다는 것이다. 자동화는 이미 이걸 해결했다.
더 읽기CAA 레코드: 아무도 안 거는 인증서 자물쇠
모든 공개 CA는 2017년부터 CAA 레코드를 지킬 의무가 있다. 공짜에 DNS 한 줄이면 되는데, 9년이 지난 지금도 채택률은 겨우 15%다.
더 읽기보안 헤더 체크리스트는 보안이 아니다
사이트가 모든 헤더 스캐너에서 초록색 A+를 받고도 손쉽게 털릴 수 있다. 체크리스트는 편지가 아니라 봉투를 채점한다 — 그리고 그 틈에 공격이 산다.
더 읽기HTTPS Everywhere는 이겼다. 그게 쉬운 쪽이었다.
2026년 10월, Chrome이 평문 HTTP에 기본으로 경고를 띄우기 시작한다. 15년짜리 캠페인이 끝났다 — 그런데 우리가 푼 건 풀 수 있는 문제였지, 어려운 문제가 아니었다.
더 읽기이메일이 슬랙보다 안전하다
모두가 슬랙을 이메일의 현대적이고 안전한 후계자로 취급한다. 하지만 Enterprise Grid에서 조직 소유자는 당신이 보낸 모든 DM을 — 수정하고 삭제한 것까지 — 내보낼 수 있고, 슬랙은 그걸 할 평문을 쥐고 있다. 이메일의 전송 계층은 1982년산 재앙이다. 그런데도 이메일이 슬랙은 구조적으로 줄 수 없는 것을 준다: 보관 주권(custody). 아무도 변호하지 않는 매체를 위한 변론.
더 읽기무료 npm 패키지 하나 올렸는데, EU 사이버 복원력법이 나한테 적용되나?
EU 사이버 복원력법(CRA)이 이미 발효됐고, 신고 의무는 2026년 9월부터 문다. 당신의 오픈소스 프로젝트에 이게 적용되는지는 두 단어 - '상업적 활동' - 와, 메인테이너를 폭발 반경에서 빼내려고 새로 만든 법적 역할 하나에 달려 있다.
더 읽기Log4Shell는 우리의 서류를 고쳤지, 의존성을 고치지 않았다
패치가 나온 지 4년 뒤에도 Sonatype 조사에서 Log4j 다운로드 여덟 건 중 대략 한 건은 여전히 취약한 버전이었다. 우리는 깨진 의존성을 목록으로 정리하는 데는 아주 능숙해졌고, 그걸 배포하지 않는 데는 거의 나아지지 않았다.
더 읽기WHOIS 프라이버시는 양날의 검이다
GDPR은 2018년에 모두의 WHOIS를 가렸다 — 할머니와 피싱 운영자가 같은 날 같은 익명성을 얻었다. 균형을 맞출 접근 시스템은 2,700만 달러로 추산됐다가 폐기됐다. 검의 한쪽 날만 벼려졌다.
더 읽기버그 바운티는 뒤틀린 인센티브를 만들었다
버그 바운티는 채택된 리포트당 돈을 준다. 그래서 보안이 아니라 채택된 리포트를 최적화한다. 그 틈은 AI 슬롭이 터지기 한참 전부터 조용히 메인테이너를 갈아 넣고 있었다.
더 읽기DNS는 인터넷의 가장 약한 고리다
당신의 DNS를 장악한 사람은 당신 도메인의 유효한 TLS 인증서를 발급받고, 메일을 빼돌리고, 당신 행세를 할 수 있다. 아무도 서명하지 않는 신뢰의 뿌리.
더 읽기SSL Labs A+ 등급은 너무 쉽다
SSL Labs A+는 TLS 채널 설정이 잘 됐다는 증명입니다. 사람들은 이걸 '우리는 안전하다'는 증거처럼 휘두릅니다. A와 A+의 차이는 HTTP 헤더 하나 — 피싱 키트도 그 문턱을 넘습니다.
더 읽기애플 Private Relay는 VPN이 아니다
다들 iCloud Private Relay를 '애플 VPN'이라 부른다. 구조상으로는 오히려 VPN의 정반대에 가깝고, 바로 그 차이가 핵심이다.
더 읽기IPv6는 (완전히는) 끝나지 않는다
2026년 3월 IPv6가 처음으로 Google 트래픽의 50%를 넘었다. 다들 이정표라고 했다. 사실은 영구적 교착 상태의 모양이다.
더 읽기서드파티 쿠키는 죽지 않았다. DNS로 옮겨갔을 뿐.
구글은 5년 동안 서드파티 쿠키를 죽이겠다고 하다가 조용히 포기했다. 별로 중요하지 않았다. 트래킹은 이미 DNS 계층으로 도망쳤고, 당신의 세션 쿠키까지 데려갔으니까.
더 읽기레이트 리밋은 보안 전략이 아니다
레이트 리미터를 직접 만들고 나서, 다들 이게 막아준다고 믿는 그 공격을 전혀 못 막는 걸 지켜봤다. 레이트 리밋은 보안 배지를 단 가용성 통제다.
더 읽기Cloudflare의 장애는 계속 운율을 맞춘다
세 번의 Cloudflare 장애 — 2019년 정규식, 2025년 서드파티 의존성, 2025년 피처 파일 — 은 결국 옷만 갈아입은 같은 장애다: 한 번에 전 세계로 퍼진 변경이, 숨을 곳 없는 버그를 만난 것.
더 읽기BGP 하이재킹: 같은 실수의 역사
1997년 AS7007 사고부터 2022년 KLAYswap 암호화폐 탈취까지, BGP 하이재킹은 매번 같은 빈 자리를 노립니다: 누구도 경로 소유를 증명할 필요가 없다는 것. 그 패턴, 그리고 왜 해결책은 여전히 선택 사항인가.
더 읽기레지스트라는 왜 계속 뚫리는가
2016년, 공격자들이 브라질 대형 은행의 온라인 전체를 5시간 동안 장악했다. 서버는 하나도 건드리지 않았다. 그들은 그냥 도메인 레지스트라에 로그인했다.
더 읽기.io 도메인에는 정치적 문제가 있다
스타트업은 .io를 input/output의 줄임말로 여긴다. 그 두 글자는 사실 지금 넘겨지고 있는 분쟁 중인 식민 영토를 가리키고, 도메인은 그 영토의 존재 위에 얹혀 있다.
더 읽기NIST 새 비밀번호 규칙은 확정됐다. 따르는 곳은 거의 없다.
NIST가 2025년 SP 800-63B-4를 확정했다. 강제 변경 없음, 복잡도 규칙 없음, 최소 15자, 유출 목록 대조 필수. 그런데 회사는 아직도 90일마다 P@ssw0rd1을 돌리게 한다. 표준은 바뀌었다. 행동은 안 바뀌었다.
더 읽기이메일은 고칠 수 없다
SMTP는 1982년, 모두가 서로를 믿던 네트워크를 위해 설계됐다. 그 이후 우리가 원한 모든 보안 속성 — 누가 보냈는지 아는 것, 전송 중 암호화 — 은 교체할 수 없는 프로토콜 위에 선택적 패치로 덧붙여졌다. 이건 아직 못 고친 버그가 아니다. 이것 자체가 이메일의 생김새다.
더 읽기DDoS의 경제학: 왜 공격 한 번이 1만 원인가
작은 사이트를 오후 내내 다운시키는 DDoS 공격 비용은 피자 한 판 값이다. 흥미로운 건 싸다는 사실이 아니라, 그 값을 실제로 누가 치르고 있느냐다 — 공격자는 아니다.
더 읽기2026년의 포트 스캔: 알 수 있는 것과 없는 것
포트 스캔은 정찰의 첫 단계라고들 한다. 2026년에 타깃을 풀 스캔하면 대개 알려주는 건 '방화벽과 로드밸런서 뒤에 있다'뿐이다. 인터넷의 지도는 더 이상 스캐너가 그리지 않는다.
더 읽기무료 SSL 인증서가 피싱을 더 쉽게 만들었다
HTTPS가 돈이 들던 시절엔 피싱 사이트 대부분이 그냥 HTTP였다. 무료 인증서는 TLS를 망가뜨린 게 아니라, 사용자들이 기대고 있던 우연한 신호 하나를 녹여버렸다.
더 읽기RDAP가 WHOIS를 대체하고 있다 (아주 천천히)
WHOIS는 파싱 불가능한 텍스트를 돌려주는 1982년 프로토콜이다. RDAP는 2015년에 그 모든 걸 고쳤다. 그런데 업계를 움직인 건 더 나은 엔지니어링이 아니라 2025년의 계약 마감일이었다.
더 읽기당신의 TLS 인증서는 이미 짧아졌다
다들 2029년에 올 47일 인증서에 패닉했지만, 첫 번째 단축은 이미 일어났다. 200일, 2026년 3월부터 의무다. 진짜 핵심은 유효기간이 아니라 10일까지 줄어드는 재검증 주기다.
더 읽기301 vs 302: 모든 걸 망가뜨리는 리다이렉트
301과 302의 차이는 '영구 vs 임시'가 아니다. 코드 하나에 조용히 묶인 두 개의 별개 결정이고, 실수로 설정한 301은 남의 브라우저 캐시 속에서 영원히 살아남을 수 있다.
더 읽기역방향 DNS는 어떻게 작동하는가 (그리고 FCrDNS가 왜 중요한가)
직접 설정할 수도 없고, 어떤 RFC도 의무화하지 않는데, 없으면 메일이 거부되는 레코드. 예의상의 관행이 어떻게 문지기가 됐는지 짚는다.
더 읽기HSTS 프리로드: 당신의 보안을 브라우저 벤더에게 넘기는 일
HSTS 프리로드 목록에 도메인을 올리는 건 일방통행 문이다. 목록은 당신 서버가 아니라 브라우저 바이너리 안에 있어서, 되돌리려면 당신이 통제하지 못하는 크롬 릴리스를 몇 달이고 기다려야 한다 — 프리로드하라고 권하는 사람들이 말 안 하는 부분이다.
더 읽기DANE: 웹에서 실패하고 이메일에서 이긴 프로토콜
다들 DANE은 죽었다고 한다 — DNSSEC 뒤에 발이 묶여 아무도 안 쓴 아름다운 프로토콜. 그 판정은 미국식이다. 네덜란드에선 의무고, 2026년 마이크로소프트가 탑재했고, 웹에선 정말로 죽었다. 같은 프로토콜, 세 갈래 운명.
더 읽기Content-Security-Policy는 가장 어려운 헤더다
배포된 CSP 대부분은 아무것도 안 한다. 구글이 측정했다: 스크립트를 제한하려는 정책의 94.7%가 우회 가능. 문법은 쉽다. 어려운 이유는 따로 있다.
더 읽기MTA-STS: 아무도 모르는 이메일 보안 프로토콜
SMTP 암호화에는 트럭이 지나갈 만한 구멍이 있다: 경로상의 공격자가 STARTTLS를 벗겨내고 메일을 평문으로 읽을 수 있다. MTA-STS가 그걸 막는다. 그러려면 웹 페이지를 하나 띄워야 하고, 그래서 거의 아무도 안 했다.
더 읽기SMTP relay는 2026년에 실제로 어떻게 작동하는가
1982년엔 모든 메일 서버가 아무한테나 relay해줬다 — 그게 설계였다. 지금은 모르는 사람한테 relay해주면 점심도 되기 전에 블록리스트에 오른다. 'relay'라는 단어는 살아남았고, 그 아래 모든 게 뒤집혔다.
더 읽기와일드카드 인증서는 보안 안티패턴이다
모든 서버에 같은 개인키 하나, 그게 앞으로 만들 모든 서브도메인을 덮는다. 와일드카드 인증서는 작은 편의를 보이지 않는 폭발 반경과 맞바꾼다 — 그리고 표준화 단체도 마침내 같은 결론에 도달했다.
더 읽기와일드카드 DNS 레코드, 계속 발등을 찍는 그 총
와일드카드 DNS 레코드는 '이 이름 아래 전부 매칭'처럼 읽힌다. 아니다. 이미 존재하는 이름은 절대 건드리지 않고, 트리 깊은 곳에 레코드 하나만 추가해도 조용히 죽는다.
더 읽기네거티브 캐싱: DNS는 '없음'도 기억한다
레코드를 추가했는데 세상은 여전히 '존재하지 않는다'고 답한다. 레코드는 멀쩡하다. DNS가 그 부재를 캐싱했을 뿐이다 — 당신이 설정한 적 없는 TTL, 아무도 건드리지 않는 SOA 필드가 지배하는 수명으로.
더 읽기DNS 리바인딩은 브라우저를 내부자로 만든다
당신이 연 웹 페이지가 당신의 브라우저를 통해 집 안의 공유기, 프린터, 스마트 스피커에 닿을 수 있다. DNS 리바인딩은 20년 넘게 통해 왔고, 아직도 통하는 이유는 우리가 로컬 네트워크를 어떻게 지어 왔는지에 관한 불편한 사실을 말해 준다.
더 읽기Anycast: 하나의 IP, 여러 대의 서버
같은 IP가 서울에 있는 당신과 상파울루에 있는 다른 사람에게, 서로 다른 두 대의 기계에서 응답한다. 둘 다 눈치채지 못한다. 그게 anycast다 — 인터넷 전체가 믿어주기로 합의한 BGP를 향한 거짓말이자, 수백 곳에서 동시에 TCP를 조용히 작동시킨 트릭.
더 읽기이메일 포워딩은 왜 모든 걸 망가뜨리는가
SPF는 첫 relay에서 죽는다. DKIM은 메일링 리스트가 본문을 건드리는 순간 깨진다. 그리고 DMARC가 40년 된 골칫거리를 반송 메일로 바꿔놓는다. 이메일에서 가장 확실하게 고장 나는 기능 이야기.
더 읽기DNS TTL: 약속한 값 vs 리졸버가 실제로 하는 일
TTL을 300으로 잡고 5분이면 바뀌겠지 했는데, 한 시간이 지나도 트래픽이 옛 IP로 들어온다. TTL은 일정표가 아니다. 캐시들의 사슬에 건네는 힌트일 뿐이고, 그 캐시들은 저마다 당신을 무시할 권리를 갖고 있다.
더 읽기DKIM Alignment: 다들 헷갈리는 바로 그 부분
DKIM 서명이 유효하다고 DMARC를 통과하는 게 아니다. 서명은 '어떤 도메인이 서명했다'만 증명한다. 그 도메인이 당신의 From 주소를 대변할 자격이 있는지는 alignment가 결정한다.
더 읽기호모그래프 공격: 도메인 이름이 거짓말을 할 때
2017년, 한 연구자가 Chrome·Firefox·Opera 주소창에 apple.com으로 표시되는 도메인을 등록했다. 유효한 HTTPS 인증서까지 달려 있었다. 모든 글자가 키릴 문자였다. 이 문제가 고치기 어려운 이유는 버그 자체보다 더 오래되고 기묘하다.
더 읽기당신의 브라우저는 왜 150개의 인증기관을 신뢰하는가
약 150개 인증기관 중 단 하나라도 당신 도메인의 유효한 인증서를 발급할 수 있다. 당신의 보안은 그중 가장 약한 곳의 수준이다. 그런데도 이게 대체로 굴러가는 이유.
더 읽기우리는 UDP 위에 TCP를 다시 만들고 QUIC라고 불렀다
QUIC는 신뢰성이 있고, 순서를 보장하고, 혼잡 제어를 하고, 전부 암호화한다 — UDP가 한사코 하지 않으려는 모든 것이다. 그런데 왜 하필 UDP 위에 만들었을까? UDP가 인터넷 배관에 남은 유일한 '새 프로토콜 모양의 구멍'이었기 때문이다.
더 읽기루트 서버가 13개라는 착각
다들 DNS 루트 서버가 13개라고 말한다. 실제로는 1,900개가 넘는다. 13이라는 숫자는 이제 아무도 신경 쓰지 않는 패킷 크기 제한 때문에 인터넷에 얼어붙어 있다 — 그리고 그 모순이 풀린 방식이야말로 지금껏 나온 인프라 꼼수 중 손꼽히게 좋은 것이다.
더 읽기DNS는 왜 UDP를 쓰는가 (그리고 안 쓸 때는 언제인가)
DNS는 인터넷에서 가장 바쁜 요청-응답 시스템을, 패킷이 도착한다고 보장하지 않는 전송 위에 올려놨다. 꼼수가 아니었다. 옳은 선택이었다 — 답이 너무 커지기 전까지는.
더 읽기서버는 당신이 봇이라는 걸 어떻게 아는가
User-Agent 문자열에는 아무 브라우저나 적어 넣을 수 있다. 그래서 아무도 그 필드를 믿지 않는다 — 그 아래에 깔린 TLS 핸드셰이크와 HTTP/2 설정은 당신이 아니라 당신이 쓴 라이브러리가 적은 것이기 때문이다.
더 읽기CDN은 단일 장애점이다
CDN 집중화로 하나의 장애가 수천 개 사이트를 동시에 내린다. 분산 복원력을 중앙화된 편의로 교환했다.
더 읽기DNS-over-HTTPS는 아무것도 안 바꿨다 (그리고 모든 걸 바꿨다)
DoH는 DNS 쿼리를 HTTPS로 감싼다. 같은 질문, 같은 답, 다른 전송. 기술 변화는 단순하다. 정치적 파장은 거대하다.
더 읽기CDN 캐시 포이즈닝의 작동 원리
CDN 캐시 포이즈닝은 CDN을 속여서 악성 응답을 캐시하게 하고 모든 후속 방문자에게 서빙하게 한다. 이상한 요청 하나, 대량의 부수 피해.
더 읽기OCSP Stapling vs CRL: 인증서 폐기의 두 가지 나쁜 선택지
인증서가 침해되면 폐기해야 한다. 폐기 확인 메커니즘 두 가지가 다 근본적으로 고장 나 있다.
더 읽기포스트 양자 암호: TLS에서 뭐가 바뀌어야 하는가
양자 컴퓨터가 RSA와 타원곡선을 깨뜨린다. 전환은 이미 시작됐다 — 양자 컴퓨터가 아직 없어서가 아니라 '지금 수확하고 나중에 복호화'가 실제 위협이라서.
더 읽기SNI: 목적지를 유출하는 필드
HTTPS가 모든 걸 암호화한다고? 아니다. 어떤 사이트에 접속하는지는 TLS 핸드셰이크에서 평문으로 전송된다.
더 읽기TLS 1.0/1.1 — 2026년에 아직 누가 쓰는가?
TLS 1.0과 1.1은 공식 폐기되고 모든 브라우저가 거부한다. 그런데 서버는 아직 제공한다. 얼마나, 왜?
더 읽기VPN은 익명성을 주지 않는다
VPN은 트래픽을 보는 주체를 ISP에서 VPN 제공자로 바꾼다. 신뢰를 제거하는 게 아니라 옮기는 것이다.
더 읽기우리는 인터넷이 어떻게 작동하는지 가르치기를 멈췄다
추상화가 인터넷을 쓸 수 있게 만들었다. 불투명하게도 만들었다. 그 비용이 나쁜 보안 결정, 장애 시 무력함, 카고컬트 설정에서 나타난다.
더 읽기"종단간 암호화"가 실제로 뜻하는 것 (그리고 안 뜻하는 것)
모든 메시징 앱이 E2EE를 주장한다. 대부분의 사용자가 완전한 프라이버시라고 생각한다. 현실은 더 미묘하다.
더 읽기BGP: 신뢰 위에 돌아가는 프로토콜
BGP는 내장 인증 없이 인터넷을 라우팅한다. 어떤 AS든 어떤 프리픽스를 공지할 수 있다. 라우트 하이재킹이 터무니없이 쉽다.
더 읽기Certificate Transparency: 모든 인증서가 공개인 이유
공인 CA가 발급하는 모든 TLS 인증서는 공개 검색 가능한 추가 전용 로그에 기록된다. DigiNotar 때문에 이렇게 됐다.
더 읽기컴플라이언스는 보안이 아니다
SOC 2, ISO 27001, PCI DSS — 조직은 컴플라이언스를 보안의 증거로 취급한다. 아니다. 컴플라이언스는 바닥이다. 보안은 방어의 실제 상태다.
더 읽기DMARC 채택 현황: 2026년에도 여전히 장식
DMARC가 '있다'는 대부분의 도메인이 p=none으로 설정한다. 감시만 하고 차단 안 함. 사이렌 없는 화재 감지기다.
더 읽기DNS 쿼리의 처음 50밀리초에 무슨 일이 일어나는가
URL을 입력하면 페이지가 뜬다. 그 사이에 컴퓨터는 서버 4개 이상과 대화하고, 1983년산 계층 구조를 탐색하고, 대부분의 쿼리가 목적지에 도달하지도 않는 캐싱에 의존한다.
더 읽기DNSSEC 작동 원리 (그리고 아무도 안 쓰는 이유)
DNSSEC는 우아한 암호학이지만 운영 현실은 잔인하다. 20년이 지나도 채택률은 20% 미만. 프로토콜이 문제가 아니다.
더 읽기이메일 인증 5개 전부 갖춘 도메인이 얼마나 될까?
SPF, DKIM, DMARC, MTA-STS, BIMI — 5개 표준, 20년, 전부 갖춘 도메인의 비율은 대부분의 조사에서 오차 범위에 들어간다.
더 읽기14개 HTTP 보안 헤더 (실제로 중요한 것은?)
모든 보안 헤더가 같지 않다. 어떤 건 매일 실제 공격을 막고, 어떤 건 브라우저가 무시하는 레거시다. 솔직한 우선순위.
더 읽기HTTP 보안 헤더: 실제로 CSP를 갖춘 곳은?
쉬운 헤더와 어려운 헤더 사이의 격차가 엄청나다. 대부분의 사이트가 X-Content-Type-Options는 설정하고 CSP는 건너뛴다.
더 읽기Let's Encrypt가 인터넷을 바꿨다 (좋은 쪽으로도, 나쁜 쪽으로도)
2015년 전에는 HTTPS가 누군가 신경 쓴다는 뜻이었다. Let's Encrypt 이후 HTTPS는 서버가 존재한다는 뜻이다. 암호화는 얻었고 신뢰 신호는 잃었다.
더 읽기MCP: 보안 도구에 어떤 의미인가
Model Context Protocol은 AI 에이전트에게 보안 도구를 호출하는 표준 방법을 준다. 정찰 워크플로우가 바뀐다. 판단 부분은 안 바뀐다.
더 읽기브라우저 자물쇠 아이콘은 제거되어야 한다
자물쇠는 수억 명의 사용자에게 거짓 신뢰를 만든다. HTTPS는 암호화를 의미하지, 안전을 의미하지 않는다. 아이콘은 사라져야 한다.
더 읽기패스키 vs 패스워드: 아무도 안 하는 전환
패스키는 기술적으로 모든 면에서 우월하다 — 피싱 방지, 공유 비밀 없음, 생체인증 친화적. Apple, Google, Microsoft 모두 지원한다. 채택은 여전히 미미하다.
더 읽기보안 점수는 의미 없다
보안 점수 시스템을 만드는 사람이 말한다. 점수는 실제 보안을 측정하지 않는다. 그런데도 계속 만드는 이유.
더 읽기SPF 10-Lookup 제한: 20년 된 실수
RFC 7208은 SPF를 DNS 조회 10회로 제한한다. 초과하면 이메일 인증이 조용히 깨진다. 2003년에는 말이 됐다. 지금은 아니다.
더 읽기TLS 핸드셰이크 7단계
모든 HTTPS 연결은 대부분의 개발자가 생각조차 안 하는 협상으로 시작된다. TLS 1.3에서 정확히 무슨 일이 일어나는지, 단계별로.
더 읽기2단계 인증은 피싱을 막지 못한다
2FA는 크리덴셜 스터핑을 막는다. 2026년에 실제로 세션을 훔치는 실시간 피싱 프록시는 거의 늦추지도 못한다.
더 읽기루트 CA가 침해되면 무슨 일이 일어나는가
2011년 DigiNotar가 해킹당해 *.google.com을 포함한 500개 이상의 위조 인증서가 발급됐다. 그 여파가 전체 PKI 생태계를 바꿨다.
더 읽기이메일 인증에 프로토콜이 5개나 필요한 이유
SPF, DKIM, DMARC, BIMI, MTA-STS — 이메일은 50년 된 시스템 위에 프로토콜을 계속 쌓고 있다. 왜 교체하지 않는 걸까.
더 읽기"제로 트러스트"는 마케팅 용어다
제로 트러스트는 정당한 보안 아키텍처 원칙으로 시작했다. 모든 벤더가 '우리 제품을 사세요'라는 뜻으로 전용했다. 원래 아이디어가 더 나은 대우를 받을 자격이 있다.
더 읽기