HTTPS — TLS 해독, 해독 없이 보는 법, 인증서 읽기¶

이 페이지에서 다루는 것

거의 모든 트래픽이 암호화되면서 생긴 가시성 문제, TLS 해독(TLS 검사)이 실제로 어떻게 동작하는지와 그 한계, 해독이 없을 때 계층별로 여전히 보이는 것(IP·ASN, 포트, SNI·인증서, 양과 시간), 그리고 인증서를 필드별로 읽어 수상한 인증서를 가려내는 법(openssl, Zeek ssl.log·x509.log). 마지막에 확인 문제와 해설이 있습니다.

표기

[보충] = 꼭 알아야 할 실무 보충, [정정] = 흔히 잘못 알려진 내용 정정, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. Zeek의 TLS 로그 필드 전체는 Zeek ssl.log·x509.log에 있습니다.

한눈에 보는 핵심 8가지¶

암호화는 사용자를 지키지만 보안팀의 눈도 가린다. HTTP뿐 아니라 DoH로 DNS까지 가려진다.
네트워크가 완전히 깜깜해져도 엔드포인트에서는 볼 수 있다. 암호화가 늘수록 엔드포인트 기록이 중심이 된다.
TLS 해독은 회사가 만든 루트 인증서를 PC에 심어 두고, 중간 장비가 사이트마다 가짜 인증서를 즉석에서 만들어 "가운데서 풀었다 다시 잠그는" 방식이다.
해독이 없어도 보이는 것: 목적지 IP(ASN·위치), 포트, SNI, (TLS 1.2 이하라면) 인증서, 주고받은 양과 시간.
인증서에서 볼 것: Subject/CN과 SAN(어느 사이트인가), Issuer(누가 서명했나), 유효 기간, 조직 정보.
수상한 인증서: 자체 서명(Issuer = Subject), 무작위 이름, 도구의 기본 인증서, SNI와 맞지 않는 이름, 443이 아닌 이상한 포트.
[정정] "조직 정보가 비어 있으면 악성"은 지금은 약한 신호다. 정상 사이트 대부분이 조직 정보 없는 DV 인증서를 쓴다.
TLS 1.3은 인증서를 암호화한다. 해독 없이 인증서를 읽는 방법은 TLS 1.2 이하에서만 통한다.

거의 모든 것이 HTTPS¶

왜 문제인가. 암호화는 개인을 엿보기와 중간자 공격(통신을 가로채 바꾸는 공격)으로부터 지켜 줍니다. 그런데 같은 암호화가 보안팀의 눈도 가립니다. 대부분의 조직에서 트래픽 대부분이 암호화돼 있는데, 그걸 풀어 볼 도구가 없는 팀도 많습니다. 게다가 DNS까지 DoH(DNS over HTTPS)로 암호화되면서, TLS를 못 풀면 HTTP뿐 아니라 DNS도 안 보이게 됐습니다(암호화 DNS).

Let's Encrypt처럼 무료로 쉽게 인증서를 받을 수 있는 서비스가 생기고, 브라우저가 https가 아닌 사이트에 "안전하지 않음"을 표시하면서 이 흐름은 더 빨라졌습니다. 공격자도 똑같이 무료 인증서로 자기 트래픽을 숨깁니다.

그래도 절망할 필요는 없습니다. 네트워크가 완전히 깜깜해져도 엔드포인트(PC·서버)에서는 직접 정보를 모을 수 있습니다. 암호화가 늘수록 엔드포인트 기록이 네트워크 가시성 손실의 주된 해답이 됩니다.

선택지는 크게 두 가지입니다. 풀어서 보거나(TLS 해독), 안 풀고도 보이는 것을 최대한 쓰는 것입니다.

TLS 해독은 어떻게 동작하나¶

비유하면 회사 우편실이 모든 봉투를 열어 보고 새 봉투에 다시 넣어 전달하는 것입니다. 직원은 회사 우편실 도장을 믿도록 미리 교육받아서, 새 봉투를 의심하지 않습니다.

Client PC  ──HTTPS (key 1)──▶  Decryption device  ──HTTPS (key 2)──▶  Web server
           ◀─ org-signed cert ─┤  decrypt → inspect  ├─ original cert ─▶
                                │  → re-encrypt      │
                                └─▶ IDS/IPS, sandbox, metadata, SIEM

준비: 회사가 자기만의 루트 인증 기관(Root CA)을 만들고, 그 루트 인증서를 모든 회사 PC의 "신뢰하는 인증서 목록"에 미리 넣어 둠. 이게 없으면 브라우저가 가짜 인증서를 거부해서 전체가 작동하지 않음
PC → 해독 장비: PC가 "www.example.com에 연결하고 싶다"고 하면, 해독 장비가 즉석에서 그 사이트용 인증서를 만들어 회사 루트 CA로 서명해 돌려줌. PC는 회사 루트를 믿으므로 받아들임
해독 장비 → 사이트: 해독 장비는 반대쪽에서 진짜 사이트에 보통의 클라이언트처럼 연결하고, 사이트의 진짜 인증서로 암호화 연결을 맺음
가운데서: 해독 장비는 사실상 "중간자"가 됩니다. PC 쪽 연결(키 1)과 사이트 쪽 연결(키 2) 사이에서 내용이 풀린 상태로 지나가므로, 이 순간 IDS/IPS 규칙, 파일 샌드박스, 메타데이터 수집, SIEM 전송을 모두 할 수 있음

사용자는 여전히 암호화 연결을 쓰고, 보안팀은 안을 볼 수 있습니다.

[보충] 해독의 한계와 주의점.

문제	내용
인증서 고정(Pinning)	일부 앱(은행 앱, 업데이트 도구, 일부 보안 제품)은 "이 사이트는 이 인증서만 믿는다"고 정해 두어, 회사 인증서를 받으면 연결을 끊음 → 예외 처리 필요
개인정보·법	은행, 의료, 개인 메일 같은 분류는 해독하지 않도록 예외를 두는 경우가 많음. 국가·조직 규정과 사용자 고지 확인 필요
회사 루트 CA 관리	그 루트 키가 유출되면 공격자가 회사 PC가 믿는 가짜 인증서를 만들 수 있음 → 가장 엄격하게 보호
성능·장애	모든 연결을 풀고 다시 잠그는 비용. 장비 장애가 곧 인터넷 장애
회사 관리 밖 기기	루트 인증서가 없는 개인 기기·IoT는 해독할 수 없음
새 프로토콜	QUIC(HTTP/3)은 기존 프록시를 우회하기 쉬워, 보통 UDP 443을 막아 TCP로 되돌림(QUIC 정책)

해독이 없을 때 여전히 보이는 것¶

해독 장비가 없어도 포기할 필요는 없습니다. 계층별로 보이는 것이 다릅니다.

계층	보이는 것	쓰는 법
IP(3계층)	목적지 IP, 그 IP의 ASN(어느 회사망인가)·국가	악성 IP 목록과 대조, 저가 VPS·낯선 국가, Passive DNS로 그 IP에 연결된 도메인 확인
TCP(4계층)	목적지 포트	대부분 443이라 평범하지만, 4444(Metasploit 기본 포트) 같은 포트로 TLS가 오가면 탐지 기회
세션(TLS)	SNI(접속하려는 사이트 이름), TLS 버전·암호 방식, 인증서(TLS 1.2 이하), 지문(JA3·JA4)	사이트 이름 판단(도메인 신호), 인증서 판정(아래), 클라이언트 지문
응용(7계층)	안 보임 — 경로, 헤더, 본문은 모두 암호화된 바이트	—
연결 정보	주고받은 양, 시간, 연결 주기	큰 업로드(유출), 비콘 주기

DNS 기록이 있다면 연결 직전에 어떤 이름을 물었는지로도 사이트를 알 수 있습니다. 다만 TLS 1.3이 퍼지고 ECH가 표준이 되면서 세션 계층에서 보이는 것도 줄고 있습니다. 그래서 해독 전략을 아직 세우지 않았다면 지금 계획해야 합니다.

인증서 읽기¶

TLS 1.2 이하에서는 서버가 보내는 인증서가 암호화되지 않은 채 지나가므로, 해독 없이도 Wireshark나 Zeek에서 읽을 수 있습니다. 브라우저의 "인증서 보기" 창에 나오는 내용과 같습니다.

필드별 의미¶

필드	뜻	분석 포인트
Subject / Common Name(CN)	인증서가 발급된 사이트 이름(필수)	사용자가 간 사이트. SNI와 맞는가
Subject Alternative Name(SAN)	이 인증서로 쓸 수 있는 이름 목록	지금 브라우저는 CN이 아니라 SAN으로 이름을 확인함
Issuer	서명한 인증 기관(필수)	Subject와 같으면 자체 서명
인증서 사슬	사이트 → 중간 CA → 루트 CA	브라우저가 믿는 루트까지 이어지는가
Not Before / Not After	유효 기간	막 발급됐나, 비정상적으로 긴가(자체 서명은 10년 등)
Organization / Locality / Country	조직·지역·국가(선택)	채워졌으면 누가 만들었는지 단서. 비어 있는 건 아래 [정정] 참고

openssl로 직접 보기¶

격리된 분석 환경에서 서버 인증서를 직접 받아 볼 수 있습니다(회사 PC·회사 IP에서 의심 서버에 접속하지 않습니다).

$ openssl s_client -connect update-cdn-sync.example:443 -servername update-cdn-sync.example </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = update-cdn-sync.example
issuer=CN = update-cdn-sync.example
notBefore=Nov  2 08:14:51 2026 GMT
notAfter=Oct 31 08:14:51 2036 GMT
X509v3 Subject Alternative Name:
    DNS:update-cdn-sync.example

openssl s_client -connect host:443 — 그 서버와 TLS 연결을 맺음
-servername host — SNI를 보냄(없으면 한 IP에 사이트가 여럿인 서버가 엉뚱한 인증서를 줄 수 있음)
</dev/null 2>/dev/null — 연결 후 바로 끝내고, 진행 메시지는 숨김
| openssl x509 -noout — 받은 인증서를 해석하되 인증서 원문은 출력하지 않음
-subject -issuer -dates -ext subjectAltName — 이름, 서명자, 유효 기간, SAN만 출력

결과 읽기: subject와 issuer가 같음 → 자체 서명, 이틀 전 발급에 유효 기간 10년(공인 인증서는 이렇게 길 수 없음), 조직 정보 없음. 정상 공개 서비스라면 공인 CA가 서명한 짧은 기간의 인증서를 씁니다.

Zeek 로그로 보기¶

ssl.log:
  id.orig_h=10.1.5.77  id.resp_h=203.0.113.58  id.resp_p=4444
  version=TLSv12  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  server_name=-  established=T  validation_status=self signed certificate

x509.log:
  certificate.subject=CN=xk29fq.local,O=,C=
  certificate.issuer=CN=xk29fq.local,O=,C=
  certificate.not_valid_before=2026-11-02T08:14:51Z
  certificate.not_valid_after=2036-10-31T08:14:51Z
  san.dns=-

id.resp_p=4444 — TLS가 443이 아닌 4444(Metasploit 기본 포트)
server_name=- — SNI 없음 → IP로 직접 접속(IP 직접 접속)
established=T — TLS 연결 성공
validation_status=self signed certificate — Zeek가 검증해 보니 자체 서명(검증 스크립트를 켰을 때 남음)
certificate.subject / issuer — 둘 다 무작위 같은 xk29fq.local, 조직·국가 비어 있음
유효 기간 10년, SAN 없음

이 정도면 C2 의심이 아주 강합니다.

수상한 인증서의 신호¶

신호	왜
자체 서명(Issuer = Subject)	공개 서비스는 공인 CA를 씀. 공격자는 아무 정보 없이 직접 만든 인증서를 쓰기도 함
무작위·의미 없는 이름, `.local` 같은 내부용 이름	공개 사이트에 맞지 않음
도구의 기본 인증서	공격 도구를 설정 없이 쓰면 기본 인증서가 그대로 나감(예: Cobalt Strike 기본 키스토어의 `CN=Major Cobalt Strike`, OpenSSL 기본값 `O=Internet Widgits Pty Ltd`)
SNI와 인증서 이름 불일치	다른 사이트 인증서를 쓰거나 프론팅·중간자
이상한 포트 + 인증서	4444, 8443, 높은 번호 포트의 TLS
공인 인증서치고 너무 긴 유효 기간	공인 인증서는 정책상 최대 기간이 정해져 있음(아래 [변경됨])
같은 인증서 지문이 여러 낯선 IP에서	공격자가 서버 여러 대에 같은 인증서를 복사 → 지문으로 인프라를 엮을 수 있음

[정정] "조직 정보가 비어 있으면 악성"은 약한 신호입니다. 예전엔 악성 인증서가 조직·지역·국가를 비워 두는 경향을 강한 단서로 봤습니다. 하지만 지금은 Let's Encrypt 같은 DV(도메인 검증) 인증서가 웹의 다수라, 정상 사이트도 대부분 조직 정보가 없습니다(DV는 "이 도메인의 주인"만 확인하고 회사 정보를 넣지 않음). 반대로 조직 정보가 채워진 OV·EV 인증서는 발급할 때 회사 확인을 거치므로, 채워져 있으면 약간의 신뢰 근거가 되고, 비어 있으면 판단 보류 정도로 봅니다. 마찬가지로 "Let's Encrypt = 수상"도 틀립니다. 무료라 공격자도 쓰지만 정상 사이트 대부분도 씁니다.

2026년 관점¶

[2026 현재] 그대로 유효한 것

"암호화가 가시성을 가린다", "해독은 회사 루트 CA를 이용한 중간자 방식", "해독이 없어도 IP·포트·SNI·양·시간은 보인다", "자체 서명·무작위 이름·이상한 포트 인증서는 수상하다", "엔드포인트가 해답의 큰 부분"은 그대로입니다.

[변경됨] 바뀐 것

인증서 유효 기간이 계속 짧아집니다. 업계 단체(CA/Browser Forum)가 정한 일정에 따라 공인 인증서 최대 유효 기간은 2026년 3월 15일부터 200일, 2027년 3월 15일부터 100일, 2029년 3월 15일부터 47일로 줄어듭니다. 그래서 "인증서가 막 발급됐다"는 신호가 약해졌습니다(정상 사이트도 자주 갱신). 대신 인증서 투명성(CT) 로그에서 그 도메인의 첫 인증서가 언제 나왔나, 도메인 등록일을 봅니다. 반대로 공인 CA가 서명했다면서 이 기간보다 긴 인증서는 이상합니다.
TLS 1.3이 대부분이 됐습니다. TLS 1.3은 서버 인증서를 암호화해서 보내므로, 해독 없이 인증서를 읽는 방법은 TLS 1.2 이하 연결에서만 통합니다. 남는 건 SNI와 지문(JA3·JA4)인데, ECH(2026년 RFC 9849)가 퍼지면 SNI도 가려집니다(ECH).
EV 인증서의 표시가 사라졌습니다. 브라우저들이 주소창의 회사 이름 표시(EV 녹색 표시)를 없앤 뒤 EV의 의미가 줄었습니다.
해독 위치가 클라우드로 옮겨 갔습니다. 회사 안 장비 대신 클라우드 보안 웹 게이트웨이(SWG)·SASE가 TLS 검사를 맡고, 엔드포인트 에이전트가 트래픽을 그쪽으로 보내는 구성이 흔합니다.
EDR·브라우저 텔레메트리가 많이 메워 줍니다. 해독이 없어도 EDR은 어떤 프로세스가 어디로 연결했는지, 무엇을 내려받았는지를 엔드포인트에서 직접 기록합니다.

[주의] 지금 그대로 하면 틀리거나 위험한 것

조직 정보 없음·Let's Encrypt만으로 악성 판정하지 않습니다. 정상 사이트 대다수가 그렇습니다.
"인증서가 최근 발급됨"을 강한 신호로 쓰지 않습니다. 짧은 유효 기간 때문에 정상 인증서도 늘 최근 것입니다. 도메인 나이와 CT 첫 등장 시점을 봅니다.
해독 예외를 넓게 잡지 않습니다. 공격자는 예외 분류(예: 금융·의료로 분류된 사이트, 업데이트 서비스)에 숨으려 합니다. 예외는 꼭 필요한 범위로 좁히고 기록합니다.
회사 루트 CA 개인키를 일반 서버처럼 다루지 않습니다. 유출되면 회사 전체의 TLS 신뢰가 무너집니다.

확인 문제¶

문제 1¶

TLS 해독이 없는 환경에서 Zeek가 다음을 남겼습니다. 무엇이 수상하고, 판정은 무엇입니까?

ssl.log:  id.orig_h=10.1.5.77  id.resp_h=203.0.113.58  id.resp_p=4444  version=TLSv12
          server_name=-  established=T  validation_status=self signed certificate
x509.log: certificate.subject=CN=xk29fq.local  certificate.issuer=CN=xk29fq.local
          not_valid_before=2026-11-02  not_valid_after=2036-10-31
conn.log: same pair every 60 s, ~1.2 KB each way

정답과 해설

수상한 점이 거의 모든 칸에 있습니다.

포트 4444 — Metasploit 기본 포트. 정상 웹은 443
SNI 없음 — IP로 직접 접속
자체 서명(Subject = Issuer), 무작위 같은 .local 이름, 조직 정보 없음
유효 기간 10년 — 공인 인증서는 이렇게 길 수 없음
60초마다 비슷한 크기 — 비콘

판정: C2 통신일 가능성이 매우 높습니다. 내용은 해독 없이 볼 수 없지만, 이 조합이면 충분히 조치할 근거가 됩니다.

다음: PC 격리, 연결 프로세스 확인(Sysmon Event ID 3), IP 차단과 평판 조회, 인증서 지문(cert_chain_fps)으로 같은 인증서를 쓰는 다른 IP를 회사 로그와 인터넷 스캔 데이터에서 찾기(공격자 인프라 확장).

문제 2¶

회사가 TLS 해독을 도입한 뒤, 한 업무용 앱과 직원들의 은행 앱이 "연결할 수 없음" 오류를 냅니다. 왜 그런지, 어떻게 처리해야 하는지 설명하세요.

정답과 해설

원인: 인증서 고정(Certificate Pinning). 이런 앱은 "이 서버는 이 인증서(또는 이 CA)만 믿는다"고 정해 두어서, 해독 장비가 즉석에서 만든 회사 CA 서명 인증서를 받으면 중간자 공격으로 보고 연결을 끊습니다. 브라우저는 회사 루트 CA를 믿도록 설정돼 있어 괜찮지만, 고정을 쓰는 앱은 그 설정을 따르지 않습니다.

처리:

해당 앱의 목적지(도메인)를 해독 예외로 등록 — 예외 트래픽은 SNI·IP·양 같은 메타데이터만 봄
은행·의료 같은 분류는 개인정보·법적 이유로도 예외를 두는 경우가 많음. 조직 규정과 사용자 고지 확인
예외는 꼭 필요한 도메인만 좁게 두고 목록을 기록·검토 — 공격자가 예외 분류에 숨지 못하게
예외 트래픽은 엔드포인트(EDR)로 보완

문제 3¶

같은 C2 서버가 이제 TLS 1.3으로 통신합니다. 이전에 보이던 x509.log 인증서 정보가 더 이상 남지 않습니다. 무엇이 아직 보이고, 어떻게 탐지를 이어 갈 수 있습니까?

정답과 해설

TLS 1.3은 서버 인증서를 암호화해서 보내므로, 해독 없이는 인증서(Subject, Issuer, 기간)를 읽을 수 없습니다.

아직 보이는 것:

IP·ASN·국가, 포트(여전히 4444라면 그것만으로도 단서)
SNI(ECH를 쓰지 않는다면) — 이 경우처럼 IP 직접 접속이면 비어 있음, 그것도 단서
TLS 클라이언트·서버 지문(JA3·JA4·JA4S) — 악성코드의 TLS 라이브러리가 만드는 고유한 모양
양, 시간, 주기 — 60초 비콘은 그대로 보임

이어 가는 법:

지문과 주기 기반 탐지(JA4 목록, RITA 같은 비콘 분석)
같은 IP·ASN·지문을 쓰는 다른 연결 찾기
엔드포인트 — 어떤 프로세스가 연결했는지(Sysmon 3, EDR), 메모리에서 C2 설정 추출
필요하면 해독 범위 확대 검토