단계 이름을 외웠는지가 아니라 왜 그 순서여야 하고 어느 단계에서 무엇이 보장되는지를 가르는 질문이다. 후속으로 1.2와 1.3 차이, 0-RTT 재전송 위험, 인증서 체인 검증 실패를 던져 깊이를 측정한다.
TLS 핸드셰이크는 평문 채널 위에서 신뢰 검증과 세션 키 합의를 동시에 완료하는 절차다. Client Hello에서 버전·암호 스위트·랜덤값을 교환하고, 서버 인증서로 신원을 증명한다. 클라이언트는 인증서 체인을 루트 CA까지 검증하고, 양쪽은 임시 키 교환값으로 같은 세션 키를 도출해 Finished로 맞춘 뒤 본 통신은 대칭키로 넘긴다. 비대칭은 키 합의에만 쓰고 데이터 전송은 대칭으로 가는 게 핵심 설계다. 비용이 싸고 빠른 대칭키를 써야 하는데 키를 평문으로 주고받을 수 없어서 이 구조가 나온다.
인증서 만료·체인 누락으로 배포 직후 HTTPS가 막혔던 경험이 있다면 어느 핸드셰이크 단계에서 끊겼는지로 풀어낼 수 있다
사설 CA·자체 인증서를 직접 등록해 본 경험이 있다면 신뢰 체인과 OS·브라우저 신뢰 저장소 이야기로 이어갈 수 있다
CDN·로드밸런서 앞단에서 TLS를 종단해 본 적이 있다면 종단·재암호화와 헤더 전달 트레이드오프를 함께 말할 수 있다
openssl s_client나 Wireshark로 핸드셰이크를 직접 까본 경험이 있다면 단계별로 짚는 답변이 자연스러워진다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.