자물쇠 아이콘 뒤에서 벌어지는 협상
브라우저 주소창의 자물쇠는 그 사이트와의 통신이 암호화돼 있다는 표시입니다. 이 암호화 통신을 시작하기 직전, 클라이언트와 서버는 짧지만 정교한 협상을 거칩니다. 이 과정이 TLS 핸드셰이크입니다. 어떤 암호 방식을 쓸지 합의하고, 상대가 진짜인지 신원을 확인하고, 실제 데이터를 암호화할 열쇠를 함께 만들어내는 일이 모두 이 짧은 순간에 일어납니다.
이 협상이 끝나기 전까지는 어떤 실제 데이터도 오가지 않습니다. 먼저 안전한 통로를 확보한 다음에야 본 통신을 시작하는 것입니다. 사용자는 페이지가 그냥 뜬다고 느끼지만, 그 이면에서는 양쪽이 신뢰할 수 있는 비밀 통로를 까는 작업이 먼저 완료됩니다. 이 과정이 제대로 이뤄져야 이후 주고받는 모든 내용이 도청과 변조로부터 보호됩니다.
핸드셰이크가 풀어야 할 세 가지 숙제
TLS가 보장하려는 것은 세 가지로 요약됩니다. 첫째는 통신 내용을 제3자가 엿볼 수 없게 하는 암호화입니다. 둘째는 상대가 사칭이 아니라 진짜 그 상대가 맞는지 확인하는 인증입니다. 셋째는 데이터가 중간에 조작되지 않았음을 보장하는 무결성입니다.
이 셋은 따로 노는 것이 아니라 하나라도 빠지면 보안이 무너집니다. 아무리 암호화해도 상대가 가짜라면 비밀을 통째로 적에게 넘기는 꼴이고, 인증과 암호화가 완벽해도 내용이 도중에 바뀐다면 신뢰할 수 없습니다. 핸드셰이크는 본 통신이 시작되기 전에 이 세 가지를 한꺼번에 갖춰두는 준비 절차입니다.
TLS 1.2 핸드셰이크의 흐름
전통적인 TLS 1.2 핸드셰이크는 여러 단계의 주고받음으로 이뤄집니다. 한 단계씩 따라가 보면 각 메시지가 왜 필요한지 드러납니다.
클라이언트 헬로
클라이언트가 먼저 인사를 건넵니다. 자신이 지원하는 TLS 버전, 사용할 수 있는 암호 방식들의 목록, 그리고 협상에 쓸 무작위 값을 함께 보냅니다. “나는 이런 것들을 쓸 수 있는데 무엇으로 할까”라고 제안하는 단계입니다.
서버 헬로와 인증서
서버는 클라이언트가 제시한 목록 중에서 쓸 암호 방식을 하나 고르고, 자신의 무작위 값과 함께 인증서를 보냅니다. 이 인증서에는 서버의 신원 정보와 공개 키가 담겨 있습니다. 클라이언트는 이 인증서가 신뢰할 수 있는 기관이 발급한 것인지, 접속한 도메인과 일치하는지 검증해 상대가 진짜인지 확인합니다.
키 교환
양쪽이 지금까지 주고받은 값들을 바탕으로 세션 키를 만들어냅니다. 이 키는 이후 본 통신을 암호화하는 데 쓰이며, 통신 당사자 둘만 아는 비밀이 됩니다. 흥미로운 점은 이 비밀 키가 네트워크를 통해 직접 전달되지 않는다는 것입니다. 양쪽이 각자 가진 정보를 조합해 같은 키에 도달하는 방식이라, 도중에 누가 엿들어도 키 자체는 알아낼 수 없습니다.
TLS 1.3은 무엇이 달라졌나
최신 버전인 TLS 1.3은 핸드셰이크를 크게 간소화했습니다. 우선 안전성이 의심되는 옛 암호 방식들을 목록에서 아예 빼버렸습니다. 협상할 후보가 줄어드니 과정이 단순해지고, 취약한 방식으로 내려앉을 위험도 사라졌습니다.
또한 왕복 횟수를 줄였습니다. 클라이언트가 서버의 선호 방식을 미리 가정하고 첫 메시지부터 키 교환에 필요한 정보를 함께 보내기 때문에, 협상이 한 번의 왕복으로 끝납니다. 결과적으로 TLS 1.3은 이전보다 더 빠르면서 동시에 더 안전해졌습니다. 보안을 강화하는 것이 보통 속도를 희생하는 것과 달리, 둘을 함께 끌어올린 드문 사례입니다. 각 메시지의 세부 구성은 IETF RFC 8446(TLS 1.3 표준 문서)에서 단계별로 볼 수 있습니다.
대칭 키와 비대칭 키의 분업
핸드셰이크에는 두 종류의 암호 방식이 영리하게 나뉘어 쓰입니다. 신원을 확인하고 비밀 키를 안전하게 합의하는 단계에서는 공개 키와 개인 키가 짝을 이루는 비대칭 방식을 씁니다. 이 방식은 안전하지만 계산이 무거워, 모든 데이터를 이걸로 암호화하기에는 비효율적입니다.
그래서 일단 비대칭 방식으로 둘만의 비밀 키를 안전하게 합의하고 나면, 이후 실제 데이터는 그 비밀 키를 양쪽이 똑같이 쓰는 대칭 방식으로 암호화합니다. 대칭 방식은 빠르기 때문입니다. 무거운 방식으로 열쇠를 안전하게 나눠 갖고, 가벼운 방식으로 본 통신을 빠르게 처리하는 이 분업이 보안과 속도를 동시에 잡는 핵심입니다.
인증서를 믿을 수 있는 이유
핸드셰이크에서 서버가 보내는 인증서를 클라이언트가 어떻게 신뢰할 수 있을까요. 핵심은 신뢰의 사슬입니다. 서버 인증서는 인증 기관이라 부르는 공신력 있는 기관이 서명해 발급합니다. 그 인증 기관은 다시 상위 기관의 서명을 받고, 이렇게 거슬러 올라가면 최상위에 모두가 신뢰하기로 약속한 루트 기관이 있습니다.
브라우저와 운영체제에는 이 신뢰할 수 있는 루트 기관 목록이 미리 담겨 있습니다. 그래서 서버 인증서를 받으면, 그것이 신뢰된 루트까지 올바르게 이어지는지를 사슬을 따라 검증합니다. 사슬이 끊기거나 알 수 없는 기관이 발급했거나 유효 기간이 지났다면, 브라우저는 경고를 띄워 사용자에게 위험을 알립니다. 자물쇠 아이콘은 바로 이 검증이 통과했다는 신호인 셈입니다.
핸드셰이크와 지연의 관계
핸드셰이크는 안전을 위한 필수 절차지만, 왕복이 늘어날수록 그만큼 지연이 쌓입니다. 본 통신을 시작하기 전에 거쳐야 하는 단계이므로, 핸드셰이크가 느리면 페이지가 처음 뜨는 시간 전체가 느려집니다. 그래서 이 비용을 줄이려는 시도가 꾸준히 이어져 왔습니다.
한 번 맺은 세션을 저장해두었다가 다음 연결에서 협상을 건너뛰고 재사용하는 방법, 그리고 TCP 연결 수립과 암호화 협상을 하나로 묶어 왕복을 줄이는 방법이 대표적입니다. QUIC이 이 둘을 동시에 처리하는 것이 좋은 예로, 연결과 암호화를 한 번에 끝내 첫 응답까지 걸리는 시간을 단축합니다. 보안을 유지하면서도 사용자가 느끼는 대기 시간을 줄이려는 노력의 결과입니다.