HTTPS는 왜 쓸까? : HTTPS 동작 과정 알아보기

 아직 면접에서 질문 받은적은 없는데, 혹시 질문이 나올 수도 있을까봐 간만에 다시 공부하는 분야다.

 

 HTTPS는 왜 쓸까? HTTP랑은 뭐가 다를까? 사실 다른 점은 딱 하나다. 주고받는 데이터에 암호화를 하느냐 마느냐. 차이점이 딱 하나니까, 사용하는 이유도 당연히 저 하나의 차이에서 나온다. HTTPS는 HTTP보다 데이터를 안전하게 주고 받을 수 있다. 그렇다고 면접에서 이렇게만 대답할 순 없잖아. 오늘은 HTTPS가 안전하게 데이터를 주고받을 수 있게 해주는 암호화 / 복호화 방식을 알아보고자 한다.

HTTP

 HTTP와 HTTPS의 차이는 주고받는 데이터에 암호화를 하냐 마냐의 하나밖에 없다고 했다. 이 말은 다시 말하면, HTTP던 HTTPS던 데이터를 주고받는데 사용된다는 것이다. 여기서 굳이 다룰 필요는 없지만, HTTP던 HTTPS던 Request를 보내면 Response를 응답하는 식으로 데이터를 주고받는다. 먼저 HTTP를 사용했을 때 데이터를 주고받는 예시를 살펴보자.

HTTP REQUEST

 위 사진은 HTTP REQUEST 구조 예시이다. HTTP를 사용하면, 위와 같이 요청에 담긴 정보가 평문으로 제공된다. 즉, 누구나 해당 정보를 쉽게 읽을 수 있다. 우리가 HTTP를 이용해서 주고받는 정보는 HEADER 또는 BODY에 담겨 전송된다. 세부 내용은 조금 다르지만, RESPONSE도 마찬가지로 HEADER와 BODY에 데이터를 담고 이를 반환하는 형태이다. 결과적으로, 우리가 사용하는 모든 정보는 누구나 쉽게 읽을 수 있다. 그럼 HTTP를 이용해서 민감한 정보를 주고받을 수 있을까? 로그인에 필요한 비밀번호나 온라인 주문에 필요한 개인정보를 HTTP를 통해 전달해도 될까? 백이면 백 안된다고 할 것이다. 이 문제를 해결하기 위해 사용되는 프로토콜이 HTTPS다.

 

HTTPS

 HTTPS는 HTTP에 Secure가 추가된 프로토콜이다. HTTP로 데이터를 주고받으니 너무 쉽게 탈취가 가능하니까, 보안을 추가하자는 것이다.

 

 HTTP가 80포트를 이용하는 것과 달리, HTTPS는 443포트를 사용한다. 당연하다, 같은 포트를 사용하면 같은 프로토콜을 사용하니까. HTTPS를 사용하면, 데이터를 송신할 때 암호화하고, 수신할 때 복호화한다. 이 과정에서 대칭키 암호화와 비대칭키 암호화 방식을 사용하는데, 두 방식은 잠시 후에 알아보기로 하고 일단은 대칭키 방식은 하나의 키를 사용하고 비대칭키 암호화는 모두가 알고있는 공개키와, 서버만 알고있는 개인키가 있다는 사실만 인지해두자.

 

 암호화를 하는데 공개키와 개인키를 사용한다고 했다. 그럼 이 키가 암호화의 핵심아닐까? 그럼 이 키를 아무나 보내고, 아무 키나 믿어도 될까? 당연히 안된다. 클라이언트 입장에선 서버에서 일방적으로 보낸 정보로 소통할 수밖에 없다. 따라서 우리는 서버에서 제공한 정보가 정말 믿을만한 정보인지 검증해주는 공명정대한 제3의 기관이 필요하다. 이러한 기관을 CA(Certificate Authority) 기관이라고 하며, 서버는 해당 기관을 통해 자신들의 공개키가 담긴 SSL / TLS 인증서를 발급받고 이를 클라이언트에게 넘겨줌으로써 서버가 안전한다는 확인을 받는다.

 

네이버가 사용하는 인증서, 발급 기관이 CA기관이다

 뭐 당연한 말이지만 CA 기관은 공인 기관이어야 한다. 만약 인증되지 않은 사설 CA기관이면 아래와 같이 HTTPS로 연결되었음에도 안전하지 않다는 경고문이 브라우저에 표시된다.

 인증서는 CA 기관의 개인키로 암호화되어 서버에 발급된다. 이렇게 발급받은 인증서를 바탕으로 클라이언트와 서버 간의 HTTPS 연결이 진행되는 과정은 아래와 같다.

1. 클라이언트가 서버와 연결을 시도한다.
2. 서버는 인증서를 클라이언트에 넘겨준다.
3. 클라이언트는 인증서의 유효성을 검사하고 세션키를 발급한다.
   1. 앞서 언급했듯, 인증서는 CA 기관의 개인키로 암호환된다. 이를 복호화하기 위해서는 CA 기관에서 발급한 공개키가 필요하다.
   2. 클라이언트는 미리 CA 기관의 공개키를 가지고있는다. 가지고 있는 키로 서버에서 제공한 인증서를 복호화한다.
   3. 복호화를 통해 확인한 정보가 CA 기관의 정보와 일치하면 유효한 인증서임을 확인할 수 있다.
   4. 세션키는 대칭키로, HTTPS 연결이 수립된 이후 데이터 암호화에 사용된다.
4. 클라이언트는 세션키를 보관하며 인증서를 통해 확인한 서버의 공개키로 세션키를 암호화하여 서버에 전송한다.
5. 서버는 공개키로 암호화된 세션키를 개인키로 복호화하여 세션키를 얻는다.
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행한다.

 위의 과정을 거쳐 클라이언트와 서버 간의 HTTPS연결이 수립된다. 위 과정에서 대칭키 기법과 비대칭키 기법이 모두 사용된다. 대충 짐작할 수 있겠지만, 대칭키 기법은 하나의 키를 가지고 두 객체가 암호화 / 복호화를 하는 방식으로, 속도가 비교적 빠르나 대칭키가 노출되면 위험하다는 단점이 있다. 반면 비대칭키 기법은 공개키 - 개인키의 두 키를 가지고 암호화 / 복호화를 하며, 공개키로 암호화된 정보는 개인키로만 복호화할 수 있고, 개인키로 암호화된 정보는 공개키로만 복호화할 수 있다. 대칭키 기법과 반대로 속도는 비교적 느리나 어느 한 객체만 알고 있는 개인키가 있기 때문에, 공개키가 노출되어도 위험부담이 적다.

 

 공개키로 암호화 했을 때와 개인키로 암호화 했을 때의 이점은 각각 다른데, 먼저 공개키로 암호화 한 데이터는 개인키로만 복호화 할 수 있기 때문에 민감한 정보를 담는데 용이하다. 개인키를 알고있는 개체가 아니면 정보를 읽을 수 없기 때문이다. 반면 개인키로 암호화한 정보는 공개키로만 복호화할 수 있기 때문에, 서버가 보내는 정보의 신뢰성을 높일 수 있다. 위의 HTTPS 수립 과정에서 대칭키 기법은 세션키를 이용하는 암호화 / 복호화 과정이며, 비대칭키 기법은 최초에 클라이언트에서 발급한 세션키를 서버와 공유하기 위해 서버의 공개키로 암호화하고, 서버는 이를 개인키로 복호화하는 과정이다.

 

 이후로는 서로 알고 있는 세션키를 바탕으로 데이터를 암호화 / 복호화하며 클라이언트 - 서버 간의 통신이 이루어진다. 생각보다 별거 없지 않은가?

 

정리

 HTTPS는 평문을 보내는 HTTP의 보안 문제를 해결하고자 사용한다. HTTPS가 보안상 더 뛰어난 이유를 파악하기 위해 HTTPS 연결과 연결을 위한 핵심인 인증서 발급, HTTPS 통신 과정 등을 살펴보았다. 보안을 위한 핵심은 클라이언트가 지금 정보를 보내고자 하는 서버가 믿을만한가?에 있으며, 서버는 자신들이 믿을만하다는 사실을 검증하기 위해 공인 기관인 CA 기관에서 발급한 SSL / TLS 인증서를 사용한다. 클라이언트는 서버에서 제공한 인증서와 CA 기관을 확인해 믿을만하면 HTTPS 연결을 수립하고, 서버와 함께 사용할 키를 만든다. 서버와 사용할 키는 인증서에 담겨있던 서버가 제공하는 키로 암호화되고 서버에 전달된다. 서버는 자신들만 알고 있는 키로 암호화된 세션키를 복호화 해 이후 통신에 사용한다. 이렇게 HTTPS를 정리해볼 수 있겠다.

 

 SSL / TLS에 대해서도 더 다루고싶지만 오늘은 일단 HTTPS까지만 다루고자 글을 마친다. 대신 읽어볼만한 링크들을 남겨놓는다.

AWS : SSL / TLS 인증서란 무엇인가요?

https://aws.amazon.com/ko/what-is/ssl-certificate/

SSL 인증서란 무엇인가요? - SSL/TLS 인증서 설명 - AWS

 

Cloudflare : SSL이란 무엇입니까? | SSL 정의

https://www.cloudflare.com/learning/ssl/what-is-ssl/

Cloudflare : TLS(Transport Layer Security)는 무엇입니까?

https://www.cloudflare.com/ko-kr/learning/ssl/transport-layer-security-tls/

 

참고자료

망나니 개발자님 : https://mangkyu.tistory.com/98

[Web] HTTP와 HTTPS의 개념 및 차이점