📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 138편
이전 글: 137. HTTP Packet 분석 · 다음 글: 139. FTP Packet 분석
1. 개념
HTTPS의 구성(HTTP + TLS), Handshake 요소, SNI 추출 명령은 62. HTTPS와 TLS Handshake — 암호화된 통신에서 볼 수 있는 것에서 다뤘습니다. 이 글은 암호화된 HTTPS 연결이 Wireshark 화면에서 어떤 레코드로 보이고, 내용을 볼 수 없는 상태에서 무엇으로 판단하는가에 집중합니다.
TLS 데이터는 레코드 단위로 전송되며, 레코드 헤더는 암호화되지 않습니다.
tls.record.content_type | 이름 | 화면에서 보이는 것 |
|---|---|---|
| 20 | Change Cipher Spec | 짧은 전환 신호 (TLS 1.3에서는 호환용) |
| 21 | Alert | 오류·종료 알림 (암호화 후에는 내용 비공개) |
| 22 | Handshake | ClientHello, ServerHello, Certificate 등 |
| 23 | Application Data | 암호화된 HTTP 요청·응답 |
| 확인 필드 | 읽는 내용 |
|---|---|
tls.handshake.type | 1 ClientHello, 2 ServerHello, 11 Certificate, 4 NewSessionTicket 등 |
tls.handshake.version, tls.handshake.extensions.supported_version | 협상 버전 (TLS 1.3은 확장 필드로 판단) |
tls.handshake.extensions_server_name | 접속하려는 호스트 이름(SNI) |
tls.handshake.extensions_alpn_str | 상위 프로토콜 협상값 (h2, http/1.1 등) |
tls.handshake.ciphersuite | ServerHello가 선택한 암호 스위트 |
tls.alert_message.desc | 평문 Alert의 종류 |
2. 동작 원리
TCP 443 연결 수립 (tcp.stream N)
↓
Handshake 레코드 (평문 구간)
ClientHello : SNI, ALPN, 지원 버전·스위트 목록
ServerHello : 선택 버전·스위트
Certificate : TLS 1.2 → 평문으로 보임 / TLS 1.3 → 암호화되어 보이지 않음
↓
Application Data 레코드 (암호화 구간)
→ 크기·방향·시간 간격만 관찰 가능
↓
종료: Alert(close_notify, 암호화됨) 또는 TCP FIN/RST- TLS 1.3은 레코드 헤더의 버전을 호환용 값(0x0303, "TLS 1.2")으로 표시하므로, 레코드 버전만 보고 1.2라고 판단하면 안 됩니다. ServerHello의
supported_version확장을 확인합니다. - 브라우저 트래픽 상당수는 UDP 443의 QUIC(HTTP/3)으로 전송될 수 있으며, 이 경우 필터는
quic이고 TCP 443만 보면 누락됩니다.
3. 주요 특징
TLS 1.2와 1.3에서 캡처로 보이는 정보
| 정보 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| SNI | 보임 | 보임 (ECH 사용 시 가려질 수 있음) |
| 서버 인증서(주체·발급자·유효기간) | 보임 | 암호화됨 |
| 선택된 암호 스위트 | 보임 | 보임 |
| HTTP 경로·헤더·본문 | 암호화 | 암호화 |
| 레코드 크기·간격 | 보임 | 보임 |
자주 쓰는 Display Filter
| 필터 | 용도 |
|---|---|
tls.handshake.type == 1 | 모든 ClientHello (접속 시도 목록) |
tls.handshake.type == 1 && !tls.handshake.extensions_server_name | SNI 없는 ClientHello |
tls.handshake.type == 11 | 인증서가 평문으로 보이는 Handshake |
tls.record.content_type == 21 | Alert 레코드 |
tcp.port == 443 && !tls | 443 포트인데 TLS로 해석되지 않는 트래픽 |
quic | UDP 기반 HTTP/3 트래픽 |
4. 예시
실습 예시 — 본인 소유 VM에서 HTTPS 접속을 캡처해 Handshake 메타데이터를 추출합니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.
sudo tcpdump -i ens33 -nn -w /tmp/https.pcapng 'tcp port 443 or udp port 443' &
curl -s https://www.example.com/ -o /dev/null
sudo pkill -INT tcpdump
# ClientHello: 스트림, 목적지, SNI, ALPN
tshark -r /tmp/https.pcapng -Y 'tls.handshake.type == 1' -T fields -E header=y \
-e tcp.stream -e ip.dst -e tls.handshake.extensions_server_name -e tls.handshake.extensions_alpn_str
# ServerHello: 협상 버전과 스위트 (TLS 1.3이면 supported_version에 0x0304)
tshark -r /tmp/https.pcapng -Y 'tls.handshake.type == 2' -T fields -E header=y \
-e tcp.stream -e tls.handshake.version -e tls.handshake.extensions.supported_version -e tls.handshake.ciphersuite
# 스트림별 Application Data 레코드 수와 크기
tshark -r /tmp/https.pcapng -Y 'tls.record.content_type == 23' -T fields -e tcp.stream -e ip.src -e tls.record.lengthServerHello 추출의 형식 예시입니다.
tcp.stream tls.handshake.version supported_version tls.handshake.ciphersuite
0 0x0303 0x0304 0x1302| 확인 포인트 | 읽는 법 |
|---|---|
| version 0x0303 | 호환용 표기 (값 자체는 TLS 1.2) |
| supported_version 0x0304 | 실제 협상 버전 TLS 1.3 |
| ciphersuite 0x1302 | TLS_AES_256_GCM_SHA384 |
복호화 실습의 범위: 본인 소유 VM에서 클라이언트가 세션 키를 파일로 남기게 하고(SSLKEYLOGFILE 환경 변수를 지원하는 curl·브라우저), Wireshark의 TLS 설정 "(Pre)-Master-Secret log filename"에 지정하면 해당 세션의 HTTP 내용을 확인할 수 있습니다. 관제 현장에서는 이 키가 없으므로 메타데이터 분석이 기본입니다.
📷 [실습 화면 삽입 위치] ClientHello Details에서 Extension: server_name, application_layer_protocol_negotiation, supported_versions를 펼친 화면
📷 [실습 화면 삽입 위치] 같은 스트림의 Packet List에서 Handshake 이후 Application Data 레코드만 이어지는 모습(Info 열)이 보이는 화면
5. 보안 관점
| 관찰 | 가능한 해석 | 확인할 것 |
|---|---|---|
| SNI 없는 ClientHello, IP로 직접 접속 | 일부 악성 도구·C2의 형태 (정상 앱도 존재) | 목적지 평판, 이전 DNS 질의 |
| TLS 1.2 인증서가 자체 서명·짧은 유효기간·무의미한 주체 | 급조된 서버 가능성 | 발급자, 주체 이름 |
| 443인데 TLS로 해석 안 됨 | 포트만 빌린 다른 프로토콜 | 페이로드 바이트, Follow Stream |
| 일정 간격·비슷한 크기의 Application Data 반복 | 비콘 형태 통신 (147. 외부 비정상 통신 분석) | 간격 분포, 세션 지속 시간 |
| 업로드 방향 레코드 크기가 다운로드보다 훨씬 큼 | 외부 전송 가능성 | 총 바이트, 목적지 |
| Handshake 직후 Alert·RST 반복 | 인증서 검증 실패, 차단 장비 개입 | 평문 Alert 종류, 차단 로그 |
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 패킷 캡처 | SNI, 버전, 스위트, (1.2) 인증서, 레코드 크기·간격 |
| 프록시·SSL 검사 장비 | 복호화된 URL (조직 정책상 검사하는 경우) |
| 방화벽·NetFlow | 목적지, 바이트, 세션 시간 |
| IDS | TLS 메타데이터(SNI·인증서·지문) 기반 이벤트 |
관제자가 확인할 질문
- 이 연결의 SNI와 목적지 IP가 같은 서비스로 설명되는가?
- 주기성·전송 방향·크기가 해당 서비스의 평소 모습과 맞는가?
- TCP 443 외에 QUIC(UDP 443) 트래픽도 확인했는가?
오탐 주의: 업데이트·클라우드 동기화·메신저는 주기적이고 장시간 유지되는 HTTPS를 만듭니다. SNI 없는 연결도 일부 정상 앱에서 발생합니다. 한 가지 지표로 판단하지 말고 목적지 평판·DNS 이력·호스트 프로세스를 함께 확인하며, ClientHello 지문 기반 탐지(JA3 등)는 필드 제공 여부가 Wireshark 버전마다 다르므로 06 영역의 IDS 글에서 다룹니다.
7. 핵심 정리
- HTTPS는 레코드 헤더(
tls.record.content_type20~23)와 Handshake 일부만 평문이고, HTTP 내용은 Application Data로 암호화됩니다. - TLS 1.3은 레코드 버전이 0x0303으로 보이므로
supported_version확장으로 실제 버전을 확인합니다. - 인증서는 TLS 1.2에서만 캡처로 보이며, SNI·ALPN·스위트는 두 버전 모두 확인할 수 있습니다.
- UDP 443의 QUIC도 함께 봐야 웹 트래픽 누락이 없습니다.
- 내용을 볼 수 없으므로 SNI·목적지·레코드 크기·간격·방향 같은 메타데이터를 조합해 판단합니다.
