30초 답변
TLS handshake는 HTTPS 연결을 시작할 때 client와 server가 안전한 암호화 통신을 준비하는 과정입니다.
client는 지원하는 TLS version과 cipher suite 등을 보내고, server는 인증서와 선택한 암호화 설정을 보냅니다. client는 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지, domain이 맞는지 확인합니다.
이후 key exchange를 통해 실제 데이터 암호화에 사용할 session key를 합의합니다. handshake 이후에는 비용이 큰 비대칭키 암호화보다 빠른 대칭키 암호화로 데이터를 주고받습니다.
꼬리질문
조금 더 깊게 물어본다면
답변 뒤에 이어질 수 있는 질문들을 하나씩 열어볼 수 있어요.
인증서는 무엇을 보장하나요?
인증서는 public key와 domain 소유 정보를 CA가 서명한 문서입니다. client는 CA chain을 검증해 이 public key가 해당 domain의 서버와 연결된다고 믿을 수 있습니다.
인증서는 암호화 자체보다 신원 확인에 중요한 역할을 합니다.
비대칭키와 대칭키를 둘 다 쓰는 이유는 무엇인가요?
비대칭키는 안전한 key 교환과 인증에 유리하지만 상대적으로 느립니다. 대칭키는 빠르지만 양쪽이 같은 key를 안전하게 공유해야 합니다.
TLS는 handshake에서 안전하게 key를 합의하고, 실제 데이터 전송은 대칭키로 빠르게 처리합니다.
HTTPS면 모든 보안 문제가 해결되나요?
아닙니다. 전송 중 도청과 변조를 막는 데 도움을 주지만, XSS, CSRF, 서버 취약점, 잘못된 권한 검사는 별개 문제입니다.
HTTPS는 기본 조건에 가깝지 전체 보안의 끝은 아닙니다.
session resumption은 왜 필요한가요?
매번 full handshake를 하면 지연과 계산 비용이 큽니다. session resumption은 이전 연결 정보를 활용해 handshake 비용을 줄이는 방식입니다.
반복 방문이나 여러 요청이 있는 웹 환경에서 성능에 도움이 됩니다.
부가 설명
ClientHello
ServerHello + Certificate
Certificate verification
Key exchange
Encrypted application data
실제 TLS 버전에 따라 세부 흐름은 다르지만, 큰 목적은 “상대 신원 확인 + 안전한 session key 합의”입니다.
TLS는 암호화뿐 아니라 무결성과 인증도 제공합니다. 사용자는 주소창의 HTTPS를 보고 “중간에서 내용을 훔쳐보기 어렵고, 내가 접속한 서버가 해당 domain의 서버라는 것을 검증했다”고 기대할 수 있습니다.
handshake에는 비용이 있으므로 connection reuse, session resumption, HTTP/2/3와도 함께 연결해서 볼 수 있습니다.
한 줄 정리
TLS handshake는 서버 신원을 확인하고 이후 암호화 통신에 쓸 session key를 안전하게 합의하는 과정입니다.