TLS/SSL

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

인터넷이 상업화되기 전에는 네트워크 통신을 지금만큼 적대적인 환경으로 보지 않았습니다. 그러나 1990년대 중반 전자상거래가 확산되면서, 신용카드 번호와 계정 정보가 평문으로 흐르는 상황이 현실 문제로 떠올랐습니다. 넷스케이프가 1995년 SSL 2.0을 내놓은 것도 이 배경에서입니다. SSL에서 TLS로 발전한 과정은 단순한 버전업이 아니라, 취약한 암호 스위트와 느린 핸드셰이크, 불완전한 검증 체계를 계속 다듬어 온 역사였습니다. 오늘날 HTTPS가 기본값이 된 것은 보안을 과하게 챙기기 때문이 아니라, 공개 네트워크에서 안전하지 않은 통신은 사실상 허용되기 어렵기 때문입니다.

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

TLS와 VPN은 둘 다 암호화를 사용하지만, 보호하는 범위와 문제 정의가 다릅니다. TLS는 하나의 애플리케이션 연결 단위로 보안을 제공하므로 브라우저와 웹 서버, 애플리케이션과 데이터베이스 사이 같은 개별 대화에 붙습니다. VPN은 네트워크 레벨에서 더 넓은 터널을 만들기 때문에, 그 터널을 지나는 여러 종류의 트래픽을 한꺼번에 감쌀 수 있습니다. 웹 서비스나 API처럼 특정 서비스 연결을 보호할 때는 TLS가 자연스럽고, 원격 근무자나 지사 연결처럼 네트워크 자체를 안전하게 잇는 문제에는 VPN이 더 어울립니다. 하나는 연결 보안이고 다른 하나는 네트워크 경로 보안이라는 차이를 분명히 보는 편이 좋습니다.

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