HTTPS 통신 간단 정리 (비대칭키, SSL 인증서 개념)

HTTP vs. HTTPS

HTTP(HyperText Transfer Protocol)는 HTML(일반적인 웹사이트 문서)와 같은 하이퍼미디어를 전송하기 위한 통신규약(Protocol)을 의미한다. 이를 통해 크롬과 같은 웹브라우저가 웹서버와 통신한다. HTTPS(HTTP over Secure Socket Layer)는 이름에서 알 수 있듯이 HTTP 통신에 보안(Secure) 기능이 추가된 통신규약이다.

 

Fig 1. HTTP와 HTTPS의 차이

 

Fig 1.은 HTTP 통신과 HTTPS 통신의 차이를 보여주는 그림이다. 컴퓨터1과 웹서버1 사이에는 HTTP 통신을, 컴퓨터2와 웹서버2 사이에는 HTTPS 통신을 한다. 컴퓨터에서 웹서버로 비밀번호를 전달해야 하는 경우가 있다고 하자. HTTP 통신은 비밀번호를 어떠한 암호화 없이 그대로 웹서버로 전송한다. 웹서버로 전송되는 과정에서 해커에 의해 비밀번호가 탈취될 위험이 존재하게 된다.

 

그에 비해 HTTPS는 비밀번호를 암호화한 암호문을 전달한다. 전송되는 과정에서 여전히 해커에 의해 암호문이 탈취될 가능성이 있지만, 암호문인 만큼 해독(복호화)하지 못한다면 비밀번호를 알아낼 수 없다. 이처럼 HTTPS 통신은 사용자의 민감정보를 인터넷상에서 전송할 때 이를 암호화하는 프로토콜이다.

 

HTTPS는 HTTP에 SSL(Secure Socket Layer) 프로토콜을 사용하여 암호화를 수행한다. SSL은 이후 TLS로 업데이트되었으며, 둘은 보안이라는 같은 목적으로 사용되는 프로토콜이기에 전문가가 아닌 경우 용어를 혼용해서 사용하기도 한다.

 

 

 

HTTPS의 암호화 방법: 대칭키 vs. 비대칭키

결국 HTTPS는 전송하고자 하는 텍스트를 암호화하여 전달한다는 의의가 있다. 그렇다면 컴퓨터2에서는 어떻게 암호화를 하고, 웹서버2는 어떻게 이것을 복호화하는 것일까? 이를 위해서는 일단 대칭키, 비대칭키 개념을 정리하자.

 

Fig 2. 대칭키 알고리즘과 비대칭키 알고리즘의 비교[1]

 

Fig 2.는 대칭키(Symmetric Encryption) 알고리즘과 비대칭키(Asymmetric Encryption) 알고리즘을 비교한 그림이다. 대칭키 알고리즘의 경우 암호화(encrypt)와 복호화(decrypt) 과정 모두 같은 파란색 키로 진행된다. 그에 비해 비대칭키 알고리즘의 경우 암호화는 초록색 키로, 복호화는 빨간색 키로 진행된다. 여기서 키는 은유적 표현으로 암호화&복호화 시 필요한 암호방식이나 파라미터라고 생각하면 된다.

 

대칭키 알고리즘은 암호화와 복호화를 같은 키로 진행한다. 따라서 대칭키를 가지고 있다면 암호화와 복호화를 모두 할 수 있다. 로컬 컴퓨터와 서버가 대칭키를 통해 통신하는 상황을 가정하자. 서버는 통신 시작 시 대칭키를 로컬 컴퓨터에게 전송할 것이다. 로컬 컴퓨터는 이 대칭키를 통해 암호화하여 비밀번호와 같은 중요한 정보를 서버에 전송한다. 서버는 암호문을 대칭키를 통해 복호화해서 비밀번호를 획득한다. 문제는 대칭키를 처음 전송할 때는 대칭키 자체는 암호화 할 수 있는 방법이 없다. 따라서 해커가 쉽게 대칭키 자체를 해킹할 수 있게 된다.

 

비대칭키 알고리즘은 암호화와 복호화를 다른 키로 진행한다. 각각을 공개키(public key), 개인키(private key)라고 한다. 공개키로 암호화할 경우 개인키로만 복호화할 수 있고, 반대로 개인키로 암호화할 경우 공개키로만 복호화할 수 있다. 공개키는 이름 그대로 사람들에게 공개하는 키이고 개인키는 서버가 유일하게 저장하는 키이다. 이러한 방식은 대칭키 알고리즘의 문제를 해결할 수 있다.

 

서버는 로컬 컴퓨터에게 공개키를 전달한다. 로컬 컴퓨터는 공개키를 통해 비밀번호를 암호화하여 서버에 전달한다. 서버는 공개키로 암호화된 문장을 개인키를 통해 복호화해 비밀번호를 알아낸다. 공개키는 해커를 포함한 누구나 가져도 된다. 해커가 공개키를 가지더라도 결국 개인키가 없기에 암호문을 복호화할 수 없다.

 

HTTPS는 이러한 비대칭키 알고리즘을 이용하여 텍스트를 암호화&복호화한다.

 

 

 

SSL 인증서

비대칭키 알고리즘은 대칭키 알고리즘의 문제를 해결하지만 여전히 해킹의 위험이 존재한다. 바로 공개키 자체를 위조하는 것이다. 로컬 컴퓨터가 서버와 통신을 위해 공개키를 요구하는데 해커가 자신의 공개키를 줄 수도 있을 것이다. 로컬컴퓨터는 해당 공개키가 진짜라고 생각하고 해당 공개키를 이용해 비밀번호를 암호화하여 서버에 전송한다. 해커는 이 비밀번호를 중간에서 탈취하여 자신의 개인키로 복호화해 비밀번호를 알아낼 수 있다.

 

이를 보완하기 위한 것이 SSL 인증서이다. SSL 인증서는 서버에서 주는 공개키가 신뢰할 수 있는 것인지를 확인시켜주는 인증서이다. 기술적으로 해킹을 방지한다기보다는 신뢰-사회적 방법으로 해킹 문제를 푸는 것이라고 할 수 있을 것 같다. 우리가 [대한민국 국민]이라는 것을 외교부에서 만든 여권이라는 것이 증명해주듯, 이 [공개키가 해당 서버에서 온 것]임을 공인된 어떤 단체에서 만든 인증서로 증명한다. 공인된 어떤 단체를 인증기관(Certificate Authority-CA)이라고 부르며 실제로 믿을 수 있는 세계적인 회사들이 인증서 발급을 담당한다. 모든 이들은 이 인증기관에서 인증한 정보=[공개키가 해당 서버에서 온 것]는 믿을 수 있다고 약속한다.

 

Fig 3. 인증서 원리 [2]

 

Fig 3.은 CA에서 인증서를 만드는 원리를 표현한 그림이다. 왼쪽은 인증서를 만드는 과정(Signing), 오른쪽은 인증서를 통해 신원증명하는 과정(Verificatio)이다. SSL 인증서는 서버의 공개키와 CA에서 그 공개키가 맞다고 증명한 Signature(Fingerprint)가 포함된다. 사용자는 이 Signature를 이용해 공개키가 신뢰가능하다는 것을 확인할 수 있다.

 

SSL 인증서를 만드는 Signing 과정을 보자. 서버는 CA에게 증명이 필요한 <서버-공개키>를 제출한다. CA는 <서버-공개키>를 어떤 Hash 함수를 통해 hash 값으로 바꾼 후, 이를 자기들의 <CA-개인키>로 다시 암호화한다. 이 암호화된 값이 Signature이다. Signature는 <CA-공개키>로만 복호화될 수 있다. 최종적으로 인증서(Certificate)는 <서버-공개키>와 Signature를 포함하여 만들어진다. 서버는 이제 이 인증서를 <서버-공개키> 배포에 사용한다.

 

로컬 컴퓨터가 SSL 인증서를 통해 <서버-공개키>가 믿을 수 있는 지를 확인하는 과정을 보자. 서버는 SSL 인증서를 로컬 컴퓨터에 전송한다. 로컬 컴퓨터는 다음 2단계를 수행한다. 

1. 인증서에 포함된 <서버-공개키>를 Hash 함수를 통해 Hash 값으로 바꾼다. (어떤 hash 함수를 쓰는지도 인증서에 저장된다.)

2. 인증서에 포함된 Signature를 <CA-공개키>를 통해 복호화한다. 이 값은 CA에 의해 인증받은 Hash 값이다. (CA-공개키는 인터넷에서 다운받을 수 있다.)

 

이렇게 구한 1번 Hash 값과 2번 Hash 값을 비교하면 <서버-공개키>의 신뢰 여부를 확인할 수 있다. 1번과 2번을 모두 <서버-공개키>의 Hash 값을 구하는 과정이다. Signature는 <CA-개인키>로 만드는 값이기에 <CA-개인키>가 없는 한 조작불가능하다. 따라서 Signature를 복호화해서 구한 Hash 값은 조작 불가능하다. 따라서 인증서 내 <서버-공개키>가 조작되더라도 Signature를 복호화한 Hash 값은 조작 불가능하기에 이와 비교하면 <서버-공개키>가 조작되었다는 것을 확인할 수 있다. 즉, 1번과 2번 결과 Hash 값이 같다면 <서버-공개키>는 믿을 수 있는 값이라는 것이고, 다르다면 <서버-공개키>는 믿을 수 없다는 것을 알 수 있다.

 

이러한 방식을 통해 로컬 컴퓨터는 신뢰할 수 있는 <서버-공개키>를 획득한다. 이후 로컬 컴퓨터는 이 <서버-공개키>로 비밀번호를 암호화하여 서버에 전달하고, 서버는 <서버-개인키>를 통해 비밀번호를 복호화한다.

 

 

 

Reference

[1] https://www.digicert.com/faq/ssl-cryptography.htm

[2] https://gdi.ch/