[2] HTTPS 프로토콜 쉽게 이해하기 - 인증서의 개념

https://akira6036.tistory.com/68

[1] HTTPS 프로토콜 쉽게 이해하기 - 대칭 키와 비대칭 키

 

 안녕하세요, 

 이 포스팅을 통해서 HTTPS의 동작 원리를 이해하기 위한 필수적인 개념 두 번째,

 인증서(Certificate)에 대하여 이해해 보는 시간을 가지도록 하겠습니다.

 

 오늘의 포스팅을 이해하기 위해서는

 대칭 키와 공개 키 암호화 시스템에 대한 이해가 필수적입니다.

 관련 내용을 아직 들어보지 않으셔다면,

 위 URL에 들어가셔서 학습을 하신 후에 이 글을 참고하시는 것을 추천 드립니다!

 

 인증서(Certificate)의 필요성

 지난 시간에,

 클라이언트가 전송하고자 하는 데이터를 왜 암호화해서 서버로 보내는 지

 그 이유에 대하여 설명하였습니다.

 

 하지만, 우리가 너무도 당연하게 생각하고 있느라 놓치고 있는,

 보안에 있어서 더 중요한 사항이 있습니다.

 

 바로 신뢰할 수 있는 서버와 소통을 하는 것 입니다.

 

 우리가 통신하고 있는 서버가, 

 해커가 클라이언트의 정보를 탈취할 목적으로 개설된 것이라면

 중요한 정보를 빼앗길 수밖에 없을 것입니다.

 

그러면, 클라이언트 측에서는

 자신이 요청하고 있는 서버를 신뢰할 수 있는 지, 아닌 지 그 여부를 어떻게 결정할 수가 있을까요?

 바로 다음과 같이 하면 될까요?

서버가 직접, 자신이 믿을만한 서버라는 것을 클라이언트에게 이야기함

 

 위 그림에서는,

 서버가 클라이언트에게 "나는 믿을만한 서버야"라고 이야기하고 있습니다.

 

 클라이언트는 이 말을 믿을 수 있을까요? 

 당연히 아닙니다.

 

 올바른 서버뿐 아니라,

 해커가 클라이언트의 정보를 탈취하기 위해 개설한 악성 서버들도

 바로 위와 같은 행위를 얼마든지 해낼 수 있습니다.

 

 만약 "나는 신뢰할 수 있는 서버야"라고 말하는 서버가,

 실제로는 악성 해커가 만든 서버였다면

 클라이언트는 어떻게 될까요?

 

 그러면 다시 본론으로 되돌아와서,

 클라이언트는 특정 서버가 공신력이 있는 지 아닌 지 어떻게 판단할 수 있을까요?

 그것은 바로,

 신뢰를 보장할 수 있는 제 3자를 사전에 정해 놓고,

 이 제 3자에 의하여 "인정받는"서버들만 "신뢰성이 있다"라고 판단하는 방법입니다.

 

 

공신력 있는 기관에서 인증한 서버라면 믿을만 하다.

 

 자타공인 "신뢰성이 있다"라고 인정받는 공신력이 있는 기관들이,

 "이 서버는 믿을 만 한 서버입니다. 믿어도 됩니다."라고 보장한다면,

 우리는 그 서버를 믿어도 됩니다.

 

 바로 우리 클라이언트들에게,

 어떤 서버가 믿을 만한 서버인지 알려 줌으로써

 신뢰할 수 있는 대상을 판단할 수 있는 시스템.

 

 그런 개념으로 부터 나온 것이 바로,

 그 유명한 인증서(Certificate)의 개념이랍니다.

 

인증 기관(Certificate Authority)과 인증서(Certificate) 부여

 

 공신력이 있는 기관에서, 어떤 서버가 "믿을만 하다"라고 인정을 해 주면,

 우리(클라이언트)들은 또한 그 서버를 신뢰할 수 있게 된다.

 

 

 여기서 바로 , 공신력이 있는 기관은 인증 기관(Certificate Authority)를 의미하며,

 "믿을만 하다"라고 인정을 해 주는 것이 바로, 인증서(Certificate) 부여 입니다.

 

 예를 들어 제가 쇼핑몰을 하나 구축했다고 해 보겠습니다.

 그런데 처음 제 쇼핑몰 서버에 접속하는 클라이언트들은

 당연히 제가 "믿을만한 서버인 지" 모르기 때문에, 신뢰할 수가 없습니다.

 

 그래서 저는 대표적인 인증기관인 Comodo를 찾아가서 다음과 같이 말을 합니다.

 

 

 "제가 쇼핑몰을 하나 구축했어요.

 저희 쇼핑몰이 믿을만한 서버라는 것을 당신에게 인정받고 싶습니다."

 

 

 그러면 저는 이 Comodo에서 요구하는,

 "신뢰성이 있는 서버로 인정받기 위해 필요한 일련의 서류"들을 제출하고

 서비스 이용료를 지불하고,

 여러가지 약관에 동의하고 나면 비로소

 다음과 같이 인증서를 부여받을 것입니다.

 

인증서를 부여받고, 드디어 신뢰성이 생긴 나의 서버

 

 저희 쇼핑몰 서버는 이제, 공신력있는 기관으로부터 인증서를 발급받고,

 여러 클라이언트들에게 "믿을 만한 서버구나"라고 인증받을 수 있는 발판을 마련하게 됩니다.

 

 나에게 무언가를 요청하는 클라이언트에게

 방금 comodo로부터 발급받은 인증서를 보여주면

 "아, 이 쇼핑몰 서버는 comodo로부터 인증서를 부여받은 신뢰 가능한 서버구나!"라고 알 수 있게 되는 것입니다.

 

이 인증서, 진짜 맞아?

 지금까지의 논리를 간단하게 정리를 해 보자면 다음과 같습니다.

 

 

 "공신력있는 인증서 발급 기관(CA)로부터 인증서를 발급받고,

 이걸 클라이언트에게 보여주면, 클라이언트는 서버를 신뢰할 수 있게 된다."

 

 

 그런데 클라이언트 입장에서는

 한 가지 꺼림칙한 게 있습니다.

 바로 다음과 같은 가능성입니다.

 

 

"서버가 보여주는 이 인증서, 진짜로 comodo한테서 발급받은 거 맞아?

 너가 조작해서, 그럴듯하게 만들어낸 것 아니야?"

 

 

 

서버가 보여주는 인증서를 믿지 못하는 의심 많은 클라이언트

 

 (당연히 이 정도 의심은 있어야 정글같은 야생에서 살아남을 수가 있는 것 같습니다)

 

클라이언트는, 서버가 보여준 인증서가 정말로,

공신력있는 기관에서 발급받은 정식 인증서인지 판단을 해야 합니다.

그렇지 않으면 서버를 신뢰할 수가 없습니다.

 

 그렇다면 클라이언트는,

 서버가 나에게 보여준 인증서가 정식 인증서인지,

 도대체 어떻게 판단할 수 있을까요?

 

 바로 공개 키 암호화 시스템(Public Key Encryption System)이 이용해서 이러한 과정을 수행한답니다.

 결론부터 말씀드리지 않고,

 찬찬히 살펴보겠습니다.

 

 사실 공신력 있는 인증기관 comodo에서 서버들에게 발급하는 인증서는 다음과 같이, 

 해당 인증기관에서 가지고 있는 개인 키(Private Key)로 암호화 된 인증서입니다.

 

CA에서 발급받은 인증서는, CA의 개인 키로 암호화 된 인증서이다

 

  CA만이 가지고 있는 개인키(절대 노출된 적이 없는)를 이용해

  인증서의 본문을 암호화시킨 후에

  서버로 전달을 하게 되는 것입니다.

 

 아까, 서버는 클라이언트의 요청이 올 때마다 

 다음과 같이 클라이언트에게 인증서를 보여준다고 하였죠?

 

서버가 보여주는 인증서를 믿지 못하는 의심 많은 클라이언트

 

 이 과정에서 클라이언트는, 

 이 인증서가 진짜 comodo로부터 발급받은 인증서인지 판단하는 작업을 합니다.

 

 클라이언트의 브라우저의 소스코드에는

 인증기관 별 공개 키가 포함되어 있습니다.

 즉, comodo라는 인증기관에 해당하는 공개 키도 포함이 되어 있을 것입니다.

 

 클라이언트는, 

 다음과 같이 말하며 이 인증서의 복호화를 시도합니다.

 

 "이 인증서는 comodo로부터 발급받은 것이라고 했지?

 그러면 이 본문은 comodo의 private key로 암호화가 되어 있겠구나.

 comodo의 private key로 암호화 된 암호문은 오로지,

 comodo의 public key로만 복호화가 될 수 있으니까

 내가 가진 comodo public key로 복호화가 성공한다면 이 인증서는 진짜 인증서다." 

 

 

 이렇게 해서 복호화에 성공하게 되면,

 이 인증서가 진짜 comodo에서 발급 받은 것임을 확인할 수 있게 되는 것입니다.

 

 

정리

이상 오늘의 포스팅을 통하여 인증서에 대해 알아보았습니다.

 

 인증서라는 것은 서버가 클라이언트에게 "나는 믿을만한 서버다"라는 것을 알려주는 수단이며

 클라이언트는 이 인증서가 진짜 믿을만한 것인지 확인하기 위해

 인증서의 발급 기관용 public key를 이용해 복호화를 합니다.

 

여기까지 이해하셨다면, 

HTTPS의 동작과정을 이해할 수 있는 기반이 갖춰진 것입니다.

다음 포스팅을 통하여 우리의 최종 목적,

HTTPS 프로토콜의 동작 과정에 대하여 알아보도록 하겠습니다.