[기초]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 설정 적용(완료)