Post

Kubernetes 환경에서 TLS 인증서 적용하기 - (1)

Posted Updated
Preview Image
By KKamJi
views 9 min read
Kubernetes 환경에서 TLS 인증서 적용하기 - (1)

현대 어플리케이션 운영에 있어 보안은 매우 중요합니다. 인터넷을 통한 데이터 전송이 증가함에 따라, 개인 정보와 민감한 데이터가 노출될 위험도 커지고 있습니다. 이러한 위험을 방지하기 위해 데이터 전송 과정에서의 암호화는 필수적입니다. 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: SYN TCP 연결을 시작합니다.
SYN ACK
Server -> Client: SYN ACK 서버가 연결 요청과 자신의 sequence를 확인합니다.
ACK
Client -> Server: ACK 양쪽 TCP 상태가 연결됩니다.
TLS handshake
Client -> Server: ClientHello 지원 버전, cipher와 client random을 제안합니다.
서버 협상 정보
Server -> Client: ServerHello 선택한 알고리즘과 server random을 응답합니다.
Certificate
Server -> Client: Certificate and ServerHelloDone Certificate 뒤에 필요한 경우 ServerKeyExchange, CertificateRequest를 보내고 ServerHelloDone으로 마칩니다.
인증서 검증과 키 교환
Client: server certificate validation client가 CA chain과 hostname을 확인합니다. CertificateRequest를 받았다면 ClientKeyExchange 전에 client Certificate를 보냅니다.
검증 통과
Client -> Server: ClientKeyExchange 선택한 방식의 키 교환 입력을 전달합니다. client 인증에 필요한 CertificateVerify는 이 메시지 뒤, ChangeCipherSpec 전에 보냅니다.
session key 준비
Client and Server: session key 양쪽이 같은 대칭 키를 계산합니다.
암호화 모드 전환과 검증
Client -> Server: ChangeCipherSpec and Finished 클라이언트가 암호화 전환과 handshake 검증을 알립니다.
서버 확인
Server -> Client: ChangeCipherSpec and Finished 서버도 전환을 확인하고 handshake를 완료합니다.
Encrypted application traffic
Client <-> Server: encrypted data session key를 사용한 기밀성과 무결성 통신을 시작합니다.

PNG 다운로드 원본 이미지 열기

Cloudflare TLS Handshake 참고자료

  1. Client Hello

    클라이언트가 서버에 연결 요청을 보내 핸드셰이크를 시작

  2. Server Hello

    서버가 클라이언트의 요청에 응답하고 필요한 정보를 전송

  3. 서버 인증 및 키 교환 준비

    클라이언트 인증서 검증

    • 클라이언트가 서버의 디지털 인증서를 확인하여 서버의 신원을 검증
    • 인증 기관(CA)을 통해 인증서의 유효성 확인 키 교환 준비(Optional)
    • 필요 여부에 따라 키 교환을 위한 추가 정보 전송

  4. 클라이언트 키 교환 (Client Key Exchange)

    예비 마스터 시크릿 생성 및 전송

    • 클라이언트가 예비 마스터 시크릿이라는 무작위 바이트 문자열 생성
    • 서버의 공개 키로 암호화된 예비 마스터 시크릿 전송

  5. 세션 키 생성

    서버에서 예비 마스터 시크릿 복호화

    • 서버가 소유하고 있는 개인 키로 클라이언트가 보낸 예비 마스터 시크릿 복호화 세션 키 계산
    • 클라이언트와 서버는 클라이언트 랜덤 값, 서버 랜덤 값, 예비 마스터 시크릿을 사용하여 동일한 세션 키 생성

  6. 변경 암호 명령 (Change Cipher Spec)

    암호화 모드 전환

    • 클라이언트와 서버가 이후 통신에서 사용할 암호화 알고리즘과 세션 키 적용 알림 전송
    • 클라이언트와 서버가 각각 Change Cipher Spec 메시지를 보내 암호화 설정 변경을 알립니다.

  7. Handshake 완료

    인증 완료 메시지 전송

    • 클라이언트와 서버가 세션 키로 암호화된 Finished 메시지 교환
    • Handshake 과정이 성공적으로 완료되었음을 확인

  8. 통신 시작

    암호화된 데이터 교환

    • Handshake가 완료되면, 세션 키를 사용하여 암호화된 데이터를 전송 보안 통신 수립
    • 클라이언트와 서버 간 안전한 대칭 암호화 통신 시작

3. Reference

궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi

Kubernetes, Networking
kubernetes harbor jenkins tls ssl cert-manager ingress-controller
This post is licensed under CC BY 4.0 by the author.