TLS Handshake

Client와 Server가 TLS를 통해 응용프로그램 데이터를 교환하기 전에 암호화된 터널이 결정되어야 한다. Client와 Server는 TLS 프로토콜 버전, ciphersuite를 동의하고 만약 필요하다면 인증서의 유효성을 검증해야 한다. 불행히도, 각각의 과정은 Client와 Server 사이에 새로운 패킷의 왕복이 필요하다.

0 ms

TLS는 신뢰할수 있는 TCP 프로토콜에서 동작한다. 그러므로 반드시 먼저 TCP Three-Way handshake가 완료되어야 한다.

56 ms

TCP 연결이 된 상태로, Client 는 평문으로 TLS 프로토콜이 동작하는 버전, 지원되는 ciphpersuite, 사용하고자 하는 TLS 옵션과 같은 수많은 명세를 보낸다.

84 ms

Server는 앞으로의 통신을 위해 TLS 프로토콜 버전을 선택한다. Client로 부터 제공받은 목록으로부터 ciphersuite를 선택하고, 공인인증서를 첨부시켜 Client에게 응답을 보낸다. 선택적으로, Server는 Client의 공인인증서와 TLS extension을 위한 항목의 요청을 보낼 수 있다.

112 ms

양쪽이 보통의 버전과 암호화를 사용할 수 있다면 Client는 Server로부터 제공된 인증서를 반길것이다. Client는 RSA나 Diffie-Hellman 키 교환을 둘다 초기화 한다.

140 ms

Server는 Client로 부터 보내진 키교환 항목을 처리한다. MAC 을 검증하여 메시지 무결성을 확인하고 암호화된 Finished 메시지를 Client 에게 되돌려 보닌다.

168 ms

Client는 협상된 대칭키로 메시지를 복호화 하고 MAC을 검증한다. 모든게 정상적이면 연결을 수립하고 이제 응요프로그램의 데이터가 보내질수 있다.

위의 그림과 같이 새로운 TLS 연결은 Handshake를 위해 2번의 왕복이 필요로 하다. 그러나 실제로 최적화된 개발을 통해 1번의 RTT로 TLS handshake를 전달하여 더 효율을 높일 수 있다.

• False start는 client와 server가 handshake가 부분적으로 완료되었을때 암호화된 응용 프로그램 데이터를 보낼수 있도록 하는 TLS 프로토콜 옵션이다. 다시말하면 ChangeCipeherSpec과 Finished 메시지가 보내지면 상대가 똑같이 메시지를 보낼때까지 기다릴 필요가 없다. 이 최적화는 새로운 TLS 연결을 1번의 RTT를 통해 Handshake 오버헤드를 줄여준다.
• Client가 Server 와 이전에 통신을 했었다면 "축소된 handshake"가 사용될수 있다. 축소된 Handshake는 1 RTT가 필요하고 Client와 Server가 이미 협상되었던 보안세션 파라미터를 다시 사용함으로써 CPU overhead를 줄인다.

위의 최적화 방법 두가지를 조합하여 새로운 사용자나, 재사용하는 사용자들의 TLS handshake 1-RTT로 구성할 수 있다. 게다가 이전에 협상된 Session 항목들을 기반으로 한 세션을 사용함으로써 CPU overhead를 줄일 수 있다.

TLS1.3의 설계 목표중의 하나는 보안 연결의 설정에 지연 overhead를 줄이는데 있다. 최초의 연결은 1-RTT, 재연결은 0-RTT