[WEB] SSL 통신

인증기관, 인증서, 암호화 키

Posted by Sol on May 25, 2021 · 4 mins read

SSL은 Secured Socket Layer의 약자로,

클라이언트와 서버가 보안이 향상된 통신을 하는 것을 의미한다.

기본적으로 HTTP 프로토콜은 HTML 문서를 주고받기 위한 프로토콜인데,

보안이 되지 않았기 때문에 해커가 중간에 문서를 가로채거나 데이터가 감청될 수 있다.

이를 보완하기 위해 넷스케이프사에서 최초로 도입된 기술이 바로 SSL이다.

어떻게 보안이 향상된 통신을 하는가?

지난포스팅에서 살펴본 암호화키를 활용한다.

비대칭키 방식은 통신을 할 때 암호화에 필요한 공개키와 복호화에 필요한 비공개키를 분리하여

공개키를 탈취당하더라도 데이터의 복호화를 불가능하게 하는 기술이다.

공개키와 비공개키가 항상 각각 암호화, 복호화에 사용되는 것이 아니다.

공개키가 복호화, 비공개키(개인키)가 암호화에 사용될 수도 있다(당연히).

SSL에서도 이 전략을 사용한다.

그러나 비대칭키 방식은 암호화 및 복호화에 컴퓨팅 리소스가 많이 소모되므로,

대칭키와 비대칭키 방식을 적절히 혼합하여 신뢰성을 보장하면서도 성능이 좋은 암호화를 만들어낼 필요가 있다.

그리고 그 전략이 SSL 통신에 녹아있다.


인증기관(CA)과 인증서

우선 SSL 통신에서 등장하는 인증기관에 대해 살펴보자.

통신을 할 때, 클라이언트는 서버를 어떻게 신뢰하는가?의 문제가 있다.

내가 지금 결제하려는 사이트가 진짜 사이트인지, 해커가 만들어낸 가짜 사이트인지 어떻게 판단할 수 있는가?

가짜 사이트에서 결제를 시도하면 내 결제 정보가 모두 노출되어 심각한 피해를 입을 수 있으므로,

클라이언트 입장에서는 해당 서버가 제대로 된 진짜 서버인지 판단해야만 한다.

그 판단을 도와주는 제3자가 바로 인증기관(Certificate Authority)이다.

어떤 웹사이트가 있을 때, 믿을만한 제3자가

“어 저 사이트는 믿어도 되는 사이트야.”

라고 인증해주면 클라이언트는 안심하고 서버에 접속할 수 있을 것이다.

‘이 사이트는 믿을만하다’고 증명해주는 것이 바로 인증서인데,

인증서는 서버가 CA에 요청하여 획득할 수 있으며, 인증서는 클라이언트 브라우저가 내장하고 있는 값들이다.

즉, 서버가 CA에 인증서를 요청하여 인증서 발급에 성공하면,

클라이언트는 브라우저에 내장된 인증서를 참고하여 내가 접속하려는 사이트가 안전한지 아닌지 판단하는 것이다.

인증서 발급 과정은 아래와 같다.


  1. 서버는 자신의 개인키와 공개키를 만든다.

  2. 서버가 인증기관에 웹사이트 정보와 공개키를 보내서 인증을 요청한다.

  3. 인증기관은 자신의 개인키와 공개키를 만든다.

  4. 인증기관은 서버가 보낸 정보를 검증하고 인증한다.

  5. 인증기관은 서버가 보낸 정보 및 공개키를 자신의 개인키로 암호화하여 인증서를 생성한다.

  6. 인증기관은 생성한 인증서를 서버에 발급한다.

  7. 인증기관은 클라이언트 브라우저에 자신의 공개키를 보낸다.

  8. 이로서 웹사이트는 자신의 개인키와 인증서를, 클라이언트 브라우저는 CA의 공개키를 갖게 되었다.

  9. 서버는 클라이언트의 최초 요청에 대해 발급받은 인증서를 함께 담아 응답한다(handshake).


SSL 통신과정

자, 인증기관이 인증서를 생성할 때 자신의 개인키로 암호화 하였고,

이 암호화 정보는 CA의 공개키로 복호화가 가능하다.

즉, 클라이언트가 서버에 접속할 때 서버가 보낸 인증서를 브라우저에 내장된 공개키로 복호화할 수 있다는 말이다.

만약 클라이언트가 CA의 공개키로 인증서를 복호화 할 수 없다면?

이 경우 해당 인증서는 CA가 발급한 것이 아니라는 의미이므로, 해당 클라이언트가 서버를 신뢰할 수 없다.

(사용자에게 경고창이 표시된다)

인증서의 암호화는 CA의 개인키로만 이루어지므로,

CA의 개인키를 보유하고 있지 않은 가짜 웹사이트는 인증서를 위조(암호화)할 수 없다!

이 부분에서 서버-클라이언트 간 신뢰가 구축된다. 다음 통신 과정은 아래와 같다.


  1. 인증서를 복호화한 결과로, 클라이언트는 서버가 보낸 정보와 서버의 공개키를 획득할 수 있다.

  2. 클라이언트는 서버의 공개키로 암호화한 대칭키를 서버에 보낸다.

  3. 해당 대칭키의 복호화서버의 개인키로만 가능하기 때문에, 중간에 탈취되어도 복호화가 불가능하다.

  4. 서버는 대칭키를 받아 본인의 개인키로 복호화하는데 성공하고, 대칭키를 얻게 된다.

  5. 결과적으로 클라이언트 - 서버는 대칭키를 확보하는데 성공하고, 향후 통신에 대칭키를 활용하게 된다.


조금 복잡하긴 하지만,

대칭키와 비대칭키, 암호화와 복호화의 개념을 알고나면 이해하기 어려운 내용은 아니다.

핵심은 두가지로,

제3자를 끌어들여 서버를 신뢰할 수 있는 장치를 마련함.

공개키와 비공개키를 혼합한 전략을 사용함.

을 잘 기억하면 되겠다.

참고로 해당 내용을 무려 만화!!로 굉장히 잘 설명해놓은 블로그가 있는데, 참고해보면 좋을 것 같다.

미닉스 김인성님 블로그(https://minix.tistory.com/)