TLS는 신뢰할 수 없는 네트워크에서도 통신 내용을 보호하도록 설계된 프로토콜이다. 데이터 암호화, 전송 중 변경 탐지, 상대방 인증을 제공한다. HTTP에 TLS를 적용한 대표적인 사용 방식이 HTTPS다. MDN TLS 문서
핸드셰이크가 하는 일
연결 초기에 양쪽은 사용할 프로토콜과 암호 알고리즘 등을 협의하고, 통신에 사용할 키를 설정한다. 웹에서는 보통 서버가 인증서를 제시해 자신의 신원을 증명한다. 브라우저는 접속 대상과 인증서의 관계를 확인한다. 모든 연결이 클라이언트 인증서까지 요구하는 것은 아니다. TLS 1.3 표준
인증과 암호화의 차이
암호화는 내용이 노출되지 않도록 보호하고, 인증은 누구와 통신하는지 확인하는 기능이다. 인증서 검증을 끄면 암호화된 연결이 성립하더라도 의도한 서버에 접속했다고 신뢰하기 어려워진다. 인증서 오류를 단순히 무시하는 방식은 정상적인 문제 해결이 아니다.
| 점검 대상 | 의미 |
|---|---|
| 호스트 이름 | 인증서가 요청 대상에 맞는지 |
| 유효 기간 | 사용할 수 있는 기간인지 |
| 신뢰 관계 | 클라이언트가 인증서를 검증할 수 있는지 |
예를 들어 테스트용 호스트의 인증서를 운영 도메인에 적용하면 이름 검증에서 문제가 생길 수 있다. 주소와 인증서 설정을 함께 확인해야 한다.
프록시가 있는 구조
리버스 프록시에서 TLS를 종료하면 브라우저와 프록시 사이의 연결은 그 지점에서 끝난다. 프록시가 뒤쪽 서버에 다시 암호화 연결을 맺는지, 내부 평문으로 전달하는지는 별도 설정이다. 따라서 구조도를 그릴 때 각 통신 구간의 보호 여부를 따로 표시하는 편이 명확하다.
보호 범위의 한계
TLS는 이미 서버에 도착한 데이터의 저장 정책이나 서비스의 권한 검사를 대신하지 않는다. 암호화된 요청도 잘못된 사용자에게 허용될 수 있으므로 로그인, 접근 제어, 비밀값 관리가 함께 필요하다. 통신 보호와 애플리케이션 보안을 같은 의미로 사용하지 않는 것이 중요하다.