보안산업기사 학습 과정에서 SSL/TLS 프로토콜에 대한 기본적인 개념과 이론을 숙지하고 있었지만 시간이 지남에 따라 일부 내용이 흐릿해지고 들으면 기억은 나지만 바로 설명하기에는 어려운 상태가 되었음
클라우드 보안을 심화 학습하는 과정에서 VPN 기술 전반을 정리하던 중 SSL VPN을 다루기 전에 기반이 되는 기술인 SSL/TLS의 구조와 동작원리를 명확히 정리할 필요성을 느껴 정리해보고자 함
✨SSL/TLS의 개요
Secure Socket Layer [SSL]
Tranport Layer Security [TLS]
🔸정의와 역할
SSL와 TLS는 애플리케이션 계층(L7)과 전송 계층(L4) 사이에서 동작하는 전송 계층 보안 프로토콜로 SSL은 Netscape사 에서 WWW[World Wide Web]를 이용하여 안전한 통신 보장을 위하여 개발되었으며 TLS는 SSL 3.0을 기준으로 IETF [Internet Engineering Task Force]의 Transport Area에서 표준화를 한 보안 프로토콜임
공개키 기반구조(PKI)를 활용한 상호 인증과 대칭키 암호화를 결합하여 네트워크 전송 구간에서 데이터 기밀성(Confidentiality)·무결성(Integrity)·인증(Authentication)을 보장함
- 기밀성: 세선 키를 사용한 대칭키 암호화로 전송 데이터 내용을 비인가자가 해독하지 못하도록 보호함
- 무결성: 메시지 인증 코드(MAC) 또는 HMAC을 통해 전송 데이터 변조 여부를 검증함
- 인증: X.509 디지털 인증서를 이용하여 Server(및 필요시 Client)의 신원 검증을 수행함
전송 계층 보안 프로토콜의 필요성
- HTTP, SMTP, FTP 등 전송 계층 위에서 동작하는 다수의 애플리케이션 프로토콜은 기본적으로 평문 통신을 수행하며, 이는 패킷 스니핑·중간자 공격(MITM)에 취약함
- SSL/TLS를 적용하면 애플리케이션 데이터가 암호화·서명 처리되어 도청 및 변조 방지가 가능하며, 종단 간 신뢰성이 확보됨
🔸HTTPS와의 관계
HTTPS(Hypertext Tranfer Protocol Secure)는 HTTP 프로토콜 위에 SSL/TLS 계층을 결합하여 웹 통신 구간에 암호화·무결성·인증 기능을 제공하는 프로토콜로 기본적으로 TCP 443번 포트를 사용하며, 암호화 세션 수립 후 HTTP 요청·응답 데이터가 SSL/TLS 세션 내부에서 전송됨
HTTPS = HTTP + SSL/TLS
-
동작 포트: 기본 443/TCP (변경 가능)
-
SSL/TLS 적용 방식
Implicit TLS
: 연결 시점부터 SSL/TLS 사용 (HTTPS가 대표)STARTTLS
: 기존 평문 연결을 SSL/TLS로 업그레이드하는 방식(SMTP, IMAP 등에서 사용)ALPN(Application-Layer Protocol Negottiation)
: SSL/TLS 핸드셰이크 중 애플리케이션 프로토콜 결정(예 : HTTP/2, HTTP/3 선택)
-
HTTP 외 적용 사례
: SMTP(SMTPS, STARTTLS), IMAP(IMAPS), POP3(POP3S), FTP 등 다양한 애플레이션 프로토콜에서 활용 가능
✨동작 원리와 구성 요소
🔸SSL/TLS 통신 구조
SSL/TLS는 크게 2계층으로 이루어짐
- 상위 계층 : Handshake, ChangeCipherSpe,c Alert, Application Data
- 하위 계층 : Record Protocol
전송 계층과의 관계
SSL/TLS는 전송 계층(TCP) 위에서 동작하는 보안 계층 프로토콜로, 애플리케이션 계층과 전송 계층 사이에 위치함
- 별도의 구현없이도 안전
: 전송 계층에서 제공하는 신뢰성 있는 바이트 스트림위에 암호화·무결성·인증기능을 추가하여 상위 애플리케이션 프로토콜이 별도의 보안기능을 구현하지 않아도 안전하게 통신이 가능 함 - 프로토콜 독립성
: 프로토콜 독립성을 가지므로 HTTP 외에도 SMTP, IMAP, FTP 등 다양한 애플리케이션 프로토콜에 적용가능 함
상위 계층 프로토콜
여러 Control Protocol과 Application Data Protocol은 Record Procotol 위에서 작동함
-
Handshake Protocol- 초기 연결 시 종단 간에 보안 파라미터 협상(암호 스위트, TLS 버전 등), 키 교환, Client/Server 인증을 수행
- RSA, (EC)DHE 등 키 교환 방식에 따라 Pre-Master Secret 생성
- TLS 1.3에서는 라운드 트립 감소(1-RTT), PFS 필수화, 암호 스위트 단순화 적용
-
ChangeCipherSpec Protocol- Client/Server가 지금부터 협상된 암호 파라미터를 적용/변경함을 통지하는 신호
- TLS 1.3에서는 기능이 Handshake 내부로 통합되어 별도 프로토콜 메시지로 거의 사용되지 않음
-
Alert Protocol- 오류나 상태 변경을 통보하는 메시지
- 경고(Alert Level: Warning)와 치명적 오류(Alert Level: Fatal)로 구분
- 치명적 오류 발생 시 즉시 세션 종료
-
Application Data Protocol- Handshake 완료 후 암호화된 실제 애플리케이션 계층 데이터(HTTP, SMTP 등)를 송수신
- 모든 Application Data 는 Record Protocol을 통해 암호화·무결성 검증 후 전송됨
Record Protocol의 구조
적용 /변경된 보안 파라미터를 이용하여 실제 암호화/복호화, 무결성 보호, 압축/압축해제 등의 기능을 제공하는 프로토콜
레코드(Record)는 핵심 전송 단위로 모든 상위 계층 메시지는 Record Protocol에 의해 처리됨
-
Fragmentation
: 상위 계층 메시지를 SSL/TLS 레코드 크기(최대 16KB) 이하로 분할 -
Opional Compress후 MAC 추가
: 협상을 통해 적용된 압축 알고리즘으로 선택적 데이터 압축 (현재는 CRIME, BREACH 등의 압축 기반 공격 위험으로 대부분 비활성화) 후 HMAC 또는 AEAD 방식의 무결성 코드 생성 및 추가 -
Encryption
: 협상을 통해 적용된 암호 알고리즘으로 암호화 수행 -
Record Header 추가
: 콘텐츠 타입, 버전 길이, 길이 정보가 포함된 헤더를 붙여 TCP 세그먼트로 전송
🔸대칭/비대칭 암호
대칭키 암호
동일한 키로 암호화와 복호화를 수행하는 암호 방식
- 연산 속도가 빠르고 구현이 단순함
- 키 길이가 고정되고, 동일 키를 모든 참여자가 공유해야 함
- 키 분배 과정에서 안전한 채널이 필요
- SSL/TLS에서의 역할
- Handshake 이후 Application Data 암호화에 사용
- 대량 데이터 전송 시 효율적인 보안 제공
- 예시 알고리즘
- AES: 블록 암호, GCM(인증 암호화)·CBC(패딩 기반) 모드
- ChaCha20-Poly1305: 스트림 암호, 모바일·저사양 환경에 최적화
비대칭키 암호
공개키(public key)와 개인키(pricate key)를 사용하는 암호 방식
- 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있음 (역도 성립)
- 키 교환 및 디지털 서명에 주로 사용
- 연산량이 많아 대용량 데이터 암호화에는 비효율적
- SSL/TLS에서의 역할
- 서버 인증서 기반 서버 신원 검증
- 세션 키(대칭 키) 교환 시 초기 handshake 구간에 사용
- 예시 알고리즘
- RSA: 모듈러 거듭제곱 기반, 키 길이에 따라 보안 강도 결정
- ECDSA: 타원곡선 기반 전자서명, 짧은 키로 높은 보안성 제공
- ECDH: 타원곡선 기반 키 교환, Forward Secrecy 구현 가능
SSL/TLS에서의 혼합 사유
비대칭 암호의 안전한 키 교환 및 신원 인증과 대칭 암호의 높은 처리 속도와 낮은 연산 부하 등의 장점을 이용
SSL/TLS는 두 방식을 결합하여 보안성과 성능을 모두 확보
- Hybrid Cyptosystem 구조
- 초기 handshake 구간: 비대칭 암호를 통해 세션 키(대칭 키) 생성 및 교환
- 데이터 송수신 구간: 대칭 암호를 통해 빠르고 안전하게 암호화
비대칭 암호만 사용할 경우 성능이 저하되며 대칭 암호만 사용할 경우 키 교환 시 보안이 취약해짐
🔸PKI 구조와 디지털 인증서
PKI (Public Key Infrastructure)
공개키 기반 암호 시스템을 운영 및 관리하기 위한 조직적, 기술적 인프라로 키는 한 쌍으로 발급되며 인증서 생성,배포,폐지와 신뢰 검층 체계를 포함함
SSL/TLS내에서 PKI는 server/client 신원 보증과 공인 CA 서명 기반 인증서 신뢰를 확보함
- 구성 요소
- CA(Certification Authority): 인증서 발급·서명·폐지 권한 보유
- RA(REgistration Authority): 사용자 신원 확인, CA 대신 등록 및 검증 수행
- Repository: 인증서, CRL 저장소 (LDAP, HTTP 등)
- OCSP Responder: 인증서 실시간 유효성 확인 서버
X.509 인증서
공개키·주체 정보·CA 서명 등을 포함한 국제 표준(ITU-T X.509) 디지털 인증서 포멧
handshake 과정에서 서버의 신원 검증과 공개키 전달 수단 (클라이언트 인증시에도 동일 구조 사용 가능)
- 주요 필드
- Subject: 인증서 소유자 식별 정보(도메인명, 조직명 등)
- Issuer: 인증서 발급자(CA) 식별 정보
- Subject Public Key Info: 공개키와 알고리즘 정보
- Validity: 유효 기간 (시작일~만료일)
- Extensions: 확장 필드 (Key Usage, Extenfef Key Usage, SAN 등)
- Signature Algorithm & Value: CA가 서명한 해시 값
신뢰 체인 (Trust Chain)
Root CA에서 시작하여 Intermediate CA를 거쳐 최종 Entity 인증서(End-Entity Certificate)에 이르는 서명 경로로 각 딘계가 상위 단계의 서명을 통해 신뢰를 전이함
체인 중 어느 한 단계라도 위변조 및 폐지 시 전체 신뢰가 무효화 됨
- 구성
- Root CA: 자기서명(Self-Sgined) 인증서, OS/브라우저 신뢰 저장소에 사전 설치
- Intermediate CA: Root CA로부터 서명받아 발급 업무을 위임받은 하위 CA
- End-Entity Certificate: 최종 Server/Client가 사용하는 인증서
🔸해시 함수와 HMAC
해시 함수란 임의 길이의 입력 데이터를 고정 길이의 해시 값으로 변환하는 단방향 함수로 동일 입력은 항상 동일하게 출력되며 미세한 입력 변화에도 완전히 다른 해시 값이 생성됨
- 보안 해시 함수 조건
역상 저항성: 해시 값으로부터 원래 입력을 찾는 것이 계산적으로 불가능해야함2차 역상 저항성: 주어진 입력과 동일 해시 값을 가지는 다른 입력을 찾는 것이 불가능 해야함충돌 저항성: 서로 다른 두 입력이 동일 해시 값을 생성하는 경우를 찾는 것이 불가능 해야 함
- 주요 알고리즘
- SHA-2: SHA-224, SHA-256, SHA-384, SHA-512로 구성, NIST 표준, 현재 널리 사용
- SHA-3: Keccak 기반, sponge 구조 사용, SHA-2 대비 설계 원리 상 다른 구조로 안전성 강화
- 취약 알고리즘
- MD5: 128비트 출력, 충돌 공격이 실용적으로 가능(2004년 이후 보안 용도 사용 중단)
- SHA-1: 160비트 출력, 2017년 구글 SHAttered 프로젝트에서 실용적 충돌 입증, TLS 인증서 서명에서 사용 금지
HMAC 구조와 해시 함수 차이
HMAC(Hash-based Message Authentication Code)는 해시 함수를 기반으로 한 메시지 인증 코드(MAC)
- 차이점
- 해시함수: 무결성 검증만 가능, 발신자 인증 불가능
- HMAC: 비밀 키를 추가로 하용하여 무결성과 인증 동시 제공
- 구조
- 비밀 키를 내부 패딩(ipad)과 외부 패딩(opad)으로 조합
H( K_opad || H( K_ipad || message ) )방식으로 계산
- SSL/TLS에서의 활용
- Record Layer에서 MAC 생성 및 검증
- Handshake 메시지 무결성 확인
✨HandShake와 세션 관리
🔸상태 유지(Stateful) 프로토콜
완전 협상을 통해 세션을 생성하고, 이 세션 정보를 공유ㅠ하는 다수의 연결을 단축협사을 통해 생성함
완전 협상(Full Handshake)
1~6 : 서버 응답 전 단계
- Client Hello
- 클라이언트가 지원하는 SSL/TLS 버전, 암호 알고리즘 목록, 무작위 난수 값, 압축 방식 등을 서버에 전송
- 세션 재사용이 아닌 새 세션 요청임을 명시
- Server Hello
- 서버가 사용할 SSL/TLS 버전, 선택한 암호 알고리즘, 서버 무작위 난수 값을 클라이언트에 전달
- Server Certificate*
- 서버의 공개키가 포함된 인증서 전송
- PKI를 통해 클라이언트가 서버 신원 검증 수행
- 옵션: 익명 키 교환(Anonymous Cipher Suite) 시 미전송 가능
- Server Key Exchange*
- Diffie-Hellman(Ephemeral 포함) 또는 ECDHE 기반 키 교환 시 필요한 파라미터 전송
- RSA Key Exchange 방식에서는 불필요
- Certificate Request
- 서버가 클라이언트 인증을 요구할 경우 전송
- 클아이언트는 이후 자신의 인증서를 서버로 전송
- Server Hello Done
- 서버 측 초기 메시지 전송 종료를 알림
7~11 : 클라이언트 응답 단계
- Client Certificate*
- 서버가 Certificate Request를 보낸 경우 클라이언트 인증서 전송
- Mutual TLS 인증 시 필수
- Client Key Exchange
- 세션 키를 생성하기 위한 키 교환 데이터 전송
- RSA 방식: 세션 키를 서버 공개키로 암호화하여 전달
- (EC)DHE 방식: 클라이언트 측 공개 파라미터 전송
- Certificate Verify*
- 클라이언트 인증서 사용 시, 클아이언트가 자신의 개인키로 서명한 데이터를 전송
- 서버는 공개키로 서명을 검증하여 클라이언트 신원 확인
- [Change Cipher Spec]
- 이후 전송되는 데이터는 협상된 대칭키·암호 알고리즘으로 암호화됨을 알림
- Finished
- 암호화된 상태에서 지금까지 handshake 메시지에 대한 해시를 송신
- 서버가 동일한 해시를 계산하여 일치 여부로 무결성 및 키 교환 성공 검증
12~13 : 서버 최종 확인 단계
- [Change Cipher Spec]
- 서버 측도 암호화 모드로 전환
- Finished
- 서버가 암호화된 Finished 메시지를 전송하여 키 교환·인증 무결성 확인 완료
단축 협상(Abbreviated Handshake)
단축 협상은 기존에 성립했던 SSL/TLS 세션을 재사용(session resumption)하여 전체 handshake 절차를 생략하고 암호화 채널을 빠르게 재수립하기 위해 사용됨
기존 세션 키 또는 세션 티켓을 이용하여 키 교관 과정을 건너뛰므로 지연과 연산 부담이 감소함
- TLS 1.2.까지는 세션ID 또는 세션 티켓 방식
- TLS 1.3에서는 0-RTT 및 1-RTT 재연결 방식 제공
- Client Hello
- 클라이언트가 이전 세션의 세션ID 또는 세션 티켓을 포함하여 전송
- 재사용 가능한 세션인지 확인 요청
- Server Hello
- 서버가 세션ID 또는 티켓을 확인 후, 재사용 가능 시 동일 세션 키 기반으로 handshake 진행
- SSL/TLS 버전, 암호 알고리즘 재확인
- [Change Cipher Spec]
- 서버가 기존 세션 키 기반 암호화 모드로 전환
- Finished
- 서버 측 handshake 메시지 무결성 검증 완료 후 전송
- [Change Cipher Spec]
- 클라이언트도 암호화 모드 전환
- Finished
- 클라이언트 측 handshake 무결성 검증 완효 후 전송
TLS 1.2와 1.3의 Handshake
| 단계 | 메시지 | 설명 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|
| 1 | ClientHello | 지원 암호 스위트, TLS 버전, 랜덤 값(Client Random) 전송 | O | O |
| 2 | ServerHello | 선택된 암호 스위트, TLS 버전, 랜덤 값(Server Random) 전송 | O | O |
| 3 | Certificate | 서버 인증서 전송 (필요 시 클라이언트 인증서 요청 가능) | O | O |
| 4 | Certificate Verify | 인증서 소유 증명(서명 검증) | O | O |
| 5 | Key Exchange | 세션 키 생성 위한 키 교환(RSA, (EC)DHE) | O | (EC)DHE만 허용 |
| 6 | Finished | 양측이 생성한 세션 키로 Finished 메시지 암호화·전송, Handshake 완료 | O | O |
| * | Change CipherSpec | 협상된 암호 스펙 적용 시작(Handshake 이후 데이터 암호화) | O | 삭제됨 |
| * | NewSession Ticket | 세션 재개용 티켓 발급 | O | O |
| * | Encrypted Extensions | 추가 확장 정보 전송 | X | O |
🔸세션 상태 정보
세션 상태(Session State)
양측 종단간의 완전 협상을 통해 생성되는 상태정보
세션이 유지되는 동안에 지속적으로 다수의 연결에 의해 사용되는 보안 파라미터 정보가 관리됨
| 필 드 | 설 명 |
|---|---|
| session ID | 둘 사이의 세션 식별자, 32byte로 구성됨 |
| peer certificate | 상대방의 인증서 (X.509v3) |
| cipher spec (암호 명세) | 암호 명세로 다음과 같은 정보를 담고 있음 - 대칭 암호 알고리즘, 키 길이, 블록 암호 모드 등 - HMAC용 해시 알고리즘 |
| compression method | 압축 방식, 현재는 null만 정의 |
| master secret | - 키 블록을 생성하기 위해 서버와 클라이언트가 공유하는 48byte 비밀값 - 완전 협상을 통해 생성한 premaster secret, server random, client random을 조합하여 master secret을 생성함 - server random, client random은 master secret를 생성하기 위한 slat 역할을 수행 |
| is resumable | 현재 세션이 재사용 될 수 있는지 여부 플래크, 재사용 된다는 의미는 여러 연결에 의해 다시 사용될 수 있는가 하는 의미 |
연결 상태(Connection State)
실제 통신이 이뤄지는 단위로 단축 협상을 통해 생성되며 세션 상태를 공유하면서 통신을 수행함
| 필 드 | 설 명 |
|---|---|
| server/client random | - 단축 협상을 통해 서버/클라이언트가 생성한 32byte 난수 값 - 세션에 저장된 master secret와 단축 협상을 통해 생성된 client random, server random을 조합/해시하여 키블록을 생성한 후 이를 이용하여 다양키를 만들어냄 - server random, client random은 키 블록을 생성하기 위한 salt 값 역할을 수행함 |
| server/client write key | 서버/클라이언트가 암호화에 사용되는 비밀키 |
| server/client write Mac secret | 서버/클라이언트가 메시지 인증 코드(MAC) 생성 시 사용하는 인증키 |
| server/client write IV | 서버/클라이언트가 블록 암호 모드에 사용하는 IV(Initialize Vector) |
| sequence number | 전송 메시지 순번 |
키 생성 과정
- 완전 협상을 통해 주고 받은 사전 마스터 비밀(Pre-master Secret), Client Random, Server Random을 조합하여 해시한 결과로 마스터 비밀을 생성(Master Secret)함
- 생성한 Master Secret는 다수 연결이 사용할 수 있도록 세션 상태에 저장
- 단축 협상을 통해 주고 받은 Clinet Random, Server Random과 세션에 저장된 Master Secret을 조합하여 해시한 결과로 키 블록(Key Block)을 생성 함
- Key Block으로부터 서버/클라이언트 각각의 암호용 비밀키, MAC용 인증키, 블록 암호 모드용 IV 를 계산해냄
🔸완전 순방향 비밀성(PFS)
Perfect Forward Secrecy
세션 키가 유출되더라도 과거의 세션 데이터를 복호화할 수 없도록 하는 보안 속성
기본 원리
- (EC)DHE(Ephemeral Diffie-Hellman)방식은 각 세션마다 임시(Ephemeral) 키 쌍을 새로 생성
- 키 교환 후 임시 키는 폐기되므로, 장기 비밀키(서버 개인키)나 세션 키가 유출되어도 과거 통신 복호화 불가
적용 사례
- TLS 1.0/1.1/1.2 : (EC)DHE 암호 스위트 선택 시에만 PFS 보장
- TLS 1.3 : 모든 키 교환이 (EC)DHE 기반으로 동작 → PFS 필수화
- RSA 키 교환 방식은 고정 키를 사용하므로 PFS 미지원, TLS 1.3에서 제거됨
보안 이점
- 장기 비밀키 유출 사고 발생 시 피해 범위 최소화
- 대규모 패킷 저장 후 나중에 복호화하는 공격을 방어할수 있음
다음 글에서는 운영·버전·보안 위협을 중점적으로 설명함
