티스토리 뷰

시리즈/Security

TLS handshake 와 Cipher Suites

빅또리 2021. 10. 21. 21:19

 

 

SSL vs TLS

SSL1.0 - never publicly released because of serious security flaws in protocol

SSL2.0 - deprecated in 2011

SSL3.0 - deprecated in June 2015

TLS1.0, TLS1.1 - widely deprecated by web sites around 2020

 

넷스케이프사가 처음 개발한 시조새 같은 프로토콜이 SSL이고 SSL을 계승하고 결점들을 보완해서 현재에 실제 사용되고 있는 프로토콜이 TLS인데, 이중에서 현재 가장 널리 통용되고 있는 것은 TLS1.2 이지만 TLS1.3으로의 세대교체 중인 그런 느낌..?

 

 

 

 

 

Cipher suites

TLS 통신 과정에서 사용할 암호화 알고리즘 모음

TLS 1.2에서는 cipher suites 조합이 37개 였는데 TLS 1.3에서는 5개로 간소화 했다고 한다. 구성하는 알고리즘 요소도 줄었다.

(뭔말인지 밑에서 보자)

 

* TLS에서는 대칭키/ 비대칭키 암호화 방식이 혼합되어 사용된다. 비대칭키 방식이 컴퓨팅 파워가 훨씬 많이 들기 때문에,

실제 통신하려는 application data는 대칭키인 session key로 암호화하고,

handshake 단계에서 키교환이나 서버인증에 비대칭키 방식을 사용해서 안전한 채널에서 session key를 나눠갖는다.

 

* Client Hello때 자기가 support 할 수 있는 Cipher suites 목록이랑 Client Random (32-byte random number) 보내면

Server Hello에서 거기서 고른 Cipher suite, Server Random 보냄

 

 

 

 

TLS 1.2 cipher suites

Cipher suites are named combinations of:

  • Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)   공개 키(session key) 나눠갖는 키 교환 알고리즘
  • Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)    서버 인증 알고리즘 
  • Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)    application data를 암호화하는 공개키 암호화 알고리즘
  • Message Authentication Code Algorithms (SHA-256, POLY1305)   MAC (메세지 무결성), PRF(key gen)에 쓰이는 hash 알고리즘

출처 : https://www.thesslstore.com/blog/cipher-suites-algorithms-security-settings/

 

특히 키교환 알고리즘을 어떤걸 선택하는지에 따라 handshake의 구체적인 구현 모습이 달라진다.

 

1) key exchange & authentication

😎키교환 알고리즘으로 RSA를 선택할 경우

 

RSA는 가장 대표적인 공개키(비대칭키)알고리즘으로 키 교환을 하면서 서버 인증 기능도 수행할 수 있다.

 

1. pre-master secret

클라이언트가 생성한 pre-master secret을 인증서 속 서버 public key로 암호화해서 client key Exchange메세지로 서버에게 전달한다.

 

2. master-secret = PRF( client Random, server Random, pre-master secret)

서버는 받은 pre-master key를 private key로 복호화 한다. 이제 양측이 같은 pre-master secret을 가지고 있음.

각자 master secret 계산.

 

3. session key = PRF (master secret)

이제 안전하게 나눠가진 세션키로 application 데이터를 암호화/복호화하며 주고 받기.

 

* PRF = pseudo random function. ( 해시 함수 )

 

서버가 public key로 암호화된 pre-master 키를 바른 private key로 잘 복호화하면 서버 authentication도 이루어진 것이다.

 

 

😗키교환 알고리즘으로 디피 헬먼 계열 알고리즘 (DH, ECDH, DHE, ECDHE)을 선택할 경우

 

* EC 접두사는 elliptic curve , E 접미사는 ephemeral 이다. (Ephemeral literally means “short lived.”) 

참고로 Perfect Forward Secrecy가 TLS 1.3 부터는 필수로 충족해야 되는게 돼서 ephemeral 안붙은 DH, ECDH 는 TLS1.3에서 아웃 됐다고 한다.

PFS = 서버 private key 가 손상되더라도 session key가 손상되지 않도록 보장하는 기능.

 

diffie-hellman key exchange
디피-헬먼 키 교환은 암호 키를 교환하는 하나의 방법으로, 두 사람이 암호화되지 않은 통신망을 통해 공통의 비밀 키를 공유할 수 있도록 한다. 

디피 헬먼 물감 섞는 걸로 비교한 그림.

Secret Key Exchange (Diffie-Hellman) - Computerphile

 

 

1. shared random value $g$, $p$ - Hello 메세지에서 보내는 client random, server random을 이걸로 설정하나?

 

2. pre master secret 

client = $ g^a \; mod \; p $ (A)

server = $ g^b \; mod \; p $ (B)

client만 서버 public key로 암호화한 pre master key를 보내는 RSA 방식과 다르게 디피헬먼에서는 서버측에서도 키 생성에 필요한 파라미터를 보내야 한다. 그래서 server Key exchange 메세지도 보냄.

 

3. session key

client = $ B^a \; mod \; p $ = $ g^{ba} \; mod \; p $ = $ g^{ab} \; mod \; p $ = $ A^a \; mod \; p $ = server

서버와 클라이언트가 같은 세션키 (대칭키)를 나눠가졌다. 

이제 이걸로 application data encryption/decryption을 하면 된다.

 

 

그런데 디피헬먼을 키교환을 위한 알고리즘이지 authentication의 기능을 할 수는 없기 때문에 꼭 다른 authentication 알고리즘과 함께 쓰여야 한다! 보통 ECDSA, EdDSA를 함께 쓴다. DSA는 이제 잘 안쓴다고 함.

2021.10.20 - [CS] - ECDSA

 ㄴ 서버가 보내는 DH 파라미터 같은 값을 message로 하고 계산한 signature (s,r) 을 같이 보내서

클라이언트가 인증서에 들어있는 public key로 서명을 verify를 하는 방식일 것 같다...

 

 

 

 

 

2) Bulk Encryption

1번이 TLS handshake에서 쓰였다면, 이제 2번은 레코드 프로토콜에서 application data를 암호화할 대칭키 알고리즘을 고르는 것이다.

handshake에서 교환한 session key를 사용해 암호화 한다.

 

2 types of symmetric ciphers

1) block ciphers => encrypt data in pre-determined size

2) stream ciphers => encrypts data in long pseudorandom streams

 

AES는 기본적으로 block cipher인데 counter mode(GCM, CBC) 사용하면 stream cipher인 것 처럼 동작한다고 함...?

그래서 AES_128_GCM을 해석해보면 AES 대칭키 알고리즘, 키 사이즈 128bit, GCM 모드.

 

다른 bulk cipher로는 AES, CHACHA20_POLY1305, DES/Tripe DES, RC4, Camelia, ARIA 같은 것들이 있다. 

 

+ 그리고 record 프로토콜에서 주고 받은 데이터가 중간에 변경되지 않았는지 데이터 무결성도 확인해봐야 하는데,

이 이유로 같이 전송하는 게 MAC (message authentication code)이다. 일종의 체크섬.

HASH ( message | secret key ) 

-> 여기에 어떤 hash 함수 쓸지가 HMAC 알고리즘이고, cipher suites에서 가장 뒤에 적혀있는 것으로 결정된다.

 

* 기존에는 (전송자 입장에서) MAC-then-Pad-then-Encrypt model 이라서, 수신자가 체크하는 과정은 반대니까

MAC부터도 일치되지 않아 버려질 수도 있는 메세진데, 비싼 Decrypt 부터 해야하고 padding oracle attacks 뭐 이런거에도 취약하다고 한다.

TLS 1.3 부터는 MAC, encryption 동시에 진행하는 AEAD cipher 방식을 택함.

TLS1.3 with AEAD - MACs and Encrypts simultaneously, shutting the window on padding attacks and saving clients and servers time and resources by making it easier for them to discard unauthenticated messages without having to decrypt them.

 

 

 

3) Hash algorithm

hash 알고리즘은 사실 앞에서 이미 다 소개 되었다.

handshake 단계에서 session key 사용할 때 등장한 (1) PRF, 그리고 레코드 프로토콜으로 application 데이터 주고 받을 때 MAC 생성할 (2) HMAC 의 해싱 알고리즘을 결정한다.

 

* TLS 1.3 부터는 (1)은 HKDF 대체, (2)는 AEAD로 통합?

HKDF = Hash based Key Derivation Function.

 

 

 

 

TLS 1.3 cipher suites

  1. The type of certificate is no longer listed (whether its RSA or ECDSA)
  2. They key exchange mechanism is not listed (always DHE or ECDHE)

출처 : https://www.thesslstore.com/blog/cipher-suites-algorithms-security-settings/

1) 키교환 알고리즘은 기본적으로 DHE base 알고리즘을사용하기로 하고, 더이상 키교환 알고리즘에 대한 협상은 진행하지 않는다.

따라서 client Hello와 함께 key 파라미터를 전송할 수 있으므로 handshake가 2 round 에서 1 round 로 줄어들 수 있다.

 

2) authentication algorithm은 RSA, ECDSA, EdDSA를 사용할 수 있다.

cipher_suite에서는 생략됐고, "signature_algorithms" Extension으로 어떤 알고리즘을 쓸지 고른다.

 

 

 

 

 

TLS 1.2 vs TLS 1.3

TLS 1.3 : Everything you need to know

 

 

 

 

 

 

TLS handshake

출처 : https://www.thesslstore.com/blog/explaining-ssl-handshake

* change cipher Spec은 이제 나 session 키 사용한 encryption 모드로 데이터 보낼거야 ~ 이렇게 알리는 것.

 

 

the TLS handshake accomplishes 3 main things:

  • Exchanging cipher suites and parameters
  • Authenticating one or both parties
  • Creating/Exchanging symmetric session keys

1. cipher suite는 client Hello, server Hello 메세지에 포함되어 있다. cipher algorithm negotiation.

 

2. 서버가 CA로 부터 발급받은 인증서를 client에게 전송하면, client는 이 인증서의 validity 체크를 하고(CA서명 체크, certificate chain verify, 유효기간 안지났나? CRL(인증서 폐기목록)에 포함된 인증서는 아닌가? 같은 것들..) 

인증서안에 들어있는 서버의 public key로 믿을만한 서버와 통신하고 있는지 검증한다.(상대 서버가 진짜로 인증서 발급시 쌍으로 준 priavate key를 가지고 있는지) 

위에서 이 알고리즘으로 RSA, ECDSA, EdDSA, DSA (deprecated..?) 가 있다는 것을 알아봤다.

 

3.  session key 나눠가지기!

 

 

 

 

참고하면 좋을 글

(완전 좋음 👍👍👍) 이 글도 밑에 두개를 뼈대로 해서 썼다.

Taking a Closer look at TLS/SSL handshake

Cipher Suites: Ciphers, Algorithms and Negotiating Security Settings

 

handshake 과정에서 오고가는 패킷 보기

The first few miliseconds of HTTP connection

Dissecting TLS using wireshark

 

 

대충 보고 넘어갈랬는데 아귀가 안맞아서 찾아보면 볼수록 처음 듣는 암호학 개념이 계속 나와서 난감했다.

아직도 완전히 정리되진 않은 것 같지만. 이쯤하고 넘어가야겠다. 휴...

'시리즈 > Security' 카테고리의 다른 글

HTTPS  (0) 2021.10.21
ECDSA  (0) 2021.10.20
디지털 암호화  (0) 2021.10.16
댓글
공지사항
최근에 올라온 글