TLS1.3 (2) - SSL/TLS Handshake

 

 

 

 

 

---

 

 

 

 

앞선 포스팅에서 키 교환 프로토콜에 대해 간단히 설명했는데, 

이를 기반으로 SSL/TLS handshake 과정을 자세히 살펴보자.

여기서 설명하는 SSL/TLS handshake 과정은 TLS 1.2 이하에 해당하는 과정이다.

 

 

 

 

 

 

---

 

 

TLS 1.2 Handshake

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

위에 와이어샤크로 직접 캡쳐한 TLS 1.2 Handshake 트래픽을 참고하며 아래 설명을 해보자면,

 

 

 

client--------------------------------------------------------------------------------------------server

1) client hello -> 

                                                                       <- 2) server hello (+ server certificate, server key exchange*)

3) verify server certificate

4) client key exchange ->

5) finished (+ change cipher spec) -> 

                                                                         <- 6) finished (+ change cipher spec)

                                       <- 7) exchange messages ->

 

 

 

 

이렇게 간단히 표현할 수 있다.

 

 

 

 

 c  1) TLS 버전, 암호 알고리즘 목록 (cipher suites), client random 전송

 

 s  2) cipher suites 에서 선택한 암호 알고리즘, server random, session ID, CA가 서명한 server 인증서 전송

      * server 인증서에 server 공개키 포함

 

 c  3, 4)

  □ RSA : CA 통해 server 에 대한 신뢰성 확보 후, premaster secret 생성 후 server 공개 키로 암호화하여 전송,

            server 는 자신의 개인 키로 premaster secret 복호화

  □ Diffie-Hellman : client 가 D-H 공개키 생성 후 (Diffie-Hellman client params) server 에 전송하고,

                         client 와 server 는 각각 premaster secret 생성

  premaster secret과 client/server random 으로 master secret 생성 및 세션키 생성

 

 c  5) client 는 지금까지의 교환 내용을 적용하고, 이를 해시한 값을 대칭 키로 암호화, 전송 및 종료

 

 s  6) server 역시 교환 내용 적용 후, 해시를 생성하여 client 로부터 받은 값과 비교, 일치하면 대칭 키로 암호화한 종료 메시지 전송

 

 c <->  s  7) SSL/TLS 세션 동안 대칭 키로 암호화된 애플리케이션 (HTTP) 데이터 통신 

 

 

 

 

 

 

* 2, 3, 4) 에서,

RSA 가 아닌 D-H (fixed, ephemeral) 방식을 사용하여 암호화 한다면,

D-H 매개변수에 거명해 인증하는 server key exchange 과정 (Diffie-Hellman server params)이 추가된다.

(anonymous D-H 에서는 서명 생략)

D-H 매개변수를 전달 받아야 client 가 D-H 공개키를 생성할 수 있기 때문

Ephemeral Diffie-Hellman
매 협상 시 마다 새로운 D-H 개인키 생성

 

 

 

* 2) 에서,

server 인증서의 기능은 2가지이다.

- client 가 접속한 server 가 신뢰할 수 있음을 보증

- TLS 연결 위한 server 공개 키 제공

 

 

 

---

 

 

 

 

 

비대칭 암호화가 오버헤드가 높기 때문에 모든 통신 과정 내내 비대칭 암호화를 사용할 수 없어,

1,2,3,4,5,6 까지는 비대칭 키 방식을 이용하여 트래픽을 주고 받으며,

7 이후부터 대칭키( TLS 공유 비밀 키) 방식을 이용하여 암호화 통신을 시작한다.

 

 

즉, 

인증서에 들어있는 server의 공개 키는 비대칭 암호화를 사용하는 것을 보여주며,

server/client 모두 premaster secret 을 가지고 이 값을 master secret 으로 변환하여 최종적으로 session key 를 생성하면

server 와 client 는 실제 데이터 전송 시, 이 session key 를 사용하여 암/복호화를 수행하는 대칭 암호화를 사용한다.

 

 

다음 포스팅에서 TLS 1.3 에 대해 살펴보자.

 

 

 

 

 

참고 : wangin9.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%ED%9B%84-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC%EB%93%A4-5TLSSSL-Handshake