암호 방식이 합의가 된 후 이걸 사용 해서 키를 설정하기 위한 파라메터 값을 서로 주고 받아야 된다.
서버가 자신의 인증서를 보낸다. 여기에는 자신의 공개키가 들어 가 있다. (몰론 CA가 서명한 공개키 이다)
클라이언트는 이 인증서를 받게되면 서버의 🔑 (공개키)를 갖게되고 서버 인증을 하는 것이다.
그 다음에 어떤 키 설정 방식을 사용하느냐에 따라서 server_key_exchange를 가지고 필요한 정보를 전달하게 된다.[참고 키 교환 방법] ex) Diffie-Hellman방식을 사용한다면 server_key_exchange에 다가 파라메터를 넣어서 전달을 하게 되는거다.
그리고 서버가 클라이언트에 인증 혹은 다른 정보를 위해서 클라이언트에 certificate_request를 보낸다. (이거는 optional)
모든게 제대로 되면 server_hello_done해서 단계 2의 과정이 끝난다.
여기 단계2 과정이 제대로 이루어지게 되면은 클라이언트와 서버는 서로 키를 설정할 수 있는 모든 정보를 다 갖추게 된다.
단계 2: 서버 인증과 키 설정
서버가 클라이언트에게 인증서를 보낸다. 그 때 서버의 공개키를 넣어서 보내는데 이 경우에는 키 설정을 RSA, ephemeral DH을 사용할 경우이고, 만약에 fixed DH를 사용 할 경우에는 서버가 보내는 CA(인증기관)가 인증한 DH파라메터를 넣어서 보내게 된다.
서버가 필요한 정보를 server_key_exchange 메세지를 보내는데 anonymous의 경우에는 DH 파라메터값을 그냥 보내는거고 ephemeral DH는 자신의 개인키로 서명을 해서 보내는 것이다. 주의 할 점은 fixed DH는 이미 인증서에 파라메터를 보냈기 때문에 server_key_exchange 메시지에 보낼 필요가 없다.
만약에 클라이언트에 인증서가 필요하면 certificate_request를 하게 된다.
모든것을 다 하면 server_hello_done을 보낸다.
이런 메시지를 보낼 때 메시지의 무결성과 인증을 위해서 hash(client_rand || server_rand || server parameters). 이 세개의 값을 해쉬하고 나온 값을 서버의 개인키로 서명을 해서 주고받는 메시지들에 붙인다. 이것이 MAC이다. *client_rand = 클라이언트의 nonce, server_rand = 서버의 nonce ( 이 두 개는 단계 1에서 이미 서로 hello 메시지를 주고 받으며 handshake를 하면서 갖고있는 값이다.)
이렇게 MAC을 붙여서 주고 받는 메시지의 무결성과 인증을 해준다.
Thus, 단계 1에서 클라이언트가 자신의 nonce값을 client_hello메시지로 보냈고 서버가 클라이언트의 nonce값을 갖고있고, 그 다음 서버도 자신의 nonce값을 클라이언트에게 보냈다. 이 과정에서 그냥 텍스트를 보낸거고 누구든지 이 메시지(nonce값)들을 볼 수 있다. 그리고 클라이언트와 서버가 할 수 있는 것은 없으니까 그대로 메시지를 전송하는 것이다. 그다음에 단계 2에서 인증서를 보내면서 클라이언트는 서버의 공개 키를 갖게된다. 만약 DH방식으로 키를 설정하면 서버는 클라이언트에게 서버의 DH 파라메터값을 보낸다. 그래서 파라메터 값들을 공유하고 있는 것이다. 그러면 클라이언트는 서버하고 같이 사용할 수 있는 세션키를 만들어야 하는데 이것을 만들기 위해서는 클라이언트와 서버만이 알고 있는 값으로 만들어야 해서 비밀값을 만드는데 이 비밀값의 이름이 PMS(Pre-Master Secret)이다. 비밀값을 만드는 방식은 [키 교환 방법을 참고].
'서버 > 암호' 카테고리의 다른 글
TLS Handshake 프로토콜 (4 단계) (0) | 2021.03.21 |
---|---|
TLS Handshake 프로토콜 (3 단계) (0) | 2021.03.21 |
TLS Handshake 프로토콜 (1 단계) (0) | 2021.03.21 |
TLS의 절차 (0) | 2021.03.20 |
세션키를 만드는 두 가지 방법 (0) | 2021.03.20 |