쉬운 설명
TLS의 역할은 두 가지입니다. ① 서버가 진짜 그 서버임을 사용자에게 증명하기(인증서 검증), ② 통신을 도청·변조 못 하게 암호화하기. 옛 이름은 SSL이었지만 보안 문제로 SSL은 폐기됐고, 지금은 모두 TLS(현재 1.3 버전)를 씁니다. 이름만 다르고 같은 일을 한다고 봐도 됩니다.
동작은 핸드셰이크로 시작합니다. ① 브라우저와 서버가 사용할 암호 방식을 합의. ② 서버가 인증서를 제시(공인 인증기관 — Let's Encrypt·DigiCert 등이 발급). ③ 브라우저가 그 인증서가 신뢰할 만한 기관이 서명한 것인지 검증. ④ 안전한 통로의 키를 만들어 공유. 이 과정이 1~2 round-trip 안에 끝납니다. TLS 1.3에서는 더 빠르고 안전해졌습니다(0-RTT 모드 포함).
TLS는 HTTPS 외에도 어디든 깔 수 있습니다. SMTP·IMAP(이메일), gRPC·DB 연결(Postgres·MySQL), VPN(OpenVPN·WireGuard와 별개로 TLS 기반 VPN도 있음), 메시징·게임 서버까지. 자체 서비스 안에서 마이크로서비스 사이에 TLS를 끼우는 'mTLS(상호 TLS)'는 내부 통신에도 신원 확인을 더하는 방식으로 점점 표준이 되고 있습니다(제로 트러스트의 일부).
운영 측면의 핵심은 인증서 관리입니다. 인증서는 보통 1년 또는 그 이하로 만료되어 갱신이 필요합니다. 옛날엔 매년 사람이 갱신해야 했지만, Let's Encrypt + certbot이나 클라우드의 자동 갱신(AWS ACM·GCP Managed Certificates) 덕분에 이제는 거의 자동입니다. 인증서 만료가 사이트 다운으로 이어진 사고가 큰 회사에서도 종종 일어나는 만큼, 자동화가 필수입니다.
보안의 함정도 있습니다. 옛 TLS 버전(1.0·1.1)은 더 이상 안전하지 않으니 사용을 막아야 합니다. 약한 암호 스위트(weak cipher suites)도 비활성화해야 합니다. Mozilla SSL Configuration Generator 같은 도구가 권장 설정을 제공하니, 직접 정하지 말고 표준 권장을 따라가는 게 안전합니다.
비유로 보면
TLS는 외교 가방의 봉인과 같습니다. 봉인이 정품 표시로 잘 찍혀 있고(인증서) 그 안의 내용은 외부에서 볼 수 없도록 봉인됩니다(암호화). 도착지의 받는 사람만이 그 봉인을 풀어 안의 서류를 볼 수 있습니다.
어디에서 만나나
모든 HTTPS 웹 통신, 메일 서버 사이의 전송(SMTPS·STARTTLS), 모바일 앱과 백엔드 통신, DB 클라이언트-서버 통신, IoT 기기의 클라우드 통신, VPN·SSH의 일부, 마이크로서비스 사이의 mTLS. 현대 네트워크 보안의 거의 모든 곳에 깔려 있습니다.
작은 예시
은행 사이트를 열면 브라우저 주소창에 자물쇠 아이콘이 뜹니다. 그 아이콘은 'TLS 핸드셰이크가 성공했고, 신뢰할 만한 인증기관이 서명한 인증서로 서버 신원이 확인됐고, 이 통신은 암호화돼 있다'는 뜻입니다. 이 한 줄을 매번 자동으로 처리해 주는 게 TLS입니다.
자주 하는 오해
한 줄 정리
TLS의 가치는 '네트워크를 신뢰할 수 없다는 가정에서 출발해 안전을 만든다'에 있습니다. 자체 보호 없이는 모든 통신이 도청·변조에 노출됩니다.