0. 개요
SSL을 계승하며 CA와 PKI를 기반으로 동작하는 TLS(transport layer protocol)
1. TLS란?
인터넷에서 암호화와 보안을 제공하는 프로토콜
- TLS는 SSL(Secure Sockets Layer) 프로토콜의 후속버전으로, SSL 3.0을 기반으로 개발
- TLS는 주로 웹 브라우저와 웹 서버 간의 통신에서 사용되며, 클라이언트와 서버 간에 전송되는 데이터를 암호화하여 제3자가 가로채거나 변경하는 것을 방지
- 현재까지 가장 broadly used인 것은 TLS1.2, TLS1.3
- TLS + HTTP = HTTPS
- TLS가 좀 더 broad한 컨셉
e.g. if you want to buy a book at amazom?
ⓐ Amazon과 내가 상호 인증을 수행하여야함 (Authentication)
ⓑ 둘 간의 정보 교환 내용의 기밀성이 유지되어야 하며, 누군가 이를 위변조 하지 않아야함 (confidentiality & integrity)
2. TLS Protocol
1) TLS Handshake
TLS 프로토콜에서 서버와 클라이언트 간의 인증, 암호화 방식, 세션 키 등을 협상하여 보안 연결을 설정하는 과정
- Hybrid Cryptosystem ( Public Key Cryptosystem & Symmetric Key Cryptosystem)
- TLS를 사용하는 서버(웹사이트)에 접속하면 TLS Handshake를 수행.
Handshake는 다음 3가지 단계로 이뤄진다.- Cipher Suite negotiation
- Authentication
- Key Exchange
각 단계를 자세히 살펴보자.
2) 1- Cipher Suite negotiation
클라이언트와 서버는 상호 지원하는 암호화 방식(Cipher Suite)을 협상
-
Cipher Suite란?
collection of cryptographic functions & techniques (protocol에 사용 할 암호화 기술, 메커니즘 등의 집합) -
다음 4가지 요소를 포함
① Key Exchange
② Authentication Algorithms
③ Data Encryption Algorithms
④ Data Integrity Algorithmse.g. TLS1.2 ECDHE-ECDSA-AES123-GCM-SHA256 < 하나의 set
- ECDHE (Key Exchange)
- ECDSA (Auth)
- AES128-GCN (Data Encrypt)
- SHA256 (Data Integrity)
-
여러개의 set로 구성된 suite를 사용해 어떤 암호화 메커니즘을 사용할지 상호 협의하는 단계
3) 2- Authentication
클라이언트와 서버가 서로의 신원을 확인
-
클라이언트는 서버의 인증서를 검증 & 서버의 신원 증명
-
서버는 클라이언트가 신원을 증명할 수 있는 인증 수단을 제공
-
RSA(소인수분해 기반)와 ECDSA(타원곡선암호화를 사용한 DSA) 2가지의 디지털 서명에 기반한 인증을 수행
4) 3- Key Exchange
클라이언트와 서버 간의 비밀키를 생성하고 교환
- RSA와 Diffie-Hellmen 키 교환을 사용
Simplified Protocol
- C=>S : cipher list, RA(nonce of client)
- S=>C : cipher(one of cipher list), RB(nonce of server), certificate
- C=>S : pre-master secret(비밀키)생성하여 서버의 공개키로 암호화
- S=>C : C가 생성한 pre-master secret을 복호화하여 K를 도출하여 C에 확인 메시지를 전달(is this our K?)
① RSA 키 교환 (removed in TLS 1.3)
I. Client는 Server의 인증서를 검증(CA공개키 사용)
II. Client는 pre-mater secret을 가지고 RSA공개키로 암호화하여 Server에 송신
III. Server는 RSA비밀키로 pre-master secret을 복호화
=> Client와 Server는 pre-master secret 을 공유하게 됨
- 그러나, 이 방식은 PFS를 보장하지 않음
만약 해커가 이미 클라이언트와 서버 간의 통신 내용을 기록하고 있었고, 서버의 개인키를 탈취해버렸다면, 이전의 모든 통신 내용을 복호화할 수 있음
② DH 키 교환 (Ephermal DH, PFS 보장)
I. 클라이언트와 서버는 각각 DH 교환에 사용할 공개키와 개인키를 생성
II. 클라이언트와 서버는 상대방에게 각각의 공개키를 전송합니다.
III. 클라이언트와 서버는 각자의 개인키와 상대방의 공개키를 결합하여 동일한 pre-master secret 값을 생성합니다.
V. 이제 클라이언트와 서버는 pre-master secret 값을 공유하며, 이를 기반으로 세션 키를 생성하여 통신에 사용합니다.
- DH Key Exchange 방식은 Ephemeral mode로 구현하여 각 세션마다 새로운 DH 공개키를 생성하여 사용하므로, Forward Secrecy를 제공합니다. TLS 1.3에서는 보안성이 검증된 고정 DH 파라미터를 사용하고, Ephemeral 모드만을 허용
3. TLS 1.3 (compared to TLS 1.2)
다음 글에서 TLS1.2와 TLS1.3에 관한 내용과 TLS 프로토콜의 취약점에 대해 다룬다.
① outmoded algorithm과 cipher를 지원하지 않음
② RSA암호화를 제거하고 ECDHE or DHE만을 허용(PFS를 보장하고자)
③ Reduces num of negotiations
cipher suite negotiation 과정에서 암호화(키교환, 서명 인증 ,암호화) 별로 협의하도록 함. 알고리즘과 방법이 많아질수록 조합의 개수가 많아지므로 이를 막고자, 각 카테고리별로 협의하도록 함
-
TLS 1.2
-
TLS 1.3
-
TLS 1.2 보다 안전한 프로토콜을 제공
4. Freak
1) What is Freak?
: attack to TLS protocol
negotiation 단계에 공격자가 개입하여 의도적으로 낮은 수준의 암호화 방식을 사용하도록 공격
=> 공격자들이 뚫기 쉽도록
2) How to prevent?
: add signature (negotiation 단계) => 중간 공격이 개입하지 못하도록
