TLS Session Resumption
추가적인 지연과 CPU 비용은 보안 통신을 위한 모든 응용 프로그램의 TLS handshake의 심각한 성능 저하를 야기시킨다. TLS는 이러한 비용을 절감하기 위해 다중 연결들 사이에 협상되었던 동일한 secret key data 를 재사용하고 공유하는 방법을 제공한다.
Session Identifiers
RFC5246 명세 에 따르면 Session 식별자 재사용은 SSL2.0 에 처음으로 도입되었다. SSL2.0은 Server가 Session ID가 포함된 32byte Session 식별자를 생성해서 ServerHello 메시지의 일부로 보낸다. Client와 Server 모두 이전에 협상된 Session ID가 키가되는 항목들을 저장하고 다음 세션을 위해 재사용을 할 수 있다.
특히 Client는 Server에게 이전 handshake에 사용된 key와 협상된 cipher suite를 기억하여 재사용 할 수 있도록 ClientHello 메시지에 Session ID를 포함하여 전송할수 있다. 결과적으로 Server가 캐시에서 전달받은 ID와 연관된 session parameter를 찾을 수 있다면 아래의 그림과 같이 handshake를 축소시킬 수 있다. 그렇지 않은 경우, Session 협상 과정 전체가 수행되어 새로운 Session ID가 생성된다.
유효한 Session 식별자는 roundtrip의 전 과정을 반복 하지 않도록 할 뿐만아니라 공유된 secret key의 협상에 사용되는 공개키 암호화의 오버헤드를 줄여준다. Session 식별자는 이전의 협상된 Session 데이터를 사용 할 때부터 보안을 유지하면서도 빠르게 보안 연결을 수립하게 한다.
HTTP\/1.x와 HTTP\/2 개발에서 Session 재사용은 최적화에 매우중요하다. handshake 과정 단축은 full RTT 지연을 줄이고 peer간의 CPU 계산 비용을 줄여준다.
사실 HTTP\/1.x와 같이 브라우저가 같은 호스트에 다중 연결이 필요한경우 Server에 추가적인 연결을 시도하기 전에 첫 TLS handshake 완료를 기다린다. 브라우저들은 협상이 완료되어 저장된 Session Parameter들을 재상요할 수 있다. 네트워크 Log를 살펴보면 TLS Handshake가 동일한 호스트에 다중 연결시 빈번하지 않은지 알수 있다.
Session 식별자 방법의 실질적인 한계 중의 하나는 Server가 모든 Client에 대한 Session 을 생성하고 유지해야 한다는 점이다. 그 결과 Server에는 몇가지 문제가 발생한다. 다수의 서버로 구성되어 매일 수천에서 수백만 연결이 발생하는 인기있는 사이트들의 경우 TLS 연결과 Session ID 캐시에 메모리를 소모하고, 많은 개발적 한계에 부딪히게 된다. 이상적인 방법으로는 서버들이 최적의 성능을 위해서는 TLS Session cache를 공유하여 사용하는 것이다.
이와 같은 문제들이 해결 불가능한 것은 아니다. 오늘날 트래픽이 많은 사이트들이 Session 식별자를 문제없이 사용한다. 하지만 다수의 서버 환경에서 Session 식별자는 각별한 주의가 필요하고 시스템 구조적으로 Session 캐시가 정상적으로 동작하는지를 보장할 수 있어야 한다.
Session Tickets
Server 측의 TLS Session 캐시 개발의 이슈를 해결화기 위해서 Session Ticket 대체 방법(RFC 5077) 이 도입되었다. Session Ticket은 Server가 Client Session 상태를 유지할 필요를 없앴다. 대신 Client가 Session Ticket을 지원한다는 것을 알려주면 Server는 모든 Server만 알고 있는 비밀키로 암호화된 Session 데이터를 새로운 Session Ticket 레코드에 포함할 수 있다.
이 Session Ticket은 Client에 저장되고 연결 이후 Session의 ClientHello 메시지 안에 SessionTicket 확장으로 포함될 수 있다. 게다가 Client 에 저장되어 있는 Session Data는 Server만 알고있는 키에 의해 암호화 되어 있기 때문에 보안을 유지할 수 있다.
Session 식별자와 Ticket은 각각 session caching 과 statelesss resumption 방법으로 간주된다. 상태를 유지하지 않는 재사용 방법의 주요한 장점은 Server 측의 Session Cache의 삭제인데, 이 방법은 Ticket이 만료될 때까지 Server에 모든 새로운 연결에 대한 Session Ticket을 제공하는 Client의 필요를 쉽게 개발할수 있게 한다.
실제적으로 Load Balanced 서버들의 Session Ticket 발급을 배포하는 것은 시스템 구조와 주의가 필요하다. 모든 서버들이 같은 세션키로 초기화되어야 하고 주기적으로 보안을 위한 모든 서버들의 공유된 키의 순환을 위한 추가적인 방법이 필요로 하다.