TLS, Let's encrypt 와 cert-manager

저번 프로젝트를 진행할때 cert-manager와 Let's encrypt를 썼었다. 

HTTPS를 위해 꼭 필요한 SSL/TLS에 대해 일단 알아보자.

 

SSL/TLS

• 우선 SSL(Secure Sockets Layer)를 업그레이드 한것이 TLS(Transport Layer Security)이다. (무려 1999년에)
• 모두 client와 서버간 암호화를 위해 만들어진 통신 프로토콜이다. 
• HTTPS의 S도 이 TLS를 이용해 Secure 한다는 뜻이다. 
• SSL은 현재 쓰이지 않고 TLS를 쓰지만 관용적으로 그냥 TLS 대신 SSL라고 부르기도 한다.
• (현실에서 SSL를 거의 TLS 의미로 계속 쓰고 있는 듯 하다)

 

TLS Handshake, 인증서

TLS 암호화 통신을 하려면

↓

TLS Handshake 필요하고

↓

TLS Handshake에서 서버 인증 필요한데

↓

그래서 인증서 필요하다

 

TLS Handshake는 다음과 같이 이루어진다. 

 

1. 클라이언트 Hello - (실제로 hello 이렇게 보낸다. ㅋㅋㅋ)

• 이때 TLS 버전, 무작위 바이트 문자열(랜덤값), 그리고 클라이언트가 지원하는 암호화 스위트 목록을 보낸다.

2. 서버 hello 

• 이때 바로 인증서와 서버가 선택한 암호화 스위트, 서버가 생성한 무작위 바이트 문자열(랜덤값)을 보낸다.

3. 키 교환 

• 클라이언트는 서버의 인증서를 검토해 신뢰하는 CA(certificate authority)인지, 도메인의 소유자가 맞는지 확인한다. 
• 확인 후 클라이언트, 서버 각자 랜덤값과 교환된 키 값을 이용해 세션 키를 생성한다.

4. 클라이언트에서 'Cipher Spec'를 전송하고 이후로는 암호화 하여 통신된다.

(제가 한번 캡처해 봤습니다.)

 

 

인증서 발급 수단

자 그러면 이제 인증서를 발급 받는 수단에 대해서 정리해보자.

 

우선 개인이 가장 쓰기 만만한 것이 Let's encrypt이다. 

특징으로는 

• 무료다.
• 유효기한이 90일이다.
• Domain Validation만 지원한다. (즉, 도메인을 소유하고 있는지만 체크하고, 실제 기업인지 이런것들은 확인하지 않는다)

 

우선 본인 도메인을 사서 서버에서 직접 발급을 받아야 하는데 단점이 아까 특징에서 보이다시피 유효기간이 90일이라 계속 갱신해줘야한다. 

 

그래서 사용하는 것이 certbot 또는 쿠버네티스 환경에서는 cert-manager이다. 

 

이전 프로젝트에서 실수했던 점이 쿠버네티스 환경인데 certbot을 사용해 인증서를 발급받고 secret으로 등록해서 90일 후에 재갱신해야하는 비효율적인 설계를 했었다. (완전 바보)

 

일반 서버 환경에서는 certbot을 사용해 자동 재갱신을 하도록 할 수 있고, 

쿠버네티스에서는 cert-manager를 통해 알아서 관리하도록 할 수 있다. 

 

따라서 정리하면 Let's encrypt는 인증서를 발급하는 기관이라고 보면 되고,

 

cert-manager는

인증서의 기한이 만료되지 않도록 관리하고

인증서를 새로 발급 받고

kubenetes secret에 등록하며

 

여러가지 일을 하는 전담 직원이라고 보면 좋을거 같다. 

 

 

 

 

 

 

참고 자료:

https://docs.tosspayments.com/resources/glossary/tls

https://aws.amazon.com/ko/compare/the-difference-between-ssl-and-tls/