9. TLS_Protocol

Transport level

SSL(Secure Socket Layer) Protocol
TLS(Transport Layer Security) Protocol

SSL v2.0, v3.0
SSL v3.1 == TLS v1.0
현재 TLS v1.2를 전세계적으로 사용중이고 TLS v1.3을 사용하는 곳도 있다.

SSL/TLS Protocol

인터넷에서 데이터를 안전하게 주고받기 위한 보안 프로토콜이다.
TLS는 TCP(전송 계층) 위에서 동작하며, TCP의 신뢰성 있는 연결을 바탕으로, 암호화된 안전한 통신(End-to-End Security)을 제공.

TLS는 다음 세 가지 핵심 보안 기능을 제공한다.

보안 기능	설명
Authentication (인증)	서버(또는 클라이언트)의 신원을 디지털 인증서로 검증함
Confidentiality (기밀성)	데이터는 암호화되어 전달됨. 도청자가 내용을 볼 수 없음
Integrity (무결성)	데이터가 전송 중 변조되지 않았는지 확인함 (예: MAC 사용)

TLS는 서버의 공개키를 검증하기 위해 디지털 인증서(X.509 인증서를 사용.

HTTP 같은 애플리케이션이 TLS를 이용함.

• HTTP 같은 애플리케이션은 TLS 위에 데이터를 얹어서 보냄
• 즉, HTTPS = HTTP + TLS
  • 사용자가 https:// 로 접속하면, 실제로는 HTTP 메시지가 TLS로 암호화되어 전송됨.

요약

항목	내용
목적	안전한 통신을 제공하기 위한 보안 프로토콜
동작 위치	TCP 위에서 작동
기능	인증, 암호화, 무결성 검증
인증 방식	디지털 인증서 사용
활용 예시	HTTPS, SMTP, IMAP 등 다양한 인터넷 서비스에서 사용됨

Layer: Record Protocol, Handshaking Protocol

Record Layer Protocol

TLS라는 프로토콜에서 정의한 메시지들뿐만 아니라 TLS에서 담고 가야하는 애플리케이션 레이어 메시지들을 담을 수 있는 포맷을 만들어 놓은 게 Record Protocol 이다.
Record Protocol의 TLS 버전은 항상 TLS 1.0

추후, Handshake protocol을 그냥 보내는 것이 아닌 Record Protocol이라는 형식에 맞춰 전달
즉, TCP 입장에서는 위에서 어떤 값이 내려오든 상관없이 항상 Record Protocol이라고 생각하고 받음

TLS에서 모든 프로토콜은 Record Protocol을 통해서 전달이 됨.
Record Protocol의 Body에 올 수 있는 값들은 위에 있는 5가지 이다.

Connection vs Session

Connection:
일시적인, peer-to-peer, communications link
반드시 1개의 SSL session과 연관 있어야 함.

Session:
안전한 소통을 위해 서로의 협약의 집합 (cryptographic parameters)
여러개의 SSL connection과 연결 지을 수 있다.
-> 세션정보는 상대방과 내가 협의한 정보를 포함

커넥션은 세션정보로 파생되는 여러가지 비밀값들을 사용해서 실제 통로를 암호화 할 때 사용되는 정보로 구성하기에 세션 정보만 계속 유지 관리하고 있으면 커넥션은 여러개 만들 수 있다.

세션 (Session)	커넥션 (Connection)
통신을 위한 암호화 규칙의 설계도	그 설계도로 만들어진 실제 암호화 통신 회선
오래 유지 가능	일시적 (필요하면 끊고 새로 만듦)
여러 커넥션을 위한 기반	실제 메시지를 주고받는 실행 통로
예: "앞으로 우리 대화는 이 암호표로 하자"	예: "지금 그 암호표로 얘기해보자!"

Session

Session Identifier:

서버가 세션을 고유하게 식별하기 위해 생성한 임의의 바이트 시퀀스.

Peer Certificate (상대방 인증서):

상대방의 X.509 v3 인증서이다.
서버 인증서가 일반적이며, 클라이언트 인증서도 일부 상황에서 사용

Compression Method (압축 방식):

데이터를 암호화 전에 압축하는 방법.
최근에는 사용 x

Cipher Spec (암호 스펙):

암호화 알고리즘 묶음

Master Secret:

대칭키를 만들 때 사용
클라이언트와 서버가 TLS 핸드세이크 과정에서 함께 생성하는 48바이트의 비밀 값이다.
암호화, MAC, 세션 키 등은 이 마스터 시크릿을 기반으로 생성.

Is Resumable (세션 재개 가능 여부):

이 세션이 재사용 가능한지 여부를 나타내는 플래그
캐싱.

전체 정리

구성 요소	설명
Session Identifier	세션 식별용 랜덤 바이트 시퀀스
Peer Certificate	상대방 인증서 (보통 서버 인증서)
Compression Method	압축 방식 (거의 사용 안 함)
Cipher Spec	암호 알고리즘 조합 (예: AES + SHA)
Master Secret	세션의 핵심 키 재료 (48바이트 비밀)
Is Resumable	세션 재사용 가능 여부 (true/false)

Connection State

TLS에서의 Connection State (연결 상태) 는 실제 데이터 송수신에 사용하는 암호화 및 인증 정보를 담고 있는 구조이다.
만약 동일한 키를 방향과 상관없이 사용할 때, 만약 키가 유출된다고 하였을 때 주고 받았던 모든 데이터가 유출 될 수 있다.
하지만, 방향 별로 키를 관리하였을 때, 보안상으로 더 좋음.

Server and Client Random:

TLS 핸드셰이크 초기에 클라이언트와 서버가 각각 생성한 32바이트 랜덤 값이다.
이 랜덤 값들은 마스터 시크릿 생성과 이후 세션 키 생성에 사용됨.
구성:
클라이언트 랜덤 = ClientHello 메시지에서 전송
서버 랜덤 = ServerHello 메시지에서 전송
목적:
키 생성 시 신선도 확보 (replay 공격 방지)

Server Write MAC Key

서버가 데이터를 보낼 때 사용하는 MAC 키.
메시지 위변조를 막기 위한 인증 코드(HMAC)를 생성할 때 사용
클라이언트는 이 키로 서버 메시지의 HMAC을 검증

Client Write MAC Key

클라이언트가 데이터를 보낼 때 사용하는 MAC 키.
서버는 이 키로 클라이언트 메시지의 무결성을 검증

Server Write Key

서버가 데이터를 암호화할 때 사용하는 대칭키.
클라이언트는 이 키로 데이터를 복호화 함.

Client Write Key

클라이언트가 데이터를 암호화할 때 사용하는 대칭키.
서버는 이 키로 데이터를 복호화 함.

Initialization vectors

같은 평문이 반복되더라도 암호문이 다르게 나오게 하여 패턴 분석을 어렵게 함.

Sequence Numbers

TLS는 보낸 메시지와 받은 메시지 각각에 대해 별도의 시퀀스 번호를 유지한다.
이 시퀀스 번호는 MAC 계산에 사용되어 메시지 순서와 무결성을 보장.

TLS Record Protocol

목적:
데이터를 암호화해서 전달.
TLS v1.0 == SSL v3.1

Confidentiality (기밀성)

TLS는 클라이언트와 서버가 Handshake Protocol을 통해 공유하는 비밀 키를 생성
이 키를 사용해 이후 송수신 되는 애플리케이션 데이터(TLS payload)를 대칭 키 암호화(AES, DES).
암호화 덕분에 전송 중 데이터가 중간에서 노출되지 않도록 보호.

Message Integrity (무결성)

클라이언트와 서버는 Handshake 중에 또 다른 공유된 비밀 값을 사용해 MAC(Message Authentication Code) 키를 생성
TLS는 데이터를 전송하기 전, 이 MAC 키로 메시지 무결성 코드(해시 값)를 계산하여 함께 보냄.

Record Layer에서의 기밀성과 무결성을 제공하기 위해서 반드시 Handshake protocol을 활용해 상대방과 내가 세션을 맺어야 한다.

항목	설명
Confidentiality (기밀성)	Handshake로 생성한 대칭키로 TLS payload를 암호화
Message Integrity (무결성)	MAC을 사용해 데이터 변조 여부 검증

TLS 명칭	Major	Minor	Hex 값	의미
TLS 1.0	3	1	0x0301	SSL 3.1 → TLS 1.0
TLS 1.1	3	2	0x0302	SSL 3.2 → TLS 1.1
TLS 1.2	3	3	0x0303	SSL 3.3 → TLS 1.2
TLS 1.3	3	4	0x0304	SSL 3.4 → TLS 1.3

TLS Handshake Protocol, Record Protocol, Session 관계

1. TLS Handshake Protocol: 보안 연결을 설정
2. TLS Session: 설정된 보안 파라미터 집합
3. TLS Record Protocol: 실제 데이터를 암호화해서 전달

TLS Handshake Protocol: "보안 연결을 만드는 과정"

• TLS 연결의 시작에서 실행
• 클라이언트와 서버가 서로 통신하며
  • 어떤 암호 알고리즘을 쓸지 정함
  • 서로의 인증서(X.509) 교환
  • 비밀 키 공유. -> 이를 기반으로 session keys 생성
• 결과적으로 "세션"의 모든 보안 파라미터가 여기서 결정

Handshake를 통해 생성되는 정보:

• Master Secret
• 암호 알고리즘, 해시 알고리즘
• 인증 정보 (서버 인증서 등)
• 세션 ID

TLS Session: "공유된 보안 컨텍스트"

Handshake 결과로 만들어지는 논리적인 보안 상태
같은 클라이언트/서버 쌍이 여러 연결(connection)을 맺을 수 있는데, 같은 세션을 공유하면 다시 핸드셰이크 안 해도 됨 (session resumption)

세션에 저장되는 요소들:

• Session ID
• 암호 스펙 (cipher spec)
• Master Secret
• Peer Certificate
• Is Resumable 플래그

TLS Record Protocol: "암호화된 실제 데이터 송수신"

Handshake가 끝난 후부터 사용됨
TLS가 실제 애플리케이션 데이터를 전송할 때 사용하는 레이어
핸드셰이크에서 얻은 세션 정보를 이용해서:

• MAC을 붙이고
• 대칭키로 암호화한 뒤 전송

Record Protocol은 다음 정보를 필요로 함:

• Client/Server Write Keys (세션에서 만들어진 대칭키)
• Client/Server Write MAC Keys
• Initialization Vectors (IV)
• Sequence Numbers

플로우

클라이언트가 서버에 접속 → TLS Handshake 시작
서버 인증서 검증, 키 교환 완료 → Master Secret 생성 → 세션 형성
세션 키와 알고리즘 기반으로 TLS Record Protocol 시작
이후 데이터는 Record Layer에서 암호화/복호화되며 안전하게 송수신됨

관계 정리

구성요소	역할 요약	관계 요약
Handshake Protocol	세션 생성 / 보안 파라미터 설정	세션을 "만든다"
Session	보안 파라미터 모음 / 핸드셰이크 결과	레코드가 "사용"
Record Protocol	실제 암호화된 데이터 송수신	세션 정보 기반으로 작동

TLS Record Layer Payload

GenericBlockCipher: confidentiality only
GenericAEADCipher: 자체적으로 메시지 integrity 보장 (Like GCM)

TLS Handshake Protocol

Type은

client_hello

필드명	설명
client_version	클라이언트가 사용하고자 하는 TLS 프로토콜 버전 (예: TLS 1.2)
random	클라이언트가 생성한 랜덤 값 (서버와 함께 마스터 시크릿 생성에 사용됨)
session_id	클라이언트가 재사용하고자 하는 세션의 ID. 새로운 세션을 원하면 비움
cipher_suites	클라이언트가 지원하는 암호 스위트 목록 (선호 순으로 나열)
compression_methods	클라이언트가 지원하는 압축 방식 목록
extensions	추가 기능이나 확장을 요청하는 필드 (예: SNI, ALPN, ECC 지원 등)

cipher_suites

키 교환엔 ECDH(Elliptic Curve Diffie-Hellman Ephemeral(임시로),
시그니처 생성엔 ECDSA,
대칭키 암호엔 AES128,
운영모드엔 GCM,
HASH 알고리즘엔 SHA256

server_hello

client_hello를 받은 서버가 client_hello 안에 있는 메시지 중에 자신이 사용할 것을 선택해서 다시 클라이언트한테 응답하는 메시지

필드명	설명
server_version	서버는 클라이언트와 자신이 모두 지원할 수 있는 TLS 버전 중, 가장 높은 버전 하나를 선택해서 server_version 필드에 넣는다.
random	서버가 생성한 랜덤 값. 클라이언트 랜덤값과 독립적으로 생성되며, 마스터 시크릿 생성에 사용됨
session_id	해당 연결에 사용할 세션 ID. 클라이언트가 보낸 session_id가 비어 있지 않으면 캐시된 세션을 찾음
cipher_suite	서버가 클라이언트의 제안 목록에서 선택한 단 하나의 암호 스위트
compression_method	서버가 클라이언트의 제안 목록에서 선택한 단 하나의 압축 방식
extensions	서버가 수락한 확장 목록. 클라이언트가 제안한 확장만 포함될 수 있음

certificate

TLS에서는 클라이언트 검증을 하지 않고, 서버 검증만 진행한다. (server가 client한테 나 진짜 니가 연결하려는 서버가 맞아 하고 보증으로 보내는 것)
certificate 1개를 보내는 것이 아닌 certificate chain을 보냄.
인증서들은 서명 체인을 형성함 (ex: 서버 인증서 → 중간 CA → 루트 CA).

상대방 웹사이트 자체를 검증하는 것이 아닌, 상대방 웹사이트가 전달한 인증서 체인이 정상적으로 루트 CA까지 연결이 되어있고, 그 루트 CA 인증서가 Trust Anchor에 들어있으면 비로소 상대방 웹사이트를 신뢰.

항목	설명
certificate_list	인증서 체인 (chain)으로 구성된 리스트
첫 번째 인증서	전송자의 인증서 (예: 서버 또는 클라이언트의 인증서)
그 다음 인증서들	직전 인증서를 직접 인증(sign)하는 인증 기관(CA)의 인증서들
루트 인증서 (self-signed)	생략 가능. 일반적으로 수신자가 이미 가지고 있다고 가정됨

server_key_exchange

master secret을 만들기 위한 pre-master secret를 만듦.

dhe: Diffie-Hellman Ephemeral (키교환)
dss: Digital-signature standard (전자서명 알고리즘)
dhe_rsa: rsa로 전자서명을 만든다.
rsa: 키교환으로 rsa사용

Server_hello_done

Server는 Client_hello를 받으면 Server_hello와 certificate, server_key_exchange를 보낸다.
Server_hello_done를 통해 서버가 클라이언트한테 보내는 메시지의 끝을 알려줌
이후에 Client는 certificate를 검증하는 과정을 걸침

Client_key_exchange

Server가 Dh한다고 하면(dh_anon) Client 역시 ClientDiffieHellmanPublic으로 전달해야됨.

Server(client)_key_exchange

최종적으로 만드려고 하는것은 대칭 키 이다.
대칭키는 master secret으로부터 유도됨.
master secret을 만들기 위해서는 pre master secret이 필요함.

키 교환 메시지를 주고 받음으로써 최종적으로 만들려 하는 것은 pre master secret이고, 그 pre master secret을 생성하는 방법이 2가지 있다.

1. RSA 알고리즘:
   클라이언트가 그냥 pre-master secret 하나를 만들어서 서버에 RSA 공개키로 암호화해서 전달.
   클라이언트가 서버로 부터 받은 certificate에 만약 인증서가 RSA 공개키를 가지고 있다고 하면 클라이언트가 인증서 검사 chain을 완료한 시점에서 상대방 서버의 RSA 공개키를 가지고 있게 된다.
   서버의 인증서에 들어있는 RSA 공개키로 내가 만든 PRe-master secret을 암호화해서 서버로 전달.
   서버는 인증서에 넣어둔 RSA 공개키에 대응하는 비밀키를 가지고 있고 비밀키로 암호화된 pre-master secret을 복호화하여 client가 만든 pre-master secret을 복원할 수 있게 된다.
   client가 pre-master secret을 만들어서 상대방 공개키로 암호화해서 보내는 방식

2. Ephemeral DH key exchange:
   만약 서버가 받은 certificate에 RSA 공개키가 없고 Server에서 DH key exchange 기반으로 키 교환을 하자. DH key exchange 방식으로 pre-master secret을 만들자고 server가 먼저 시도하고 client는 그거에 대한 응답을 함.
   서버는 보낼 때 public key. DH public parameter에 서명된 공개된 파라미터를 전달. 이 서명은 어떻게 검증하냐? RSA 기반이 아니고, ECC, DH를 활용할 때는 공개키에 DH 키 교환에서 말하는 키가 존재한다. ECC에서의 비밀키 a라 하면 공개키는 aG. 여기에 들어있는 공개키로 서명을 검증 가능. 인증서에 있는 걸로.

   서버와 클라이언트 각각 공개키를 만들고 서로 주고 받은 다음에 각자가 가지고 있는 비밀키 값으로 지수승을 해서 공통된 pre-master key를 만들자.

TLS Cryptographic Computations

• master secret 공유된 48바이트의 비밀값으로, 해당세션에서만 사용.

• 키 교환 알고리즘 (RSA, ECDHE 등)을 통해 클라이언트와 서버가 공동으로 생성.

• 이 master secret를 바탕으로 다양한 암호화 및 MAC 키를 만든다.

생성되는 키	역할
Client Write MAC Key	클라이언트가 보내는 메시지의 무결성 검증용 (HMAC)
Server Write MAC Key	서버가 보내는 메시지의 무결성 검증용
Client Write Key	클라이언트가 데이터를 암호화할 때 사용
Server Write Key	서버가 데이터를 암호화할 때 사용
Client Write IV	클라이언트 측 초기화 벡터 (대칭 암호 알고리즘용)
Server Write IV	서버 측 초기화 벡터

이 모든 값은 key_block = PRF(master_secret, "key expansion", ServerHello.random + ClientHello.random)로부터 순서대로 잘라냅니다.

PRF: Pseudo Random Function으로 입력이 주어지면 고정된 길이의 임의의 값을 만들어 냄.
고정된 길이를 임의의 길이로 확장도 가능하다.

Master secret 만드는 법

PM: pre-master secret
CR: Client_Random
SR: Server_Random

hash값의 일부를 나눠 key값으로 사용한다.

TLS Handshake Protocol

현대의 TLS에서는 클라이언트가 서버로 인증서 보낼 수 있지만 보내지 않는다.

change_cipher_spec: 해당 과정 전에 이미 pre-master secret을 바탕으로 master secret과 여러개의 key를 이미 만들어 놓은 상태이다.
change_cipher_spec이 의미하는 것은 앞으로의 통신은 데이터를 암호화해서 보내자 라는 신호이다. (1byte)

finished: TLS handshake가 종료됐다. 해당 finished를 암호화해서 전달 가능.

클라이언트가 서버로 finished 메시지를 보낼 때 client_write_key를 사용해 암호를 진행하고 서버 또한 client_write_key가 존재하는데 finished 메시지를 서버가 만든 키로 복호화가 잘 되는지 확인하고 잘 되는 경우 클라이언트와 서버와 키 교환이 정상적으로 잘 했구나를 확인 가능.

Practice

RSA기반 키 교환 단점?

RSA 공개키에 대응하는 인증서의 유효기간이 다 할 때 까지는 항상 서버의 RSA 공개키로 pre-master secret을 암호화해서 보낸다.
즉, 서버의 RSA 비밀키가 유출이 되면, 해당 서버와 통신했던 모든 클라이언트의 pre-master secret값이 공개가 될 것이고,
만약 pre-master secret값이 노출 되게 된다면 key값을 만들 때 필요한 나머지 값들 (server random, client random, label)은 모두 공개 되어있기에 pre-master secret이 노출된다면 모든 키 값이 노출 되는것이랑 마찬가지이다.
이전 세션의 키들도 알아 낼 수 있고, 해당 키들을 사용해 이전 데이터들도 모두 복호화해서 볼 수 있다.

세션이 독립적이지 않고 하나의 세션이 공격당하게 되면 모든 세션이 영향을 받음. 그러기에 TLSv1.3에서는 RSA 기반 키 교환을 없앰.

즉, RSA 기반 키 교환 알고리즘은 Forward Secrecy를 보장하지 않는다.

Forward Secrecy:
장기적으로 사용하는 비밀키가 나중에 유출되더라도, 이전에 주고받은 메시지들은 해독되지 않도록 보장하는 보안 속성입니다.