핵심 인사이트 (3줄 요약)
- 본질: HPKP (HTTP Public Key Pinning)는 서버가
Public-Key-Pins헤더로 "앞으로는 이 공개키 지문과 일치하는 인증서만 신뢰하라"고 브라우저에 동적으로 전달하던 웹 PKI (Public Key Infrastructure) 보강 기법이다.- 가치: 악성 Root CA (Certificate Authority) 설치나 CA 오발급이 있어도 핀과 일치하지 않으면 브라우저가 연결을 끊으므로, 공개 PKI의 넓은 신뢰 범위를 서비스별로 좁히려는 시도였다.
- 판단 포인트: 그러나 TOFU (Trust On First Use), 키 유실, 자살 핀닝, Ransom Pinning 위험이 너무 커 공개 웹에서는 사실상 실패했고, 오늘날은 CT (Certificate Transparency) 모니터링·CAA (Certification Authority Authorization)·정적 앱 핀닝이 더 현실적인 대안이다.
Ⅰ. 개요 및 필요성
HPKP는 웹 서버가 브라우저에게 "다음 접속부터는 이 공개키 계열만 믿어라"라고 지시하는 동적 핀닝 방식이었다. 일반 HTTPS (Hypertext Transfer Protocol Secure)는 운영체제나 브라우저가 기본적으로 신뢰하는 수많은 CA 중 어느 하나가 서명한 인증서라면 일단 정상 후보로 받아들인다. 이 구조는 인터넷 전체에는 유연하지만, 공격자 관점에서는 신뢰 경로가 너무 많다는 뜻이기도 하다.
이 문제가 크게 드러난 배경에는 CA 침해와 오발급 사고가 있었다. 대표적으로 DigiNotar 사건처럼 CA가 뚫리면 합법처럼 보이는 위조 인증서가 발급될 수 있고, 사용자는 브라우저 자물쇠 아이콘만 보고는 이를 구별하기 어렵다. HPKP는 이런 공개 PKI의 약점을 보완하기 위해, "우리 도메인이 실제로 쓰는 공개키 지문을 브라우저가 기억하게 하자"는 발상에서 등장했다.
문제는 HPKP가 보안 강화를 위해 브라우저에 너무 강한 기억을 심었다는 점이다. 서버 운영자가 핀으로 등록한 키를 잃어버리거나, CDN (Content Delivery Network)·인증서 교체 절차를 잘못 밟으면 공격자가 아닌 정상 운영자조차 자기 사이트에 접속하지 못하게 만들 수 있었다. 즉 HPKP의 핵심 딜레마는 "CA를 덜 믿기 위해 브라우저 캐시를 더 강하게 믿게 만들었다"는 데 있다.
- 📢 섹션 요약 비유: HPKP는 손님에게 "우리 집 열쇠 모양은 이것뿐"이라고 미리 외우게 하는 방식인데, 집주인이 열쇠를 바꾸고도 그 사실을 제때 알리지 못하면 정작 진짜 집주인도 문을 못 연다.
Ⅱ. 아키텍처 및 핵심 원리
HPKP의 동작은 간단하지만 운영상 매우 위험했다. 서버는 정상 HTTPS 응답과 함께 Public-Key-Pins 헤더를 보낸다. 브라우저는 여기서 SPKI (Subject Public Key Info) 해시와 max-age를 읽어 캐시하고, 이후 같은 도메인에 접속할 때 서버 인증서 체인이 이 핀셋 중 하나와 일치하는지 다시 확인한다. 체인 검증과 핀 검증이 모두 통과해야 세션이 열린다.
| 구성 요소 | 역할 | 설계상 의미 |
|---|---|---|
pin-sha256 | 공개키 지문의 Base64 해시 | 현재 운영 키와 백업 키를 함께 넣어야 함 |
max-age | 핀을 기억할 기간 | 길수록 보안 지속 시간은 늘지만 복구는 어려워짐 |
includeSubDomains | 하위 도메인까지 강제 | 범위를 넓힐수록 사고 영향도 함께 확대 |
report-uri | 위반 보고 수집 | 탐지에는 도움되지만 차단 자체는 막지 못함 |
아래 그림은 HPKP의 정상 흐름과 실패 지점을 함께 보여 준다. 핵심은 브라우저가 최초 정상 접속 후 핀을 "배웠다"는 점이며, 이 기억을 서버가 강제로 지우기 어렵다는 데 있다.
┌──────────────────────────────────────────────────────────────────────┐
│ HPKP runtime flow │
├──────────────────────────────────────────────────────────────────────┤
│ 1) First valid HTTPS response │
│ Server -> Public-Key-Pins(primary pin + backup pin + max-age) │
│ Browser caches pinset for the host │
│ │
│ 2) Later connection │
│ Presented cert chain -> extract SPKI hash │
│ │ │
│ ├─ hash matches cached pinset -> allow │
│ └─ hash mismatch -> hard fail │
│ │
│ 3) Operational failure cases │
│ - both pinned keys lost or rotated incorrectly │
│ - attacker injects malicious long-lived pins │
│ - cert/CDN change occurs before cache expiry │
└──────────────────────────────────────────────────────────────────────┘
여기서 가장 치명적인 메커니즘은 TOFU다. 최초 접속 시점이 안전하다고 가정해야 핀을 정상적으로 배울 수 있는데, 만약 그 시점 자체가 공격 환경이면 잘못된 핀을 저장할 수 있다. 또한 운영자가 현재 키와 백업 키를 모두 잃으면 브라우저는 남은 max-age 동안 새로운 정상 인증서조차 거부한다. 이를 자살 핀닝(Suicide Pinning)이라 부른다.
여기에 더해 공격자가 서버를 잠시 장악한 뒤 자신의 공개키를 긴 max-age로 심어 버리면, 원래 운영자가 서버를 되찾더라도 사용자는 계속 접속이 차단될 수 있다. 이것이 Ransom Pinning이다. 즉 HPKP는 이론상 MITM (Man-In-The-Middle) 방어에는 강했지만, 실제 운영에서는 "공격자보다 운영 실수와 복구 실패"에 더 취약했다.
- 📢 섹션 요약 비유: HPKP는 비밀번호를 아주 강하게 거는 금고와 같지만, 예비 열쇠와 관리자 절차가 없으면 도둑보다 주인이 먼저 갇히게 된다.
Ⅲ. 비교 및 연결
HPKP를 이해할 때 가장 중요한 것은 인증서 핀닝, HSTS (HTTP Strict Transport Security), CT를 서로 섞지 않는 것이다. 이들은 모두 TLS (Transport Layer Security) 주변 기술이지만, 해결하려는 질문이 다르다.
| 기법 | 답하려는 질문 | 강점 | 한계 |
|---|---|---|---|
| HPKP | "브라우저가 다음에도 이 공개키 계열만 신뢰해야 하는가?" | CA 오발급 방어, 강한 클라이언트 차단 | TOFU, 자살 핀닝, Ransom Pinning |
| 정적 인증서 핀닝 | "통제 가능한 앱이 특정 서버만 신뢰해야 하는가?" | 모바일 앱에서 매우 강력 | 앱 업데이트·백업 핀 관리 필요 |
| HSTS | "이 도메인은 항상 HTTPS로만 접근해야 하는가?" | 프로토콜 다운그레이드 방지 | 인증서 오발급 자체는 못 막음 |
| CT | "이상한 인증서가 발급되었는가?" | 오발급 탐지, 생태계 투명성 강화 | 클라이언트에서 즉시 차단하지는 않음 |
즉 HPKP는 브라우저에 동적으로 핀을 학습시키는 공개 웹용 기법이었고, 정적 핀닝은 모바일 앱처럼 배포 경로를 통제할 수 있는 클라이언트에 더 적합하다. HSTS는 HTTPS 강제 정책일 뿐 핀닝이 아니고, CT는 "막는 기술"보다 "들키게 만드는 기술"에 가깝다. 이 구분을 이해해야 HPKP 폐기 이후의 대안을 올바르게 선택할 수 있다.
실무 연결도 중요하다. 오늘날 공개 웹은 HPKP 대신 CT 로그 모니터링, CAA 레코드, 짧은 인증서 수명, 자동 갱신, HSTS를 조합해 신뢰 모델을 관리한다. 반면 모바일 금융 앱이나 전용 에이전트는 서버 대상을 강하게 통제할 수 있으므로, HPKP가 아니라 정적 SPKI 핀닝을 신중하게 적용한다. 즉 HPKP의 실패는 "핀닝 자체의 실패"가 아니라 "통제 불가능한 브라우저 생태계에서의 동적 강제 핀닝 실패"로 보는 것이 정확하다.
- 📢 섹션 요약 비유: HPKP가 길거리 모든 손님에게 비상 연락처까지 외우게 한 규칙이었다면, 정적 앱 핀닝은 회사 직원증에만 적힌 내부 규칙이고, CT는 누가 가짜 출입증을 만들었는지 공개 게시판에 바로 올리는 방식이다.
Ⅳ. 실무 적용 및 기술사 판단
현재 공개 웹 서비스에서 HPKP를 신규 도입하는 판단은 사실상 "비권장"이 아니라 "금지에 가깝다"고 보는 편이 맞다. 주요 브라우저가 이미 지원을 중단했기 때문에 보안 효과도 얻기 어렵고, 오래된 문서나 장비에 남은 설정은 오히려 혼란만 만든다. 기술사 답안에서는 HPKP를 적극 기술이 아니라, 운영 가능성을 무시한 보안 설계의 반면교사로 정리하는 것이 좋다.
| 운영 맥락 | 권장 판단 | 이유 |
|---|---|---|
| 공개 웹 브라우저 서비스 | HPKP 사용 금지, CT·CAA·HSTS 채택 | 브라우저 지원 종료, 운영 리스크 큼 |
| 모바일 앱 / 전용 에이전트 | 정적 SPKI 핀닝 검토 | 배포 채널과 서버 대상 통제가 가능 |
| 레거시 사내 브라우저 환경 | 예외적 검토만 가능 | 폐쇄망·버전 통제·키 에스크로가 모두 전제 |
| 멀티 CDN / 제3자 인증서 의존 서비스 | 핀 계열 강제 지양 | 교체 주체가 많아 가용성 사고 위험 큼 |
실무 체크리스트
- 공개 웹이라면 HPKP 대신 CT 로그 모니터링, CAA, HSTS, 자동 인증서 갱신 체계를 갖추었는가?
- 앱 핀닝을 쓴다면 Primary Pin과 Backup Pin, 키 회전 절차, 강제 업데이트 전략이 있는가?
- 인증서 문제를 탐지하는 모니터링과 운영 Runbook이 있는가?
- CDN, 로드밸런서, 제3자 TLS 종료 지점을 모두 통제할 수 있는가?
- "차단"이 필요한지, 아니면 "탐지와 경보"가 더 적합한지 구분했는가?
자주 발생하는 안티패턴
- HPKP와 HSTS를 비슷한 보안 헤더로 오해해 함께 권장하는 답안
- 핀 계열을 너무 넓게 잡거나 Leaf 인증서 하나만 고정해 교체 절차를 망치는 설계
- 브라우저 정책 문제를 모바일 앱 정적 핀닝 문제와 혼동하는 설명
- CA 오발급 대응을 클라이언트 강제 차단 하나로만 해결하려는 사고
정리하면 HPKP의 교훈은 단순하다. 보안 통제가 강할수록 복구 경로도 함께 설계해야 한다. 복구가 없는 강제 정책은 공격 차단 수단이 아니라, 스스로를 멈추게 하는 장애 유발 장치가 되기 쉽다.
- 📢 섹션 요약 비유: HPKP를 공개 웹에 쓰는 것은 비상 탈출구 없는 방화문을 설치하는 것과 같아서, 불은 막을 수 있어도 안의 사람도 함께 가두게 된다.
Ⅴ. 기대효과 및 결론
HPKP가 남긴 가장 큰 유산은 "보안을 더 세게 걸면 무조건 좋다"는 직관이 틀릴 수 있다는 사실이다. 공개 웹에서는 수많은 브라우저, CDN, 인증서 자동화, 제3자 인프라가 얽혀 있으므로, 클라이언트 캐시에 장기 정책을 심는 방식이 운영 현실과 맞지 않았다. 결국 업계는 클라이언트 강제 차단보다, CT처럼 공개 로그를 통한 감사와 탐지 중심 모델로 이동했다.
이 변화는 보안 책임의 위치도 바꾸었다. HPKP는 수많은 브라우저에 차단 책임을 나눠 주었지만, CT와 CAA는 도메인 운영자가 발급 거버넌스와 모니터링을 직접 관리하게 만든다. 즉 "각 클라이언트가 개별 기억으로 막는 방식"에서 "생태계 전체가 투명성으로 감시하는 방식"으로 패러다임이 이동한 것이다.
결론적으로 HPKP는 오늘날 실무에서 쓰는 기술이라기보다, 동적 브라우저 핀닝이 왜 실패했는지 설명하는 역사적 사례로 기억하는 것이 정확하다. 그리고 이 사례는 현대 보안 설계자에게 언제나 같은 질문을 남긴다. "공격자는 막았는데, 정상 운영자는 복구할 수 있는가?"
- 📢 섹션 요약 비유: HPKP는 너무 엄격한 출입 명단을 만든 나머지 경비원도 수정할 수 없게 되어 버린 규칙과 같다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 인증서 핀닝 (Certificate Pinning) | HPKP는 브라우저에 동적으로 핀을 배포한 특수한 형태였다. |
| SPKI (Subject Public Key Info) | HPKP가 주로 고정하려 했던 공개키 지문 대상이다. |
| CT (Certificate Transparency) | HPKP 실패 이후 공개 웹에서 오발급 대응의 중심이 된 체계다. |
| HSTS (HTTP Strict Transport Security) | HTTPS 강제 정책으로, HPKP와 목적이 다르다. |
| CAA (Certification Authority Authorization) | 어떤 CA가 우리 도메인 인증서를 발급할 수 있는지 DNS에서 제한한다. |
| MITM (Man-In-The-Middle) | HPKP가 직접 줄이려 했던 대표 공격 시나리오다. |
📈 관련 키워드 및 발전 흐름도
공개 PKI 신뢰 모델
│
▼
CA 오발급 · 악성 Root CA 우려
│
├─ 통제 가능한 클라이언트 -> 정적 인증서 핀닝
└─ 공개 웹 브라우저 -> HPKP 동적 핀닝 시도
│
▼
TOFU · 자살 핀닝 · Ransom Pinning
│
▼
브라우저 지원 중단
│
▼
CT 모니터링 + CAA + HSTS + 자동 인증서 운영
이 흐름은 HPKP가 "더 강한 차단"으로 출발했지만, 결국 "더 운영 가능한 투명성"으로 대체된 과정을 보여 준다.
👶 어린이를 위한 3줄 비유 설명
- HPKP는 브라우저에게 "우리 집 열쇠 모양은 이것만 맞아" 하고 오래 기억하게 만드는 규칙이었어요.
- 그래서 가짜 열쇠는 잘 막았지만, 진짜 집주인이 열쇠를 바꿔도 브라우저가 예전 것만 믿어서 문을 안 열어 줄 수 있었어요.
- 그래서 지금은 열쇠를 억지로 기억시키기보다, 누가 이상한 열쇠를 만들었는지 모두가 볼 수 있는 기록장으로 감시하는 방법을 더 많이 써요.