TLS 중간 인증서(CA) 미적용의 숨겨진 위험: MITM 공격 시나리오 분석

 

 

안녕하세요, 실더입니다.

 

최근 프로젝트에서 TLS 인증서 적용을 다루다 중간 인증서(Intermediate CA)를 등록하지 않아도 "보안상 문제없이 작동은 한다"는 의견을 들었어요. 실제로 일부 환경에서는 보기엔 정상적으로 보이지만, 이는 보안의 큰 구멍을 만들 수 있습니다. 오늘은 PEM(서버 인증서) + Key만으로 TLS를 적용할 때 발생하는 문제, 특히 MITM(Man-in-the-Middle) 공격 시나리오를 구조적으로 분석해 보겠습니다.

 

실제로 SSL Labs 데이터에 따르면, 전 세계 사이트 20%가 체인 문제로 A 등급 미달인 상태입니다.

 

(참고: NIST SP 800-52, SSL Labs 데이터)

---

왜 중간 CA가 필요한가?

TLS 인증서는 "신뢰 체인(Chain of Trust)"으로 작동합니다:

• 루트 CA: 브라우저에 미리 설치된 최상위 신뢰 앵커.
• 중간 CA: 루트가 서명한 중간 단계 (CA 파일).
• 서버 인증서 (PEM): 중간 CA가 서명한 최종 certificate
• 프라이빗 키 (Key): 암호화용 비밀키.

중간 CA를 서버에서 제공하지 않으면 신뢰 체인이 불완전해집니다. 클라이언트(브라우저)는 AIA 확장자로 자동 다운로드하려 하지만, 이는 신뢰할 수 없어요. 결과? 암호화는 되지만 인증(누구와 통신하나?)이 약화됩니다.

---

보안 문제: "암호화 OK"지만 전체가 무너짐

 "암호화 통신 자체에는 문제없다"는 말은 맞긴합니다. 다만 TLS는 기밀성(Confidentiality) 외에 인증(Authentication)과 무결성(Integrity)이 핵심이에요. CA 중간 인증서 미적용은 OWASP Top 10 (Security Misconfiguration)에 해당하며, PCI-DSS 규제 위반 가능성도 있습니다.

• 호환성 이슈: 구형 브라우저(IE11, Android 4.x)에서 연결 실패.
• MITM 취약: 체인 검증 약화로 공격자 주입 쉬움. Qualys 보고서: 불완전 체인 사이트 25%가 MITM 취약.

---

MITM 공격 시나리오

중간 CA 미적용 환경에서 공격자가 네트워크를 제어할 수 있다고 가정하면, 아래 순서로 공격이 진행됩니다. (TLS 핸드셰이크 기반)

1. 공격자 위치 확보 (Positioning):
   • ARP 스푸핑이나 DNS 포이즈닝으로 트래픽 가로채기.
   • 문제 소지: CA 누락으로 클라이언트의 자동 다운로드(AIA URL)를 공격자가 차단/스푸핑 가능.
2. TLS 핸드셰이크 가로채기 (Interception):
   • ClientHello 인터셉트 → 가짜 ServerHello 전달.
   • 문제 소지: PEM만 받은 클라이언트가 체인 불완전 → 가짜 중간 CA 주입 용이.
3. 가짜 인증서 & 키 교환 (Forgery & Exchange):
   • 가짜 PEM + 위조 중간 CA 제시.
   • 문제 소지: X.509 검증(RFC 5280) 우회 → 세션 키 공유되지만 공격자 손에.
4. 트래픽 변조 (Tampering):
   • 데이터 복호화/변조/재전달 (e.g., 로그인 정보 탈취).
   • 문제 소지: OCSP 폐지 확인 실패 → 만료된 가짜 CA 사용 가능.
5. 지속 & 회피 (Persistence):
   • 연결 유지하며 스파이링 → 로그 "정상"으로 위장.
   • 문제 소지: HSTS/CT 효과 약화 → 탐지 어려움.

※ CVE-2014-0092(체인 불완전 MITM)와 유사.

- 실제 사례: 2014 Apple Goto Fail 버그처럼 체인 검증 누락으로 MITM 발생: iOS 기기 전세계에서 인증 우회 취약점 노출, 긴급 패치 발행됨 (CVE-2014-1266).

---

해결책: 간단히 fullchain 만들기

cat server.pem intermediate.ca > fullchain.pem  # PEM 먼저!

 

※ WEB 서버에 따라 Config 파일에 직접 코드를 적용할 수 있습니다.

---

마무리: "전체 그림 고려"

중간 CA 미적용 후 TLS 인증 적용은 "작동하는 척"하는 함정입니다. 사설 certificate 예시처럼 내부에선 OK지만, 외부 서비스에선 위험하기 때문에 수정이 필요합니다. 

 

참고 자료: RFC 5246, NIST SP 800-52, SSL Labs 보고서.

---

여담으로 굳이?라는 환경이 있습니다. 서비스의 환경이나 구조에 따라 다르겠지만, 폐쇄망에서 제한적으로 운영중인 서비스나 ACL, FW 과 같은 방법으로 접속을 제한하여 운영하고 있다면 굳이 TLS CA인증서는 패스하거나 사설인증서만 적용하는 정도라도 문제 없을것으로 보입니다. 

 

기업의 보안 담당자라면 환경과 비용에 따라 선택과 집중하여 안전한 환경을 운영하여 주시기 바랍니다.