[부록]MSSQL 복호화 4-Hand Shaking(핸드셰이크) | DB 접근제어 관점의 TLS 흐름

MSSQL 복호화 4-Hand Shaking(핸드셰이크) 완전 가이드

이 문서는 DB 접근제어 게이트웨이(이하 “게이트웨이”)가 MSSQL Server와 통신하며 암호화 세션을 수립하고, 이후 암호화된 TDS(Tabular Data Stream) 패킷을 주고받기까지의 전 과정을 네트워크 관점(TCP)과 암호화 관점(TLS/SSL)에서 정밀하게 설명합니다. 실무에서 바로 쓸 수 있는 패킷 관찰 포인트, 인증서 구성 팁, 문제 발생 시 진단·복구 절차까지 포함했습니다.

용어 정리

게이트웨이DB 접근제어/프록시/중계 장치. 서버 측과의 TLS 세션에서는 “클라이언트” 역할. MSSQL Server1433 등에서 대기하는 데이터베이스 서버. TLS 세션에서는 “서버” 역할. TDSSQL Server의 응용계층 프로토콜. TLS 수립 후에는 암호화된 TDS가 흐름. TLS(SSL)전송 계층 보안. 여기서는 TLS 1.2 기준 흐름으로 설명(환경에 따라 다를 수 있음).

1) 간략 흐름도 — 4 Hand Shaking 요약

1. ClientHello — 게이트웨이가 지원 암호 제품군·랜덤 값·확장(SNI 등)을 제시
2. ServerHello + Certificate — MSSQL이 스위트 선택, 서버 인증서 전달(사설/공인 가능)
3. ClientKeyExchange — 대칭키 생성에 필요한 매개 전달(ECDHE 등 키교환)
4. ChangeCipherSpec / Finished — 이후부터는 대칭키로 암호화된 애플리케이션 데이터(TDS) 전송 시작

주의: 실무 문서에서 서버가 ClientHello를 보낸다는 식의 표기는 오기입니다. ClientHello는 항상 “클라이언트 역할”(여기서는 게이트웨이)가 보냅니다.

2) 상세 흐름도 — TCP 3-Way + TLS Handshake + 암호화된 TDS

[TCP 수립]
1) 게이트웨이 → MSSQL : SYN
2) MSSQL → 게이트웨이 : SYN/ACK
3) 게이트웨이 → MSSQL : ACK

[TLS Handshake]
4) 게이트웨이 → MSSQL : ClientHello
5) MSSQL → 게이트웨이 : ServerHello + Certificate (+ ServerKeyExchange, CertificateRequest 옵션)
6) 게이트웨이 → MSSQL : ClientKeyExchange (+ Certificate/CertificateVerify 옵션)
7) 게이트웨이 ↔ MSSQL : ChangeCipherSpec, Finished (쌍방 교환 후 애플리케이션 데이터 암호화 개시)

[업무 트래픽]
8) 양단 간 : Encrypted Application Data (암호화된 TDS Packet)

3) MSSQL 인증서·암호화 구성 핵심

항목	실무 포인트
서버 인증서(Windows)	MSSQL 서비스 계정이 접근 가능한 개인(Computer) 저장소에 배치. 개인키 포함 내보내기(PFX) 후 바인딩. CN 또는 SAN에 접속 FQDN 일치.
사설 CA 사용	게이트웨이에 해당 루트/중간 CA를 신뢰 저장소로 배포. 체인 불완전/만료 시 handshake_failure 또는 unknown_ca 유발.
암호 스위트	서버와 게이트웨이 공통 교집합 필요. 너무 약한 스위트 차단 시 초기 협상 실패 가능. 운영 표준을 문서화.
TLS 버전	운영 정책(TLS1.2 권장 등)에 맞춰 강제/허용 범위 설정. 버전 미스매치 시 protocol_version 에러.
SNI	게이트웨이가 SNI 확장을 보낼 경우, 인증서 선택·호스트명 검증에 도움. FQDN 일치 필요.
시간 동기화	NTP로 서버/게이트웨이 시계 동기화. 시간 불일치로 인증서 유효기간 판단 오류 발생 가능.

4) 패킷 캡처·관찰 포인트 (tcpdump / Wireshark)

4.1 빠른 필터

# TCP 수준(포트 1433 가정)
tcpdump -nn -i any tcp port 1433 -s0

# Wireshark 표시 필터(핸드셰이크 관찰)
tcp.port == 1433 and tls

# 세부 이벤트
tls.handshake.type == 1        # ClientHello
tls.handshake.type == 2        # ServerHello
tls.record.content_type == 22  # Handshake
tls.record.content_type == 20  # ChangeCipherSpec
tls.record.content_type == 23  # Application Data (= 암호화된 TDS)

4.2 정상 수립 체크리스트

• TCP 3-Way가 지연/재전송 없이 완료되는가?
• ClientHello에 합리적인 Cipher Suites와 SNI가 포함되는가?
• ServerHello + Certificate 수신 후 Alert 없이 ChangeCipherSpec/Finished로 이어지는가?
• TLS 완료 뒤에는 Application Data(암호화된 TDS)만 흐르는가?

5) 운영 진단: 실패 유형별 원인 → 조치

증상/로그	가능 원인	조치
unknown_ca, certificate_unknown	게이트웨이가 서버 인증서 발급CA를 신뢰하지 않음	루트/중간CA 체인을 게이트웨이 신뢰 저장소에 배포, 체인 정상화
bad_certificate / hostname mismatch	CN/SAN과 접속 호스트명이 불일치	FQDN 기준 인증서 재발급 또는 접속 설정을 인증서 이름과 일치
handshake_failure	암호 스위트/버전 교집합 없음	서버와 게이트웨이 양쪽 정책 재조정(TLS1.2 공통스위트 확보)
protocol_version	TLS 버전 미스매치	서버(레지스트리/구성) 또는 게이트웨이(보안정책)에서 허용 버전 동기화
certificate_expired	서버 인증서 만료	새 인증서 교체, 체인 검증 및 롤백 플랜 구비
초기 TCP 재전송/세션 리셋	FW/IPS 차단, MTU/PMTUD 이상, 포트 미열림	방화벽 정책/경로 MTU 점검, MSS clamp, 포트 상태 확인

6) 현장 점검 커맨드 (안전한 범위 예시)

6.1 암호화 수립 가시화

# 게이트웨이(리눅스 등)에서 서버 인증·스위트 확인
openssl s_client -connect db.example.com:1433 -tls1_2 -servername db.example.com -brief

# 인증서 체인만 빠르게 확인
openssl s_client -connect db.example.com:1433 -showcerts < /dev/null | openssl x509 -noout -subject -issuer -dates

6.2 MSSQL 포트/도달성

# PowerShell (클라이언트/게이트웨이 측)
Test-NetConnection db.example.com -Port 1433

# 리눅스
nc -vz db.example.com 1433

7) “복호화” 관점 이해 — 게이트웨이 아키텍처별 시나리오

• 종단암호(End-to-End): 클라이언트↔서버 TLS 직결. 게이트웨이는 L4/L7 관제·허용만 수행. 패킷 레벨에서 평문 TDS를 관찰하지 못함.
• TLS 중계(종단 분할): 클라이언트↔게이트웨이와 게이트웨이↔서버 이중 TLS. 게이트웨이는 서버 측 세션에서 클라이언트 역할로 ClientHello를 보냄. 정책에 따라 콘텐츠 검사/감사 가능.
• 사설 인증서 기반 가시화: 신뢰루트 하에 발급된 사설 인증서로 게이트웨이가 서버 역할을 수용(클라 측), 동시에 서버로는 클라 역할. 이 경우 게이트웨이 내부에서 평문 TDS 가시화·정책 적용.

포인트: 운영 환경에서 “복호화”라는 표현은 보통 게이트웨이 내부에서의 가시화를 의미합니다. 네트워크 패킷 캡처만으로는(제3지점) 평문 TDS를 보지 못하는 것이 정상입니다.

8) 감사·보안 체크리스트 (현장 적용)

• 게이트웨이 ↔ MSSQL 사이 ClientHello 주체가 게이트웨이인지 점검(로그/패킷으로 확인)
• 서버 인증서 CN/SAN ↔ 접속 FQDN 정합성
• CA 체인 완결/신뢰 배포 확인(루트·중간 누락 금지)
• TLS1.2 공통 스위트 확보(ECDHE_RSA with AESGCM 등)
• 방화벽/IPS 정책, 경로 MTU, 리셋/재전송 빈도 모니터링
• 게이트웨이 내부 정책(접속 주체·DB·쿼리 가시화/감사)의 단계적 적용 및 성능계수 산정

9) 트러블슈팅 Playbook (요약)

1. TCP 계층부터 정상화: 포트/방화벽/라우팅/MTU 확인, 재전송·RST 유무 체크
2. TLS 로그 확보: 게이트웨이/서버 이벤트(Windows Schannel, 애플리케이션 로그)
3. 인증서 체인 및 호스트명 검증: openssl로 신속 점검
4. 암호 스위트/버전 교집합 확보: 운영 보안정책 문서 반영
5. 성공 케이스 패킷 캡처를 골든 패턴으로 보관해 비교

부록 A. 사용자가 제공한 “간략/상세 흐름도”와의 정렬

[간략 흐름도] 항목은 표준 TLS 1.2 시퀀스와 일치합니다. 다만 [상세 흐름도] 중 “MSSQL Server → DB접근제어 : Client Hello”로 표기된 부분은 실제 표준 동작과 다릅니다. ClientHello는 게이트웨이(클라이언트 역할)가 보내는 것이 맞습니다. 본문 2) 상세 흐름도에서 이를 바로잡아 정리했습니다.

부록 B. 현장 점검 템플릿

# 점검 체크리스트(발췌)
[ ] TCP 3-Way 정상 (재전송/RST 없음)
[ ] ClientHello → ServerHello(+Certificate) → (키교환) → CCS/Finished 순서 확인
[ ] 서버 인증서 CN/SAN = 접속 FQDN
[ ] CA 체인 배포/만료검사 완료
[ ] TLS1.2 스위트 교집합 명시(ECDHE_RSA with AES_128_GCM_SHA256 등)
[ ] 성공 캡처 기준(골든)과 비교 결과 무이상

# 보고용 메모(예시)
- 대상: gw01 → mssql-prd01:1433
- 시각: 2025-11-07 11:20 KST
- 결과: TLS1.2 수립 OK, Cipher=ECDHE_RSA with AES_256_GCM_SHA384
- 조치: SNI 미설정 발견 → 게이트웨이에 FQDN 설정 적용(완료)

부록 C. Windows Schannel / OpenSSL 오류별 진단 사례

환경	이벤트 또는 메시지	의미 / 조치
Windows (Event Viewer)	Event ID 36887 — “A fatal alert was received from the remote endpoint.”	원격(게이트웨이)에서 TLS Alert 전송. Cipher 교집합 또는 인증서 문제일 가능성. 서버 TLS 정책 확인.
Windows (Event Viewer)	Event ID 36874 — “An SSL connection request was received... no suitable certificate.”	서버 측 인증서 매칭 실패. SQL Server Configuration Manager에서 올바른 인증서 재지정.
리눅스(OpenSSL)	ssl handshake failure / tlsv1 alert unknown ca	게이트웨이 쪽 루트CA 누락. /etc/pki/ca-trust/source/anchors에 루트CA 추가 후 update-ca-trust extract.
리눅스(OpenSSL)	ssl alert certificate expired	서버 인증서 만료. 새 인증서 교체 및 체인 점검 필요.
리눅스(OpenSSL)	handshake failure (no shared cipher)	TLS 버전/스위트 불일치. openssl ciphers -v | grep TLSv1.2로 교집합 검토.

부록 D. MTU / PMTUD (Path MTU Discovery) 튜닝 가이드

TLS 수립 중 초기 패킷 손실이 발생하면 대체로 방화벽/라우터 단의 ICMP 차단이나 MTU 불일치가 원인일 가능성이 높습니다.

D.1 진단 절차

# 1) MTU 확인
ip link show dev eth0
# 2) Path MTU 점검
tracepath db.example.com
# 3) PMTU 테스트 (Don't Fragment 플래그)
ping -M do -s 1472 db.example.com

# MSS Clamp 예시 (iptables)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
         -j TCPMSS --clamp-mss-to-pmtu

D.2 조치 요약

• VPN/터널 구간은 MTU 1400~1420으로 낮추기
• 스위치/라우터 ICMP Fragmentation Needed 허용
• 게이트웨이 ↔ MSSQL 구간 동일 MTU 유지

부록 E. 내부 교육용 시각화 설명

다음 도식은 TLS 4-Hand Shaking의 패킷 흐름을 **게이트웨이 관점**에서 단계별로 해석한 것입니다.

┌─────────────┐ ┌───────────────┐
│ DB 접근제어 │ │ MSSQL Server │
├─────────────┤ ├───────────────┤
│ SYN ───────▶│ ① TCP 세션 시작
│ ◀────── SYN/ACK │ ② 응답
│ ACK ───────▶│ ③ 연결 완료
│ ClientHello ─▶│ ④ 암호 협상 개시
│ ◀── ServerHello+Cert │ ⑤ 인증서 교환
│ ClientKeyEx ─▶│ ⑥ 키교환 완료
│ CCS/Finished ─▶│ ⑦ 세션 암호화 전환
│ ◀── Encrypted Data │ ⑧ 암호화된 TDS 전송

이 시퀀스는 Wireshark 상에서도 동일하게 관찰됩니다. 패킷의 Record Layer 항목을 열어보면 Handshake Type과 Cipher Suite 협상 과정을 실시간으로 추적할 수 있습니다.

부록 F. 교육용 핵심 요약 슬라이드용 문장 (발표용)

• “MSSQL의 TLS 핸드셰이크는 단순한 암호화 협상이 아니라, 정상 통신을 위한 인증·암호·신뢰 체인 수립 단계다.”
• “게이트웨이는 TLS에서 항상 클라이언트 역할이며, ClientHello를 송신한다.”
• “사설 인증서 사용 시 체인 신뢰성이 확보되지 않으면 handshake_failure가 발생한다.”
• “복호화는 네트워크 외부에서 불가능하며, 게이트웨이 내부에서 정책 기반 가시화로 수행된다.”

교육 활용 팁: 상기 흐름도와 표를 PPT 슬라이드로 구성할 때는 ClientHello / ServerHello / Finished를 강조 색으로 표시하고, TCP 3-Way와 TLS Handshake를 구분선으로 나누면 직관적인 시각화가 가능함.

[기본 글 - 4hand shaking]

2025.11.07 - [경험 공유/ETC] - [기초]MSSQL 복호화 4-Hand Shaking(핸드셰이크) | DB 접근제어 관점의 TLS 흐름

[기초]MSSQL 복호화 4-Hand Shaking(핸드셰이크) | DB 접근제어 관점의 TLS 흐름