현대 어플리케이션 운영에 있어 보안은 매우 중요합니다. 인터넷을 통한 데이터 전송이 증가함에 따라, 개인 정보와 민감한 데이터가 노출될 위험도 커지고 있습니다. 이러한 위험을 방지하기 위해 데이터 전송 과정에서의 암호화는 필수적입니다. TLS(Transport Layer Security) 인증서의 적용은 이러한 보안을 강화하는 핵심 요소입니다.
TLS는 애플리케이션과 사용자의 통신을 암호화하여 중간자 공격, 도청, 데이터 위변조 등의 위협으로부터 보호합니다. 특히 Kubernetes 환경에서는 다양한 서비스들이 네트워크를 통해 상호 작용하므로, TLS 인증서의 적용이 더욱 필수적입니다.
인증서를 붙이는 절차 자체는 cert-manager가 대신해 주지만, 발급이 실패하거나 브라우저가 경고를 띄울 때 어느 단계에서 막혔는지 읽으려면 handshake가 어떤 순서로 진행되는지 알아야 합니다. TLS의 개념과 인증 과정을 먼저 정리합니다.
TL;DR
TLS는 SSL의 취약점을 개선한 후속 프로토콜입니다. SSL은 POODLE과 downgrade attack 등으로 더 이상 사용되지 않습니다.
TLS Handshake는 Client Hello와 Server Hello로 시작해 서버 인증과 키 교환을 거쳐 세션 키를 만들고, Change Cipher Spec 이후 실제 통신으로 넘어갑니다.
1. TLS(Transport Layer Security) 개념
TLS(Transport Layer Security)란 SSL(Secure Socket Layer)의 보안 취약점을 개선하고 더 강력한 암호화 알고리즘을 도입한 후속 버전으로, 인터넷에서 안전한 통신을 제공하기 위한 암호화 프로토콜입니다.
TLS는 클라이언트와 서버 간의 데이터 전송 시 보안을 강화하여 데이터의 기밀성, 무결성, 그리고 인증을 제공합니다. 이를 통해 중간자 공격, 도청, 데이터 위변조 등의 보안 위협으로부터 보호할 수 있습니다.
SSL은 POODLE(Padding Oracle On Downgraded Legacy Encryption) Attack, Downgrade Attack, 암호화 및 해시 알고리즘 취약점 문제 등과 같은 보안 취약점으로 인해 더 이상 사용되지 않으며, 현재 TLS가 SSL을 대체하고 있습니다.
2. TLS 인증 과정
TLS는 클라이언트와 서버 간의 통신 세션을 수립하기 위해 Handshake 과정을 거칩니다. 쉬운 이해를 위해 TLS Handshake 과정에 대해 이미지를 첨부하겠습니다. 아래 그림과 같습니다.
TLS 1.2 서버 인증서 기반 전체 핸드셰이크
서버 인증서 기반 TLS 1.2 예시입니다. 키 교환 방식과 client 인증 요청에 따라 선택 메시지가 달라집니다. TLS 1.3의 순서와는 다릅니다.
TCP connection setup
Client -> Server: SYNTCP 연결을 시작합니다.
SYN ACK
Server -> Client: SYN ACK서버가 연결 요청과 자신의 sequence를 확인합니다.
