오늘날 디지털 환경에서 HTTPS는 신뢰의 기반이다. 사용자는 웹사이트의 자물쇠 아이콘을 보며 자신의 정보가 안전하게 전송된다고 믿는다. 이러한 신뢰는 TLS/SSL 암호화와 인증 기관(Certificate Authority, CA) 모델에 기반한다.
[출처: https://www.geeksforgeeks.org/ethical-hacking/how-ssl-tls-certificates-and-digital-signatures-secure-your-online-activities/]
하지만 이 신뢰 모델은 중간자 공격(Man-in-the-Middle, MITM)이라는 본질적인 취약점을 가진다. 공격자는 신뢰받는 CA 중 하나를 손상시키거나 사용자를 속여 악성 CA 인증서를 설치하게 만들 수 있다. 일단 가짜 인증서를 신뢰하게 되면, 모든 암호화된 통신 내용은 공격자에게 노출된다.
SSL 피닝(SSL Pinning)은 바로 이 문제를 해결하기 위해 고안된 강력한 보안 기법이다. 이는 신뢰의 대상을 광범위한 CA 목록에서 개발자가 명시적으로 지정한 단 하나의 인증서 정보로 축소시킨다.
[출처: https://www.indusface.com/learning/what-is-ssl-pinning-a-quick-walk-through/]
SSL Pinning이란?
SSL 피닝의 기술적 원리는 '명시적 신뢰'에 있다. 표준 TLS 통신이 수백 개의 CA 중 누구든 신뢰하는 '위임된 신뢰' 모델이라면, SSL 피닝은 개발자가 "오직 내가 지정한 이 인증서 정보만 신뢰하겠다"라고 앱 코드 내부에 하드코딩하는 방식이다. 앱은 서버로부터 인증서를 받으면, 시스템의 기본 검증에 더해 이 정보가 앱 내부에 고정된(pinned) 정보와 일치하는지 추가로 검사한다. 만약 일치하지 않으면, 앱은 이 연결을 MITM 공격 시도로 간주하고 즉시 통신을 중단한다.
[출처: https://www.indusface.com/learning/what-is-ssl-pinning-a-quick-walk-through/]
구현 방식은 피닝 대상에 따라 크게 두 가지로 나뉜다.
- 인증서 피닝 (Certificate Pinning)
서버의 X.509 인증서 전체 파일 혹은 그 해시값을 앱 내부에 저장하고 비교하는 가장 엄격한 방식이다. 인증서의 모든 정보가 일치해야 하므로 이론상 가장 강력한 보안을 제공한다. 하지만 인증서는 유효기간이 있어 주기적으로 갱신되어야 한다. 인증서 갱신 시마다 앱 업데이트가 필요해 유지보수 비용이 극도로 높다는 치명적인 단점이 있다.
[출처: https://www.wallarm.com/what/certificate-pinning]
- 공개 키 피닝 (Public Key Pinning)
인증서 전체가 아닌, 인증서 내부의 '공개 키' 정보만 추출하여 비교하는 방식이다. 서버 인증서가 갱신되더라도, 동일한 공개 키/개인 키 쌍을 재사용한다면 앱 업데이트 없이도 통신을 지속할 수 있다. 유연성 측면에서 훨씬 유리하다. 현대적 구현에서는 공개 키와 암호화 알고리즘 정보를 포함하는 SPKI(Subject Public Key Info)의 해시값을 피닝하는 방식이 권장된다. 이는 대부분의 운영 환경에서 보안성과 유연성의 최적 균형을 제공한다.
[출처: https://www.keycdn.com/support/public-key-pinning]
영향 및 위험성
SSL 피닝은 강력한 보안을 제공하는 대신 치명적인 운영 위험을 동반한다. 이는 SSL 피닝이 '양날의 검'이라 불리는 이유이다.
가장 심각한 위험은 '앱 먹통(bricked)' 현상이다. SSL 피닝은 특정 인증서 정보를 앱 내부에 하드코딩한다. 만약 서버 관리자가 이 인증서를 갱신하거나, 키가 유출되어 긴급 교체하는 경우, 구버전 앱을 사용하는 모든 사용자는 더 이상 서버의 신원을 확인할 수 없게 된다. 결과적으로 모든 네트워크 연결이 차단되며, 사용자 입장에서는 앱이 완전히 멈추는 것과 같다. 이 문제를 해결할 유일한 방법은 새 인증서 정보를 포함한 앱을 다시 배포하고 모든 사용자의 업데이트를 강제하는 것이지만, 이는 현실적으로 불가능에 가깝다.
과거 웹 환경에서 사용되던 HPKP(HTTP Public Key Pinning) 기술이 대표적인 실패 사례이다. HPKP는 운영자의 작은 실수로도 사이트 전체가 장기간 접속 불능이 되는 'HPKP 자살(HPKP Suicide)' 위험 때문에 모든 주요 브라우저에서 폐기되었다. 모바일 앱의 SSL 피닝 역시 이와 동일한 위험을 내포한다. 보안을 강화하려다 오히려 서비스의 가용성을 심각하게 해치는 최악의 결과를 초래할 수 있다.
대응 및 예방 방안
SSL 피닝을 구현하기로 결정했다면, 그 위험을 최소화하고 우회 시도에 대비하는 다층적 전략이 필수적이다.
구현 가이드
- Android: OkHttp 라이브러리의
CertificatePinner를 사용하거나, 안드로이드 7.0(API 24) 이상부터는 XML로 피닝을 선언하는 네트워크 보안 구성(Network Security Configuration) 방식이 권장된다. 후자가 코드에서 보안 정책을 분리할 수 있어 더 선호된다. - iOS: URLSessionDelegate를 직접 구현하여
didReceive challenge메서드 내에서 인증서를 검증하거나, Alamofire 라이브러리의ServerTrustManager와PinnedCertificatesTrustEvaluator를 사용하는 것이 일반적이다.
운영 및 완화 전략
'앱 먹통' 사태를 피하기 위해, 현재 인증서의 핀과 함께 백업 핀(Backup Pin)을 반드시 앱에 포함해야 한다. 백업 핀은 다음에 사용할 예비 키 쌍의 공개 키 해시이다. 이렇게 하면 주 인증서에 문제가 생기거나 갱신이 필요할 때 백업 인증서로 원활하게 전환할 수 있다. 또는 리프 인증서 대신 상위의 중간 CA를 피닝하여 유연성을 확보하는 전략도 있으나, 이는 공격 표면을 다시 넓히는 한계가 있다.
우회 공격과 방어
SSL 피닝은 클라이언트 측 검증이므로 루팅이나 탈옥 환경에서는 우회될 수 있다. 공격자는 Frida와 같은 동적 분석 도구를 사용하여 앱의 피닝 검증 로직(예: OkHttp의 CertificatePinner.check 메서드)을 실시간으로 조작(후킹)하여 검증을 무력화한다.
따라서 SSL 피닝은 다음과 같은 다층 방어 전략과 함께 사용되어야 한다.
- 루팅/탈옥 탐지: 공격의 전제 조건인 변조된 환경을 탐지하고 앱 실행을 차단한다.
- 코드 난독화 및 안티-탬퍼링: Frida 등이 분석할 코드를 찾기 어렵게 만든다.
- 모바일 앱 증명 (Mobile App Attestation): 가장 근본적인 방어책이다. 클라이언트가 아닌 서버가 앱과 기기 환경의 무결성을 검증하는 기술이다. Frida 등으로 피닝이 우회된 환경에서는 유효한 증명 토큰을 발급받지 못하므로, 서버가 API 요청을 원천 차단할 수 있다.
최신 동향 및 실제 사례
SSL 피닝의 높은 운영 위험과 한계로 인해, 업계는 더 유연하고 생태계 전반에 걸친 대안으로 이동하고 있다. 구글과 같은 주요 플랫폼 리더들은 더 이상 모바일 앱에 SSL 피닝을 적극적으로 권장하지 않는다.
이 흐름을 주도하는 핵심 기술은 인증서 투명성(Certificate Transparency, CT)이다. CT는 모든 CA가 발급하는 모든 SSL/TLS 인증서를 공개적인 로그에 기록하도록 강제하는 프레임워크이다. 이는 잘못된 인증서 발급을 '차단'하는 피닝과 달리, 모든 발급 내역을 '탐지'하고 감사할 수 있게 만든다. 최신 브라우저들은 서버 인증서에 SCT(Signed Certificate Timestamp)가 포함되어 있는지 확인하여, CT 로그에 기록되었음을 검증한다.
[출처: https://comodosslstore.com/blog/everything-wanted-know-certificate-transparency.html]
도메인 소유자는 이 로그를 감시하여 승인되지 않은 인증서 발급을 즉시 탐지하고 대응할 수 있다. 또한 인증 기관 승인(CAA) 레코드는 도메인 소유자가 DNS에 인증서 발급을 허용할 CA를 명시하는 기술이다.
이처럼 CT와 CAA, 그리고 90일 등으로 짧아진 인증서 유효기간 정책이 결합하여, SSL 피닝이라는 위험한 기술 없이도 PKI 생태계의 신뢰도를 크게 향상시키고 있다.
