TLS 통신에는 다음과 같은 작업들이 있다.
서버의 신뢰성을 보증하는 구조는 공개키를 보증하는 구조이기도 하다. 공개키 기반구조 (PKI; Public Key Infrastructure)라고 불린다.
클라이언트는 서버가 보내준 인증서의 신뢰여부를 확인한다. 인증서는 X.509 포맷으로 되어있는 파일로, 사이트주체(이름, 도메인), 발행자, 서버의 공개키, 유효기간 등이 담겨있다.
발행자는 인증기관(CA; Certificate Authority)라고 부르며 신뢰성 확인의 핵심은 발행자다. 또한 인증서는 발행자의 디지털 서명도 함께 담겨있다. 그래서 인증서에 포함된 디지털 서명을 이용하여 인증서가 위변조되지는 않았는지 확인이 가능하다. 그리고 다시 상위 발행자의 인증서도 차례로 검증해 나간다.
이렇게 상위 발행자의 인증서를 검사해나가다보면 최종적으로는 발행자와 주체자가 동일한 인증서가 나오게 되는데 이를 루트 인증기관 이라고 부른다. 브라우저, OS는 '미리 신뢰할 수 있는 인증기관의 인증서' 목록을 관리하고 있다. 이 신뢰할 수 루트 인증기관의 인증서 목록과 대조함으로써 최종적으로 서버를 신뢰할 수 있는지 여부가 결정 된다.
Client Hello, Server Hello 협상을 통해 어떤 공개키 암호화 알고리즘과 어떤 키 교환 전용 알고리즘을 사용할지 결정한다.
클라이언트는 먼저 난수를 사용하여 통신암호화에 사용될 공통키를 생성한다. 서버 인증서에 포함된 공개키를 이용하여 이 공통키를 암호화하여 서버로 보낸다. 서버는 자신의 비밀키를 사용하여 클라이언트가 보내준 데이터를 복호화하여 공통키를 꺼낼 수 있다.
클라이언트와 서버가 생성해낸 공통키를 사용하여 TLS 핸드쉐이크 과정 이후에는 공통키 암호화 방식으로 암호화된 데이터들이 오가게 된다. 그리고 전송되는 데이터들에도 해시값을 붙여서 전송한다. 그래서 이 해시값을 사용하여 중간에 데이터가 조작되었는지 탐지할 수 있다.
TLS는 TCP 핸드쉐이크과정 외에 TLS 핸드쉐이크 과정도 있으므로 매번 이러한 과정이 발생하면 오버헤드가 상당할 것이다.
하지만 HTTP Keep-Alive를 사용하여 커넥션을 재사용하게 되면 이러한 과정은 최초 1회만 수행하면 된다.
또한 TLS 1.2에는 새션 재개 기능이 있다. 최초 핸드쉐이크시 이전에 사용하던 세션ID를 보내면 이후 키 교환 과정이 생략되고 새션이 재게된다.
TLS 1.2까지는 TLS 핸드쉐이크 과정에서 어떤 암호화 스위트(Cipher Suite)를 사용할지 결정하는 과정이 포함되어있었다. 하지만 TLS 1.3에서는 암호화 스위트에 퉁쳐져 있던 '키 교환 알고리즘' / '대칭키 암호화 알고리즘' / '인증서 서명 알고리즘'을 분리하여 유연성을 높혔다. 또한 ClientHello 과정에서부터 키 교환할 수 있도록 개선하여 통신왕복을 1개를 줄일 수 있게 되었다.