TLS/SSL

공용 와이파이이든 내부 네트워크이든, 중간 경로를 지나는 패킷은 누군가 볼 수 있고 바꿔치기할 수도 있습니다. 비밀번호나 세션 쿠키가 평문으로 흐르면 도청만으로도 계정 탈취가 가능하고, 사용자는 지금 연결한 서버가 진짜 서버인지 확인하기 어렵습니다. 보안 문제는 단순히 내용을 숨기는 것에 그치지 않고, 내가 대화하는 상대가 진짜인지 증명하는 문제까지 포함합니다. 데이터가 기밀해야 하고, 중간에서 변조되지 않아야 하며, 서버 신원도 검증돼야 합니다. TLS는 이 세 가지 요구를 한 연결 안에서 함께 해결하려고 설계됐습니다.

인터넷이 상업화되기 전에는 네트워크 통신을 지금만큼 적대적인 환경으로 보지 않았습니다. 그러나 1990년대 중반 전자상거래가 확산되면서, 신용카드 번호와 계정 정보가 평문으로 흐르는 상황이 현실 문제로 떠올랐습니다. 넷스케이프가 1995년 SSL 2.0을 내놓은 것이 시작이었고, 이듬해 SSL 3.0으로 설계를 크게 고쳤습니다. 1999년 IETF가 SSL 3.0을 기반으로 표준화하면서 이름을 TLS 1.0으로 바꿨습니다. 넷스케이프라는 한 회사의 프로토콜에서 인터넷 표준 기구의 공식 프로토콜로 넘어간 것입니다. 프로토콜 내부도 달라졌는데, 핸드셰이크 메시지 구조와 MAC 계산 방식이 변경돼 SSL 3.0과 TLS 1.0은 서로 호환되지 않습니다. 이후 TLS 1.1, 1.2를 거치며 취약한 암호 스위트를 제거하고 검증 체계를 강화했고, 2018년 TLS 1.3에서는 핸드셰이크를 1-RTT로 단축하고 안전하지 않은 옵션 자체를 프로토콜에서 없앴습니다. SSL 2.0과 3.0은 이미 오래전에 폐기됐고, TLS 1.0과 1.1도 2021년부터 주요 브라우저가 지원을 끊었습니다. 그런데도 업계에서는 여전히 'SSL 인증서', 'SSL 종료'라는 표현을 관습적으로 씁니다. 실제로 돌아가는 프로토콜은 TLS인데 이름만 SSL이 남아 있는 셈입니다. 오늘날 HTTPS가 기본값이 된 것은 보안을 과하게 챙기기 때문이 아니라, 공개 네트워크에서 안전하지 않은 통신은 사실상 허용되기 어렵기 때문입니다.

TLS 연결은 먼저 핸드셰이크로 시작합니다. 클라이언트는 사용할 수 있는 암호화 방식들을 제안하고, 서버는 인증서를 보내 자신의 신원을 증명합니다. 클라이언트는 그 인증서가 신뢰할 수 있는 CA 체계 안에 있는지, 도메인 이름이 맞는지, 만료되지 않았는지를 검증합니다. 검증이 끝나면 양쪽은 안전한 방식으로 세션 키를 합의하고, 실제 데이터 전송은 공개키 암호보다 훨씬 빠른 대칭키 암호화로 처리합니다. TLS 1.3에서는 이 핸드셰이크가 1-RTT로 단축됐습니다. 이후 흐르는 모든 데이터는 암호화되고 무결성 보호까지 받기 때문에, 중간에서 패킷을 보더라도 내용을 읽거나 몰래 바꾸기가 어렵습니다.

가장 먼저 정리할 혼동은 SSL과 TLS의 관계입니다. SSL은 넷스케이프가 만든 원래 프로토콜이고, TLS는 IETF가 SSL 3.0을 기반으로 표준화하면서 붙인 새 이름입니다. 단순한 이름 변경이 아니라 핸드셰이크 구조와 암호화 방식이 달라졌고, SSL 2.0과 3.0은 보안 취약점 때문에 이미 폐기됐습니다. 지금 'SSL 인증서'나 'SSL 설정'이라고 부르는 것의 실체는 TLS입니다. 새로 구축하는 시스템에서 SSL을 선택할 이유는 없고, TLS 1.2 이상을 쓰는 것이 현재 기준입니다. TLS와 VPN은 둘 다 암호화를 사용하지만, 보호하는 범위와 문제 정의가 다릅니다. TLS는 하나의 애플리케이션 연결 단위로 보안을 제공하므로 브라우저와 웹 서버, 애플리케이션과 데이터베이스 사이 같은 개별 대화에 붙습니다. VPN은 네트워크 레벨에서 더 넓은 터널을 만들기 때문에, 그 터널을 지나는 여러 종류의 트래픽을 한꺼번에 감쌀 수 있습니다. 웹 서비스나 API처럼 특정 서비스 연결을 보호할 때는 TLS가 자연스럽고, 원격 근무자나 지사 연결처럼 네트워크 자체를 안전하게 잇는 문제에는 VPN이 더 어울립니다.

TLS는 웹사이트 로그인과 결제, 서비스 간 API 호출, 데이터베이스 연결, 메일 전송처럼 중간에서 노출되면 곤란한 통신에 적용됩니다. 외부 인터넷뿐 아니라 내부망에서도 서비스 수가 많아지고 경계가 흐려질수록 TLS를 기본으로 두는 편이 운영상 안전합니다. 다만 TLS를 붙이는 순간 끝나는 것이 아니라, 인증서 발급과 갱신, 종료 지점 관리, 구버전 프로토콜 차단 같은 운영 과제가 따라옵니다. 인증서 만료 하나만 놓쳐도 서비스 전체가 접속 오류로 보일 수 있으므로 자동 갱신 설정이 중요합니다. TLS를 제대로 쓴다는 것은 자물쇠 아이콘을 켜는 일이 아니라, 신뢰와 암호화를 서비스 운영의 일부로 다루는 일입니다.