17장. 전송 계층 보안 (Transport-Level Security)

학습 목표

웹 보안 위협과 트래픽 보안 접근법을 요약한다.

TLS(Transport Layer Security)의 개요를 제시한다.

TLS Record Protocol, Handshake Protocol, Alert Protocol의 동작을 이해한다.

HTTPS(HTTP over SSL/TLS)의 개요를 제시한다.

SSH(Secure Shell)의 개요를 제시한다.

17.1 웹 보안 고려사항

웹 보안 위협

위협 범주	예시	대응
무결성	사용자 데이터 변조, 트로이 목마 브라우저, 전송 중 메시지 수정	암호학적 체크섬
기밀성	네트워크 도청, 서버/클라이언트 정보 탈취, 통신 패턴 노출	암호화, 웹 프록시
서비스 거부	스레드 고갈, 보거스 요청 폭주, 디스크/메모리 소진, DNS 공격	방어 어려움
인증	사용자/서버 위장, 데이터 위조	암호학적 기법

보안 적용 위치

계층	접근법	예시	특징
네트워크 (IP)	IPsec	20장 참조	투명, 범용, 필터링 가능
전송 (TCP 위)	SSL/TLS	본 장	앱 투명 또는 내장 가능
응용	앱 내장 보안	S/MIME, Kerberos, SET	앱 맞춤형

17.2 TLS (Transport Layer Security)

SSL에서 발전한 인터넷 표준 (TLSv1.2: RFC 5246). TCP 위에서 동작하며 기밀성 + 메시지 무결성을 제공한다.

TLS 아키텍처 — 두 계층의 프로토콜

하위 계층: TLS Record Protocol — 기본 보안 서비스 (암호화, MAC)

상위 계층: Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol, Heartbeat Protocol, 그리고 HTTP 등 애플리케이션 프로토콜

세션과 연결

개념	정의	특성
세션 (Session)	클라이언트-서버 간의 연관. Handshake로 생성	암호 파라미터를 정의하며 여러 연결에서 공유 가능
연결 (Connection)	전송 계층의 피어 간 관계	일시적. 각 연결은 하나의 세션에 속함

세션 상태 파라미터: 세션 ID, 피어 인증서, 압축 방법, 암호 사양(Cipher Spec), 마스터 시크릿(48바이트), 재개 가능 플래그

연결 상태 파라미터: 클라이언트/서버 랜덤값, MAC 쓰기 시크릿, 쓰기 키, IV, 시퀀스 번호

TLS Record Protocol

처리 단계	설명
분할 (Fragment)	상위 계층 데이터를 $2^{14}$ 바이트 이하 블록으로 분할
압축 (Compress)	선택적 무손실 압축 (TLSv1.2에서는 null이 기본)
MAC 추가	HMAC 계산 (MAC_write_secret, seq_num ∥ type ∥ version ∥ length ∥ fragment)
암호화 (Encrypt)	대칭 암호로 암호화. 블록 암호 시 패딩 추가
헤더 추가	Content Type(8b) + Version(16b) + Length(16b)

MAC-then-Encrypt

TLS Record Protocol은 MAC을 먼저 계산한 뒤 평문 + MAC을 함께 암호화한다. 스트림 암호에서는 패딩 없이, 블록 암호에서는 블록 크기의 배수가 되도록 패딩을 추가한다. 가변 길이 패딩으로 메시지 길이 분석 공격을 방어한다.

Change Cipher Spec Protocol

단일 바이트(값 1)로 구성된 가장 단순한 프로토콜. 대기 상태(pending state)를 현재 상태(current state)로 전환 — 협상된 암호 스위트를 활성화한다.

Alert Protocol

2바이트 메시지: 심각도(warning/fatal) + 경고 코드.

Fatal 경고 (즉시 연결 종료): unexpected_message, bad_record_mac, handshake_failure, illegal_parameter, decompression_failure, decryption_failed, record_overflow, unknown_ca, access_denied, decode_error, protocol_version, insufficient_security, internal_error 등

기타 경고: close_notify, bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown, decrypt_error, user_canceled, no_renegotiation

Handshake Protocol

TLS의 핵심 프로토콜. 서버·클라이언트 인증, 암호 알고리즘·키를 협상한다.

4단계:

Phase 1 — Hello 교환 (보안 능력 수립):

메시지	내용
ClientHello	최고 TLS 버전, 랜덤(32비트 타임스탬프 + 28바이트 난수), 세션 ID, 암호 스위트 목록, 압축 방법 목록
ServerHello	선택된 버전·랜덤·세션 ID·암호 스위트·압축 방법

암호 스위트의 첫 요소는 키 교환 방법: RSA, 고정 DH, 임시(Ephemeral) DH, 익명 DH. 나머지는 CipherSpec: 암호 알고리즘(AES, 3DES, RC4), MAC 알고리즘(MD5, SHA-1), 암호 유형(스트림/블록), IV 크기 등.

익명 Diffie-Hellman

인증 없이 DH 교환을 수행하므로 중간자 공격에 취약하다.

Phase 2 — 서버 인증·키 교환:

Certificate: 서버의 X.509 인증서 체인 전송 (익명 DH 제외)
ServerKeyExchange: 임시 DH 파라미터+서명, 또는 익명 DH 파라미터 (고정 DH / RSA 인증서의 경우 불필요)
CertificateRequest: 클라이언트 인증서 요청 (선택)
ServerHelloDone: 서버 Hello 단계 완료

Phase 3 — 클라이언트 인증·키 교환:

Certificate: 요청된 경우 클라이언트 인증서 전송
ClientKeyExchange: RSA → 48바이트 pre_master_secret을 서버 공개키로 암호화. DH → 클라이언트의 DH 공개 파라미터
CertificateVerify: 이전 핸드셰이크 메시지의 해시를 클라이언트 개인키로 서명 → 인증서 소유 증명

Phase 4 — 완료:

클라이언트: change_cipher_spec → finished (새 알고리즘·키·시크릿으로 즉시 전환)
서버: change_cipher_spec → finished

$\text{finished} = \text{PRF}(\text{master\_secret},\; \text{label},\; \text{MD5(msgs)} \| \text{SHA-1(msgs)})$

암호학적 계산

마스터 시크릿 생성:

pre_master_secret 교환 (RSA → 클라이언트 생성·암호화, DH → 양측 계산)
마스터 시크릿 도출:

$\text{master\_secret} = \text{PRF}(\text{pre\_master\_secret},\; \text{"master secret"},\; \text{ClientHello.random} \| \text{ServerHello.random})$

48바이트 출력. 이로부터 키 블록을 도출:

$\text{key\_block} = \text{PRF}(\text{master\_secret},\; \text{"key expansion"},\; \text{server\_random} \| \text{client\_random})$

키 블록에서 순서대로 추출: client write MAC secret, server write MAC secret, client write key, server write key, client write IV, server write IV.

PRF: HMAC 기반 데이터 확장 함수:

$P\_\text{hash}(\text{secret}, \text{seed}) = \text{HMAC}(\text{secret}, A(1) \| \text{seed}) \| \text{HMAC}(\text{secret}, A(2) \| \text{seed}) \| \cdots$

$A(0) = \text{seed}, \quad A(i) = \text{HMAC}(\text{secret}, A(i-1))$

Heartbeat Protocol

RFC 6520. 연결이 살아 있는지 확인하는 keep-alive 메커니즘. heartbeat_request에 랜덤 페이로드(16B~64KB)를 포함하고, heartbeat_response에 동일 페이로드를 반환한다.

Heartbleed 취약점 (2014)

heartbeat_request의 페이로드 길이 필드를 검증하지 않는 구현 결함으로, 공격자가 서버 메모리 최대 64KB를 유출할 수 있었다. 개인키, 세션키, 사용자 자격증명 등이 노출 위험에 처했으며, 역사상 가장 심각한 TLS 취약점 중 하나로 기록되었다.

TLSv1.3 주요 변경

변경 사항	설명
제거된 기능	압축, 비인증 암호, 정적 RSA/DH 키 교환, 32비트 타임스탬프, 재협상, Change Cipher Spec, RC4, MD5/SHA-224 서명
키 교환	DH 또는 ECDH만 허용 → 순방향 비밀성(Forward Secrecy) 보장 (RSA 제거)
1-RTT 핸드셰이크	클라이언트가 ClientKeyExchange를 먼저 전송 → 서버가 첫 응답 전에 키 계산 가능 → 속도 향상 + 공격면 축소
핸드셰이크 후 암호화	모든 핸드셰이크 메시지가 암호화됨

TLSv1.3의 설계 철학

코드를 줄이면 잠재적 코딩 오류와 공격면이 줄어든다. 불필요하거나 위험한 옵션을 과감히 삭제하여 효율성과 보안을 동시에 개선한다.

17.3 HTTPS

HTTP를 TLS 위에서 실행. URL은 https://로 시작, 기본 포트 443.

암호화 대상: 요청 URL, 문서 내용, 브라우저 폼 내용, 쿠키, HTTP 헤더.

연결 개시: 클라이언트가 적절한 포트에 연결 → TLS ClientHello 전송 → 핸드셰이크 완료 후 HTTP 요청 시작. 모든 HTTP 데이터는 TLS 응용 데이터로 전송.

연결 종료: Connection: close 헤더 포함 → TLS close_notify 경고 → TCP 연결 종료.

예고 없는 TCP 종료

close_notify 없이 TCP 연결이 끊기면 프로그래밍 오류, 통신 장애, 또는 공격의 징후일 수 있다. HTTPS 클라이언트는 이 경우 보안 경고를 표시해야 한다.

17.4 SSH (Secure Shell)

안전한 원격 로그인·파일 전송·네트워크 서비스를 위한 프로토콜. TELNET을 대체. TCP 위에서 동작하며 3개 프로토콜로 구성된다.

SSH 프로토콜 계층

프로토콜	기능
Transport Layer Protocol	서버 인증, 기밀성, 무결성, 압축. 순방향 비밀성 제공. 호스트 키 기반 서버 인증
User Authentication Protocol	서버에 대한 사용자 인증. Transport Layer 위에서 동작
Connection Protocol	단일 SSH 연결 위에 다중 논리 채널 멀티플렉싱

Transport Layer Protocol

호스트 키: 서버가 공개/개인 키 쌍을 보유. 클라이언트는 서버의 공개키를 (1) 로컬 데이터베이스 또는 (2) CA 인증서로 알고 있어야 한다.

패킷 교환 흐름:

식별 문자열 교환: SSH-protoversion-softwareversion 형식
알고리즘 협상: SSH_MSG_KEXINIT 교환 — 키 교환, 암호화, MAC, 압축 알고리즘을 클라이언트 선호도 순으로 협상
키 교환: Diffie-Hellman 방식

$e = g^x \bmod p \;\text{(C→S)}, \quad f = g^y \bmod p \;\text{(S→C)}$

$K = e^y \bmod p = f^x \bmod p$

$H = \text{hash}(V_C \| V_S \| I_C \| I_S \| K_S \| e \| f \| K)$

서버가 $H$ 를 호스트 개인키로 서명하여 전송 → 클라이언트가 검증. $H$ 는 세션 식별자로 사용 (키 재교환 후에도 변경 불가).

키 교환 완료: SSH_MSG_NEWKEYS 교환 → 이후 모든 데이터 암호화·MAC 적용
서비스 요청: 사용자 인증 또는 연결 프로토콜 요청

키 생성: 공유 비밀 $K$ , 해시 $H$ , 세션 ID로부터:

$\text{IV}_{C \to S} = \text{HASH}(K \| H \| \text{"A"} \| \text{session\_id})$

$\text{Enc Key}_{C \to S} = \text{HASH}(K \| H \| \text{"C"} \| \text{session\_id})$

$\text{MAC Key}_{C \to S} = \text{HASH}(K \| H \| \text{"E"} \| \text{session\_id})$

(서버→클라이언트 방향은 각각 "B", "D", "F" 사용)

User Authentication Protocol

인증 방법 3가지:

방법	설명
publickey	클라이언트 공개키를 전송하고, 메시지를 개인키로 서명
password	평문 비밀번호 (Transport Layer가 암호화 보호)
hostbased	클라이언트 호스트를 인증. 호스트 개인키로 서명 → 서버가 호스트를 신뢰

Connection Protocol

보안 인증 연결(터널) 위에 다중 논리 채널을 멀티플렉싱한다.

채널 유형 4가지: session (원격 프로그램 실행), x11 (X Window 포워딩), forwarded-tcpip (원격 포트 포워딩), direct-tcpip (로컬 포트 포워딩)

포트 포워딩 (SSH 터널링): 비보안 TCP 연결을 보안 SSH 연결로 변환하는 기능.

로컬 포워딩: 클라이언트 측에서 특정 포트의 트래픽을 SSH 터널로 리다이렉트 → 원격 서버의 목적지 포트로 전달
원격 포워딩: 서버 측에서 특정 포트의 트래픽을 SSH 터널로 리다이렉트 → 클라이언트 측 목적지 포트로 전달

로컬 포워딩 예시 (POP3 이메일)

SSH 클라이언트가 메일 서버에 SSH 연결 수립
로컬 포트 9999를 원격 포트 110(POP3)에 매핑하도록 구성
이메일 클라이언트가 로컬 9999로 전송 → SSH가 암호화하여 터널로 전송 → 서버가 복호화하여 포트 110으로 전달
응답도 역방향으로 터널을 통해 전달

주요 용어

한글	영문
경고 프로토콜	Alert Protocol
암호 사양 변경 프로토콜	Change Cipher Spec Protocol
핸드셰이크 프로토콜	Handshake Protocol
하트비트 프로토콜	Heartbeat Protocol
HTTPS	HTTP over TLS
마스터 시크릿	master secret
세션	session
연결	connection
순방향 비밀성	forward secrecy
SSH	Secure Shell
전송 계층 보안	Transport Layer Security (TLS)
포트 포워딩	port forwarding

17.1 웹 보안 고려사항​

웹 보안 위협​

보안 적용 위치​

17.2 TLS (Transport Layer Security)​

TLS 아키텍처 — 두 계층의 프로토콜​

세션과 연결​

TLS Record Protocol​

Change Cipher Spec Protocol​

Alert Protocol​

Handshake Protocol​

암호학적 계산​

Heartbeat Protocol​

TLSv1.3 주요 변경​

17.3 HTTPS​

17.4 SSH (Secure Shell)​

SSH 프로토콜 계층​

Transport Layer Protocol​

User Authentication Protocol​

Connection Protocol​

주요 용어​