TLS통신과 공인인증서에 대한 정리를 위함.
TLS(Transport Layer Security)는 전송계층보안으로 브라우저와 같은 웹 응용 프로그램과 서버 간의 통신을 암호화하는 것입니다.
이 과정에서 데이터를 숨기고(암호화), 데이터를 교환할 때 수신측에 송신측의 신분을 보장해야(인증), 데이터의 위변조(무결성)를 확인합니다.
TLS 통신에는 크게 세가지를 확인해야합니다.
먼저 각 요소에 대해 간단히 알아보겠습니다.
전송자가 데이터를 A라는 키를 이용해 암호화하여 수신자에게 전송하면 수신자는 같은 A라는 키를 이용해 전달 받은 데이터를 복호화합니다.
이때 암호화/복호화 과정에서 사용하는 A라는 키를 '대칭키' 라고 합니다.
대칭키 암호화 방식은 보안에 취약한데, 대칭키를 전달하는 과정에서 대칭키가 노출될 가능성이 크고 노출된 대칭키로 제3자가 데이터를 복호화할 수 있는 문제가 생깁니다.
비대칭키 암호화 방식은 대칭키 암호화 방식과 다르게 한쌍의 키를 갖습니다.
전송자가 데이터를 B라는 키를 이용해 암호화하여 수신자에게 전송하면 수신자는 b라는 키를 이용해 전달 받은 데이터를 복호화합니다.
이때 B라는 키로 암호화한 데이터는 b라는 키로만 복호화가 가능합니다. 또한 b키로 암호화한 데이터는 B키로만 복호화가 가능합니다.
B와 b는 한쌍으로 하나는 'Public-key(공개키)', 다른 하나는 'Private-key(개인키)'라고 합니다.
이렇게 한 쌍의 키로 암호화, 복호화를 하는 방식을 RSA 알고리즘 이라고 합니다.
접속하려는 서버가 신뢰할 수 있는 진짜 서버임을 확인하기 위해 공인인증서가 사용됩니다.
CA(Certificate Authority)로부터 발급 받을 수 있고, 공인인증서는 다음과 같은 정보들을 포함합니다.
서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등)
서버 측 공개키(공개키, 공개키 암호화 방법)
지문, 디지털 서명 등
위 그림과 같이 모든 브라우저(chrome, edge, safari...)는 CA들의 public-key를 제공을 받아 가지고 있습니다.
이제 이 그림을 시작으로 통신 절차를 알아보겠습니다.
서버를 운영하는 회사에서 도메인과 공개키를 CA에 제출하여 인증서 발급을 요청합니다.
CA에서 CSR을 요청한 회사에 대한 검증 과정을 거칩니다.
CA에서 검증 과정을 마치고 sign을 한 공인인증서를 발급해줍니다.
여기까지는 Client와 서버가 TLS통신을 하기 위해 CA와 서버간의 공인인증서 발급 절차를 알아보았습니다.
이제 실제 Client와 서버간의 TLS 통신절차에 대해 알아보겠습니다.
Client는 https를 이용해 서버에 접근합니다.
서버쪽에서 Private-key의 쌍인 Public-key를 생성합니다.
Client는 서버로부터 Public-key와 공인인증서를 받습니다.
Client의 브라우저에 저장된 CA Public-key를 사용하여 전달받은 공인인증서가 CA로 부터 발급받은 유효한 인증서인지 체크합니다.
이 과정을 통해 통신하려는 사이트가 가짜 사이트인지 확인 할 수 있습니다.
공인인증서 체크가 끝나면 서버와의 암호화 통신을 위해 Client의 대칭키를 서버로부터 제공받은 Public-key를 사용하여 암호화합니다.
Client는 암호화한 대칭키를 서버로 보냅니다. 이때 전송하는 대칭키는 서버의 Public-key로 암호화하였기 때문에 서버의 Private-key로만 복호화가 가능합니다.
따라서 해당 과정에서 암호화된 대칭키가 유출되어도 복호화가 불가능하기 때문에(Private-key가 유출되지 않았다면) 안전하게 전송이 가능합니다.
서버는 전달받은 암호화된 대칭키를 Private-key를 사용하여 복호화합니다.
이제 Client와 서버가 모두 동일한 대칭키를 안전하게 갖게 되었습니다.
해당 대칭키는 Client와 서버만 갖고 있기 때문에 서로간 암호화 된 통신이 가능하게 됩니다.
TLS 통신에 대해 정리해보았습니다. 다음에는 K8s에서의 TLS 통신에 대해 포스팅 할 예정입니다.
[K8s에서의 TLS통신]