개념: SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인터넷 상에서 데이터가 도청되거나 위변조되지 않도록 종단 간(End-to-End) 안전한 통신을 보장하는 암호화 프로토콜입니다. HTTPS, FTPS, SMTPS 등 응용 계층의 보안을 책임집니다.
차이점:
SSL: 넷스케이프(Netscape)사에서 개발한 초기 버전입니다. (SSL 1.0 ~ 3.0) 보안 취약점으로 인해 현재는 사용이 전면 금지(Deprecated)되었습니다.
TLS: IETF(국제 인터넷 표준화 기구)에서 SSL 3.0을 기반으로 표준화한 버전입니다. 즉, TLS 1.0은 사실상 SSL 3.1과 같습니다. 오늘날 우리가 "SSL"이라고 부르는 것은 관용적인 표현일 뿐, 실제로는 "TLS (1.2 또는 1.3)"를 의미합니다.
(2) SSL/TLS가 제공하는 3대 보안 서비스
- 요약 키워드: 기밀성(암호화), 무결성(MAC), 인증(인증서)
- 이론 상세 내용:
기밀성 (Confidentiality): 송수신되는 모든 데이터를 대칭키 암호화(AES 등)를 통해 암호화하여 제3자가 패킷을 스니핑하더라도 내용을 알 수 없게 도청을 방지합니다.
무결성 (Integrity): 메시지가 전송 도중 위조되거나 변조되지 않았음을 보장하기 위해 MAC(Message Authentication Code) 알고리즘(SHA 등)을 추가하여 무결성을 검증합니다.
인증 (Authentication): 신뢰할 수 있는 제3의 인증기관(CA)에서 발급한 X.509 기반의 디지털 인증서(공개키 포함)를 사용하여 통신 상대방(주로 서버, 필요시 클라이언트 포함)의 신원을 확실하게 보증합니다.
(3) 동작 계층 및 하위/상위 세부 프로토콜
- 요약 키워드: 전송 계층 위 / 응용 계층 아래, Record(하위), Handshake/CCS/Alert(상위)
- 이론 상세 내용:
SSL/TLS는 전송 계층(TCP)과 응용 계층(HTTP, FTP 등) 사이에서 독립적인 계층으로 동작합니다. 아키텍처는 크게 데이터를 캡슐화하는 하위 프로토콜과 연결을 관리하는 3개의 상위 프로토콜로 나뉩니다.
계층 (Layer)
세부 프로토콜
역할 및 기능
상위 계층 (연결 관리)
Handshake
Handshake Protocol
서버와 클라이언트가 서로 인증하고, 통신에 사용할 암호 알고리즘 세트(Cipher Suite)를 결정하며, 암호화에 사용할 비밀 키(세션 키)를 안전하게 교환합니다.
CCS
Change Cipher Spec Protocol
핸드셰이크 과정에서 협상된 암호화 정책과 키를 "지금부터 적용하겠다"고 상대방에게 알리는 1바이트짜리 신호 프로토콜입니다.
Alert
Alert Protocol
통신 중 발생하는 경고 및 오류 메시지(Fatal, Warning)를 상대방에게 전달합니다. (예: 인증서 만료, 복호화 실패 등)
하위 계층 (데이터 처리)
Record
Record Protocol
상위 프로토콜이나 응용 계층의 데이터를 넘겨받아 단편화, 압축, MAC(무결성) 추가, 암호화하여 최종적으로 전송 계층(TCP)으로 내려보냅니다.
(시험이나 실무에서 모두 "데이터를 실제 암호화하기 위해 양측이 공유하는 하나의 키"를 뜻하는 동의어로 혼용되어 사용되니 반드시 기억하세요.)
[키 생성의 상세 메커니즘 (RSA 키 교환 기준)]
난수 교환: Client Hello와 Server Hello 단계에서 각각 클라이언트 난수(Client Random)와 서버 난수(Server Random)를 생성하여 평문으로 교환합니다.
Pre-Master Secret 전달: 클라이언트가 48바이트 길이의 임의의 난수인 Pre-Master Secret(예비 마스터 키)을 생성한 뒤, 서버의 인증서에서 추출한 공개키로 암호화하여 서버로 보냅니다. (서버는 자신의 개인키로 이를 복호화합니다.) Master Secret / Key Block은 네트워크를 통해 공유하는 것이 아닌, PRF로 양쪽이 각자 생성하는 것입니다.
Master Secret 도출: 양측은 교환한 3가지 재료인 [클라이언트 난수 + 서버 난수 + Pre-Master Secret]을 PRF(Pseudo-Random Function, 의사 난수 함수)에 통과시켜 48바이트의 Master Secret(마스터 시크릿)을 동일하게 도출해냅니다.
최종 Key Block 생성: 도출된 Master Secret과 양측의 난수를 다시 PRF에 돌려 최종적으로 통신에 사용할 Key Block을 만듭니다. 이 Key Block은 잘게 쪼개져 클라이언트/서버용 쓰기 대칭키(세션키), MAC 무결성 키, IV(초기화 벡터)로 각각 나뉘어 Record 프로토콜에서 사용됩니다.
(3) 완전 협상(Full)과 단축 협상(Abbreviated)의 차이
- 요약 키워드: Session ID, Session Ticket, 비대칭키 연산 생략, 서버 부하 감소
- 이론 상세 내용:
완전 협상 (Full Handshake): 최초 연결 시 발생하며, 상호 인증과 무거운 비대칭키 연산(RSA 등)을 통해 새로운 세션 키를 생성하는 모든 과정을 거칩니다.
단축 협상 (Abbreviated Handshake / Session Resumption): 이전에 맺었던 세션을 재사용하는 방식입니다.
Client Hello에 이전 Session ID나 Session Ticket을 포함하여 보냅니다.
서버가 이를 확인하면, 인증서 교환 및 비대칭키 연산(Key Exchange) 과정을 전면 생략하고 곧바로 Change Cipher Spec 단계로 넘어갑니다. 시간(RTT)과 CPU 부하를 획기적으로 줄이는 기술입니다.
(4) Cipher Suites (암호 알고리즘 세트) 형식 및 해석 예시
- 요약 키워드: 프로토콜, 키 교환, 인증, 대칭키 암호화, MAC(해시) 알고리즘
- 이론 상세 내용:
클라이언트와 서버가 통신 방식을 결정할 때 합의하는 알고리즘의 묶음입니다. 기본적인 포맷은 다음과 같습니다. `프로토콜_키교환알고리즘_인증알고리즘_WITH_대칭키(데이터암호화)알고리즘_MAC(해시)알고리즘`
예시 1: TLS_RSA_WITH_AES_256_CBC_SHA256
TLS: 통신 프로토콜
RSA: 키 교환 및 인증 알고리즘 (RSA 하나로 둘 다 수행)
AES_256_CBC: 실제 데이터를 암호화하는 대칭키 알고리즘 (AES 256비트, CBC 모드)
SHA256: 데이터 무결성을 확인하는 MAC(해시) 알고리즘
예시 2: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE: 타원 곡선 디피-헬만 방식의 키 교환 (순방향 비밀성 제공)
RSA: 인증서의 전자서명을 검증하는 인증 알고리즘
AES_128_GCM: 대칭키 암호화 알고리즘 (인증과 암호화를 동시 수행하는 AEAD 방식)
SHA256: MAC 알고리즘
예시 3: TLS_AES_256_GCM_SHA384 (TLS 1.3 전용 형식)
TLS 1.3에서는 키 교환 및 인증 방식이 별도로 협상되므로 Cipher Suite 문자열이 훨씬 간결해졌습니다.
AES_256_GCM: 대칭키 암호화 알고리즘
SHA384: MAC 알고리즘
5.3. 레코드 프로토콜 동작 방식 및 TLS 버전별 RTT 비교
(1) Record 프로토콜의 동작 순서
- 요약 키워드: 단편화 → 압축 → MAC 추가 → 암호화 → 헤더 부착
- 이론 상세 내용:
실기 시험에서 순서를 묻는다면 다음의 흐름을 정확히 서술해야 합니다.
단편화 (Fragmentation): 상위 계층에서 내려온 메시지를 처리하기 쉬운 크기(최대 2^14 바이트)로 자릅니다.
압축 (Compression): 단편화된 데이터를 압축합니다. (※ 취약점-CRIME 공격 등으로 인해 현재 TLS 버전에서는 거의 생략/사용 금지됨)
MAC 추가 (Message Authentication Code): 데이터의 무결성을 보장하기 위해 사전에 협상된 MAC 키를 이용해 해시값을 생성하고 덧붙입니다.
암호화 (Encryption): 데이터와 MAC을 사전에 협상된 대칭키(세션 키)로 암호화합니다.
헤더 부착 (Append Header): 암호화된 데이터에 프로토콜 타입, 버전, 길이 정보가 담긴 SSL/TLS 헤더를 붙여 전송 계층으로 넘깁니다.
(2) TLS 1.2 vs TLS 1.3 - RTT(Round Trip Time) 속도 차이
- 요약 키워드: 2-RTT vs 1-RTT, 0-RTT(Early Data), 암호화 시작 시점 차이
- 이론 상세 내용:
TLS 1.3은 보안성 뿐만 아니라 통신 속도(핸드셰이크 지연 시간)를 획기적으로 개선했습니다.
버전 및 협상 방식
RTT (왕복 횟수)
동작 특징 상세 설명
TLS 1.2 (완전 협상)
2-RTT
Client Hello ↔ Server Hello 한 번 왕복(1-RTT), 그 후 Key Exchange ↔ Finished(1-RTT)를 거쳐야 비로소 암호화 통신이 시작됩니다.
TLS 1.2 (단축 협상)
1-RTT
Session ID를 보내고, 서버가 바로 Finished로 응답하여 1-RTT만에 암호화가 시작됩니다.
TLS 1.3 (완전 협상)
1-RTT
클라이언트가 Hello 메시지를 보낼 때 키 교환 데이터(Key Share)를 미리 추측해서 함께 던져버립니다. 서버가 이를 수락하면 단 1-RTT만에 완전 협상이 종료됩니다.
TLS 1.3 (세션 재개)
0-RTT
이전 세션 티켓을 활용하여, 첫 번째 패킷(Client Hello)을 보낼 때 실제 응용 데이터(Early Data)를 같이 암호화해서 보내버립니다. 기다리는 시간이 아예 없는 0-RTT가 실현됩니다.
5.4. [실기 단골] SSL/TLS 핵심 취약점 및 최신 보안 아키텍처
(1) Heartbleed (하트블리드) 취약점
- 요약 키워드: OpenSSL, Heartbeat 확장, 경계값 검사 누락, 메모리 정보 유출
- 이론 상세 내용:
원리: OpenSSL의 연결 유지 기능인 Heartbeat 확장 프로토콜에서, 클라이언트가 보내는 페이로드의 길이(경계값) 검사를 누락한 취약점입니다.
공격: 공격자가 실제로는 1바이트를 보내면서 "내 데이터는 64KB야"라고 조작하면, 서버는 메모리에 있는 다른 64KB(비밀키, 세션 정보 등 포함)를 그대로 긁어서 공격자에게 반환합니다.
(2) 다운그레이드 공격 (Downgrade Attack) 및 POODLE
- 요약 키워드: 약한 암호 알고리즘 강제, FREAK, Logjam, POODLE(SSL 3.0 Fallback)
- 이론 상세 내용:
다운그레이드 공격: 공격자가 핸드셰이크 패킷을 조작하여, 클라이언트와 서버가 지원하는 강력한 알고리즘을 숨기고 과거의 취약한 알고리즘(Export-grade 등)으로 연결하도록 강제하는 기법입니다. (예: FREAK, Logjam 공격)
POODLE 공격: TLS 연결 실패 시 하위 버전으로 재시도하는 Fallback 메커니즘을 악용하여, 취약한 SSL 3.0으로 다운그레이드시킨 후 CBC 모드의 패딩 오라클 취약점을 이용해 세션 쿠키를 탈취하는 공격입니다.
(3) 완전 순방향 비밀성 (PFS, Perfect Forward Secrecy) 지원
- 요약 키워드: 마스터 키 유출 대비, 임시 키 교환(DHE, ECDHE), TLS 1.3 RSA 키 교환 금지
- 이론 상세 내용:
개념: 서버의 마스터 개인키가 미래에 털리더라도, 과거에 암호화되어 전송된 패킷들은 절대 복호화할 수 없도록 통신마다 독립적인 임시 키를 생성하는 성질입니다.
TLS 1.3의 혁신: 기존 TLS 1.2까지는 PFS가 보장되지 않는 RSA 키 교환 방식을 허용했으나, TLS 1.3부터는 RSA 키 교환 방식을 전면 폐지하고 반드시 PFS를 지원하는 (EC)DHE 방식만 사용하도록 강제했습니다.
💡 TLS 1.2 이하에서 PFS(완전 순방향 비밀성)만 지원하기 어려웠던 현실적 이유:
성능 부하(Performance): DHE나 ECDHE 방식은 매 연결마다 새로운 키 파라미터를 생성하고 복잡한 수학적 연산을 거쳐야 하므로, 기존 RSA 방식보다 서버의 CPU 연산 부하가 큽니다. 대규모 트래픽을 감당하는 서버 입장에서는 큰 부담이었습니다.
브라우저 호환성(Compatibility): 구형 브라우저(예: 구버전 IE)나 레거시 시스템, 일부 IoT 기기 등은 최신 ECDHE와 같은 알고리즘을 지원하지 못합니다. 모든 사용자의 접속(서비스 가용성)을 보장해야 하는 서비스 특성상 하위 호환을 위해 RSA 키 교환 방식을 남겨둘 수밖에 없었습니다.
(4) SNI (Server Name Indication)
- 요약 키워드: 단일 IP 멀티 도메인, Client Hello 평문 노출, ESNI / ECH
- 이론 상세 내용:
개념: 하나의 IP 주소(서버)에서 여러 개의 HTTPS 도메인을 호스팅할 때, 클라이언트가 어떤 도메인의 인증서를 요구하는지 Client Hello 확장 필드에 명시하는 기술입니다.
취약점: Client Hello 단계는 평문으로 전송되므로 SNI 정보(접속하려는 도메인 명)가 네트워크 상에 노출되어 검열의 대상이 됩니다. 이를 막기 위해 SNI 필드 자체를 암호화하는 ESNI(Encrypted SNI) 및 ECH 기술이 TLS 1.3에서 도입되고 있습니다.
(5) 서버 개인키 노출 시의 문제점 (보안 취약점)
- 요약 키워드: 세션 키 복호화, 과거 패킷 해독, 중간자 공격(MITM) 위협
- 이론 상세 내용:
만약 서버에 보관되어 있던 '서버 개인키(Private Key)'가 해커에게 노출될 경우 다음과 같은 치명적인 보안 사고가 발생합니다.
과거 트래픽의 전면적인 복호화: PFS(완전 순방향 비밀성)가 적용되지 않은 RSA 키 교환 방식을 사용했다면, 해커는 과거에 스니핑해두었던 Pre-Master Secret을 개인키로 모두 복호화할 수 있습니다. 이를 통해 과거의 세션 키(대칭키)를 재현해 내어 과거 통신 내용 전체를 평문으로 읽어낼 수 있습니다.
위장 및 중간자 공격(MITM): 해커가 서버 개인키를 가지고 있으면, 해당 도메인의 합법적인 서버인 것처럼 완벽하게 위장(Spoofing)할 수 있어 클라이언트와 서버 사이에서 데이터를 가로채고 변조하는 중간자 공격이 가능해집니다.
