TLS와 HTTPS의 작동 원리
TLS는 평문 HTTP에 암호화, 무결성, 인증을 더해 HTTPS를 구성하는 보안 계층이다. 이 스크립트는 핸드셰이크, 인증서 체인, TLS 1.3, SNI, mTLS, 종료 지점과 운영 장애 포인트를 연결해 설명한다.
Script Companion
오디오와 함께 스크립트 보기
- 01
TLS와 HTTPS는 브라우저의 자물쇠 아이콘 하나로 끝나는 주제가 아니다. 플랫폼 엔지니어는 ALB, Nginx, API Gateway 중 어디에서 TLS를 종료할지 정하고, 인증서를 자동 갱신하는 흐름까지 관리해야 한다. 실제 장애도 certificate expired, SSL handshake timeout, UNABLE_TO_VERIFY_LEAF_SIGNATURE 같은 TLS 설정 문제에서 자주 시작된다. 이 문서의 초점은 HTTPS가 도청을 막는다는 결론 뒤에 있는 핸드셰이크, 인증서 체인, 키 교환 메커니즘이다.
- 02
HTTP는 원래 TCP 위에서 평문으로 동작했고, 민감한 애플리케이션이 늘어나면서 채널 보안이 필요해졌다. RFC 2818의 관점에서 HTTP/TLS는 HTTP를 TLS 위에 올린 구조이며, 기본 포트는 443이고 서버 인증서의 신원을 호스트명과 대조해야 중간자 공격을 막을 수 있다. 여기서 TLS가 붙이는 기능은 세 가지다. HTTP 바이트를 암호화하고 무결성을 확인하며, 인증서 체인과 SAN 검증으로 접속한 호스트가 맞는지 확인한다.
- 03
TLS는 비대칭키와 대칭키를 목적에 따라 나누어 쓴다. 비대칭키는 사전에 같은 키를 공유하지 않아도 되는 대신 느리고, 대칭키는 같은 키로 잠그고 여는 방식이라 빠르지만 처음에 안전하게 전달해야 한다. 그래서 TLS는 핸드셰이크에서 ECDHE 같은 임시 키 교환으로 세션 키를 만들고, 실제 HTTP 요청과 응답은 협상된 대칭키로 처리한다. 비대칭키 연산은 CPU 비용이 대칭키보다 1000배 이상 높다는 점 때문에 이 역할 분리가 중요하다.
- 04
인증서 체인은 서버 신원을 확인하는 신뢰 경로다. Root CA는 운영체제나 브라우저에 내장된 신뢰의 출발점이고, Intermediate CA는 실제 온라인 발급 과정에서 Leaf Certificate에 서명한다. Root CA의 개인키가 유출되면 인터넷 전체의 신뢰 체계가 흔들리므로, Root CA는 오프라인 HSM에 보관하고 Intermediate CA만 온라인에 노출한다. 브라우저는 체인을 따라 issuer와 subject가 이어지는지 보고, 현대 브라우저는 CN보다 SAN을 기준으로 호스트명을 검증한다.
- 05
TLS 1.2와 TLS 1.3의 큰 차이는 핸드셰이크 왕복 횟수와 보안 기본값이다. TLS 1.2는 실제 HTTP 요청 전에 2 RTT가 필요하지만, TLS 1.3은 2018년 RFC 8446으로 표준화되면서 1 RTT를 기본으로 하고 Forward Secrecy를 강제화했다. 운영 기본값은 TLS 1.3 우선, TLS 1.2 호환 유지, TLS 1.0과 1.1 비활성화다. 다만 TLS 1.2를 성급히 버리면 구형 OS, 라이브러리, 내부 배치, 파트너 API가 조용히 실패할 수 있다.
- 06
0-RTT, 즉 Early Data는 재연결 때 ClientHello와 함께 HTTP 요청 데이터를 바로 보내 성능을 높이는 기능이다. 그러나 RFC 8446은 이 방식에서 Forward Secrecy가 보장되지 않고 Replay Attack 위험이 있다고 설명한다. 판단은 HTTP 메서드만으로 끝나지 않는다. RFC 8470은 safe method라도 리소스별 side effect가 있을 수 있으므로 origin이 early data 허용 여부를 명시적으로 판단해야 한다고 본다. 위험한 요청은 Early-Data: 1로 전달하거나 425 Too Early로 재시도시키는 식의 경계가 필요하다.
- 07
SNI는 하나의 IP 주소에 여러 도메인을 올릴 때 필요한 힌트다. 서버는 TLS 핸드셰이크 초기에 클라이언트가 어느 도메인으로 접속하려는지 알아야 알맞은 인증서를 선택할 수 있는데, IP만으로는 그 정보를 알 수 없다. 그래서 SNI는 ClientHello에 목적지 호스트명을 포함한다. ALB에서 여러 Target Group을 도메인별로 라우팅할 때도 이 정보로 인증서를 고르고 리스너 규칙을 적용한다. SNI가 빠지거나 맞지 않으면 잘못된 인증서나 HANDSHAKE_FAILURE로 이어질 수 있다.
- 08
mTLS는 기본 TLS가 서버만 인증하는 구조를 넘어, 클라이언트도 인증서로 자신을 증명하게 만든다. Kubernetes 환경의 서비스 메시, Istio와 Envoy 사이드카 패턴은 이런 서비스 간 인증을 이해해야 설계할 수 있다. 내부 서비스 간 통신에서 JWT 토큰 방식 대신 mTLS를 쓰면 네트워크 레이어에서 인증이 끝나므로 애플리케이션 코드의 인증 로직을 줄일 수 있다. 반대로 ALB에서 mutual-authentication Mode=verify가 켜졌는데 클라이언트 인증서가 없거나 TrustStore에 없는 CA가 서명했다면 403 Forbidden이 발생할 수 있다.
- 09
운영에서 중요한 선택은 TLS Termination, 즉 어디서 HTTPS 트래픽을 복호화할지다. ALB에서 종료하는 방식이 일반적이고, 필요한 경우 종단간 암호화나 Nginx 종료를 선택한다. 인증서 관리는 AWS ACM과 Let’s Encrypt가 대표적이다. ACM의 DNS 검증 인증서는 만료 45일 전에 연결된 AWS 서비스와 CNAME 조회 가능 여부를 확인하고, 실패 이벤트는 30일, 15일, 7일, 3일, 1일 전에 전달된다. 정리하면 TLS는 비대칭키로 세션 키를 교환하고, 대칭키로 데이터를 보호하며, X.509 인증서 체인으로 서버 신원을 검증하는 프로토콜이다.
같은 레이어
L7에서 이어 듣기
- 오디오 파일
- /podcasts/l7-tls-https.mp3