[네트워크] TLS 암호화 및 인증 과정

TLS (Transport Layer Socket)

• 대칭 키 방식과 비대칭 키 방식을 혼용하여 사용한 암호화 방식
• TCP/IP 통신 시 보안을 제공하는 SSL이 표준화되어 바뀐 이름
• HTTPS에서 사용하는 보안 인증

 

TLS 암호화 방식

• 처음에 대칭키를 서로 공유하는 통신을 RSA 비대칭키 방식을 이용
• 실제 통신을 할 때 CPU 리소스 소모가 적은 대칭 키 방식으로 데이터를 주고받음

출처: https://babbab2.tistory.com/4

• 대칭 키를 안전하게 비대칭 키 암호화 방식으로 공유하고, 대칭 키를 안전하게 공유했으니 대칭 키로 암호화하여 통신
• 대칭 키 방식과 비대칭 키 방식의 단점을 보완함

 

인증서

• TLS 과정에서 서버와 통신을 할 때, 클라이언트가 서버의 신뢰성을 확인하는 작업
• 서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등), 서버 측 공개키(공개키, 공개키 암호화 방법), 서명값이 포함됨

tistory의 인증서

CA (Certificate Authority)

• 공개 키와 인증서를 함께 발급해주는 제3의 인증 기관 (신뢰성이 엄격하게 공인된 기업)
• 자체적으로 공개키와 비밀키를 가지고 있음
• CA가 발급한 인증서엔 서명 값(Signature)이 있어 클라이언트는 이 서명 값을 바탕으로 인증서를 검증함
  • 서명 값은 서버의 공개 키를 해시하여 CA의 개인 키로 암호화하여 만들어지며 이를 클라이언트에게 인증서와 함께 전송

출처: https://babbab2.tistory.com/5

 

인증서 체인 (Certificate Chain)

• 상위 인증 기관이 하위 인증서가 포함하고 있는 공개키(인증서)를 상위 기관의 비밀키로 암호화하여 상호 보증하게 되는 것
• 보통 3단계에 걸쳐서 일어나며 상위 인증기관이 없는 인증 기관은 Root CA라 불리며 Self-Signed 되어있음
  • CA 공인 인증 없이 Self-Signed 된 사설 인증서로 TLS 통신을 하는 사이트도 있음 ("신뢰할 수 없는 사이트입니다."의 예시임)

 

TLS 인증서로 서버를 인증하는 과정

• 인증서가 CA에서 발급받은 건지 조작된 건지 확인하는 과정이 필요함
• 클라이언트들은 CA 기관들의 공개키가 포함된 CA 리스트를 이미 소유하고 있음 (OS 설치 시 PC에 포함 or 브라우저가 포함)
• 클라이언트는 먼저 인증서가 자신이 가진 CA 리스트에 있는 기관에서 발급받은 것인지 확인함
• (1) 클라이언트는 서명 값과 인증서를 분리하고, 인증서 내용을 CA 기관의 공개키로 복호화함 (인증서 내용을 해시 처리한 값으로)
• (2) 인증서의 공개키를 해시한 값을 얻어냄
• (1)과 (2)를 비교하여 요청을 보낸 서버가 신뢰할 수 있는지 판별함

출처: https://babbab2.tistory.com/5

• 이러한 과정이 끝나면 클라이언트는 자신이 사용할 대칭 키를 서버의 공개 키로 암호화하여 서버로 보냄
• 서버는 자신의 개인 키로 이를 복호화하여 클라이언트의 대칭 키를 알아내어 이를 기반으로 통신함

이렇게 서버의 무결성을 확인하고 대칭 키를 전달하는 과정은 TLS Handshake(≠TCP 3-Way Handshake)를 통해 이루어짐