HTTPS에서 SSL 세션 아이디(Session ID) 와 세션 티켓(Session Ticket) 차이

웹 통신에서 HTTPS 트래픽을 처리하기 위해 클라이언트와 서버간 SSL 세션을 맺는 HTTPS 핸드쉐이크 과정 다들 아시지요?

자! 아래 그림을 참고해 보겠습니다.

네.. 일반적인 HTTPS 핸드쉐이크 과정입니다. 위 과정이 모두 완료되어야 클라이언트-서버간 암호화된 데이터를 주고 받을 수 있습니다.

그런데 여러분..

데이터를 보내려고 할때마다 위와 같이 인증서를 확인하고.. 암호화 방식을 결정하며.. 데이터 암호화에 사용할 키를 생성하고 서로 교환하는 과정을 반복한다면.. 얼마나 비효율적일까요?

클라이언트와 서버간 Latency 가 50ms 라고 한다면.. 실제 데이터를 교환하기 위해 매번 200 ms(클라이언트 기준) 의 핸드쉐이크 과정이 포함되어야 합니다.

가뜩이나 암/복호화로 인해 서버의 응답 지연시간이 HTTP 보다 느려지는데.. 핸드쉐이크 과정까지 매번 수행하게 되면.. 속도측면에서 얼마나 만족스러운 결과를 기대할 수 있을까요?

그렇습니다. 우리가 지금 고민하고 있듯이.. SSL 프로토콜을 만드신 분들께서도 이런 사항을 고민하셨겠지요~..

HTTPS 핸드쉐이크의 과정을 대폭 개선한 간소화된 핸드쉐이크 과정이 이미 나와있습니다.

크게 보면.. 2가지네요~.. 

그 중 먼저 첫 번째… 두둥~

1.     SSL Identifier 메커니즘

일단, 최초로 서버와의 통신을 시도하는 클라이언트는 어쩔 수 없습니다.

Full 핸드쉐이크 과정을 처음엔 거쳐야 합니다.

먼저 클라이언트는 최초 접속이기 때문에 Client Hello 메시지에 session id 값이 없습니다.

아래 2번과정에서 서버는 Server Hello 메시지에 Session Identifier 를 포함하여 전달합니다. 

클라이언트는 서버에서 발행해 준 Session Identifier 정보를 로컬에 저장하게 되는데요~..

클라이언트는 다음 HTTPS 세션을 맺을 때 이 값을 사용하게 됩니다. 

저장해 둔 Session Identifier 값을 Client Hello 메시지에 포함하여 전달합니다. 

서버는 클라이언트가 보내준 Session Identifier 정보를 확인하고, 이를 다시 사용해도 된다고 판단이 되면, Server Hello 메시지에 같은 Session IDs 값을 포함하여 전달합니다. (위 2번 과정)

이러면.. 다음 과정들이 생략됩니다.

ㄱ.   서버 인증서 확인

ㄴ.   암복호화에 사용할 Cipher Sutes 결정

ㄷ.   암복호화에 사용할 암호화 키 교환

이전에 사용했던 Cipher Suite 와 암호화 키를 다시 재활용하게 되므로 Full 핸드쉐이크 과정보다 2 Step 정도가 간소화 되네요~.. 

처음과 같이 하나의 과정의 Latency 를 50ms 로 가정한다면.. 100ms 정도를 개선하는 효과가 생깁니다.

클라이언트-서버간 주고 받아야 할 트랜잭션이 많을수록 효과는 크게 됩니다. 

2.     Session Ticket 메커니즘

두번째 방법은 Session Ticket 메커니즘입니다.

이 역시도 최초에는 Full 핸드쉐이크 과정을 수행해야 합니다. 가장 마지막 과정에서 서버는 “New Session Ticket”메시지를 클라이언트에게 전달합니다. 여기에는 암복호화에 사용할 마스터 키와 Cipher Sutes 알고리즘이 포함되어 있습니다.

세션 티켓의 정보는 서버만 알고 있는 키로 안전하게 암호화 하여 처리합니다.

세션 티켓 메커니즘은 TLS 확장 옵션입니다. 해당 메커니즘은 클라이언트와 서버가 모두 지원해야만 사용할 수 있습니다.

클라이언트는 Client Hello 메시지의 확장 옵션부분에 값이 없는 Session Ticket 을 같이 포함하여 전달함으로써 Session Ticket 메커니즘을 지원함을 알립니다. 서버 역시 Server Hello 메시지에 같은 방식으로 지원여부를 알립니다. 

클라이언트가 다시 서버에 HTTPS 통신을 시도하게 되면 다음과 같이 간소화된 절차를 거치게 됩니다.

클라이언트나 서버 둘 중 하나도 이를 지원하지 않는 경우에는 Session Identifier 메커니즘을 사용하게 됩니다.

Session Ticket 메커니즘이 상세히 기술된 RFC 5077 에는 Session Identifier 보다 Session Ticket 메카니즘의 사용을 더 권장하고 있습니다.

이유는 두가지인데요~

첫째, 서버의 메모리 사용이 적습니다. Session Identifier 는 서버가 발행한 Session IDs 값들을 모두 메모리에 기억하고 있어야 합니다. 

따라서 접속사용자가 많은 경우에는 서버 메모리 자원에 영향을 줄 수 있습니다. 

반면, Session Ticket 메커니즘은 클라이언트가 해당 내용을 기억하고 서버로 전달하는 방식이라 서버의 메모리 자원에 영향이 적습니다.

둘째, L4에 의한 부하분산 환경에서는 Session Identifier 메커니즘을 사용하는데 문제가 될 수 있습니다.

L4 의 부하분산 방식이 사용자의 IP를 참고하지 않는 방식의 경우 사용자를 동일한 서버로 분산하지 않기 때문에 SSL 세션 재활용 효율이 적습니다. 

이는 서버가 정보를 저장하고 이용하기 때문인데, 반면 클라이언트가 정보를 전달하는 방식인 Session Ticket을 사용할 경우에는 L4의 환경에 영향을 전혀 받지 않습니다. 

간만에 블로그 내용을 포스팅합니다. ^^

2018년은 새해 시작하면서 엄청 바쁘네요~.. 블로그 포스팅에도 앞으로 신경 쓰겠습니다. 

끝~~