HTTP vs HTTPS

2 minute read

HTTP란?

위에서 언급한 Stateless와 Connectionless는 비즈니스 로직에 따라 장점 또는 단점이 될 수도 있다.
이러한 특징 외에 HTTP는 평문(즉, 암호화 되지 않는다.)으로 전달이 되기 때문에, ‘스니처’와 같은 툴을 이용해 악의적인 사용자가 쉽게 HTTP 패킷을 가로챌 수 있다.

우리의 비즈니스 상황에서는 주로 고객의 정보와 같은 민감한 내용을 주고받는 경우가 빈번하기 때문에 HTTP로 전달되는 패킷의 내용을 감춰야 한다. 이런 보안상의 단점을 해결하기 위해서 HTTPS가 등장했다.

HTTPS는 Hyper Text Transfer Protocol Secure의 약자로 이름에서 알 수 있듯 기존의 HTTP에서 보안 기능을 추가한 프로토콜이다.
HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다.
즉, HTTPS는 HTTP의 기능에서 암호화 기능을 추가해 전송과정에서 정보를 보호하는 역할을 수행한다.

HTTPS는 SSL이라는 프로토콜을 추가로 사용해서 HTTPS의 정보를 암호화한다. 다음과 같은 계층 구조를 갖는다.

대칭키와 비대칭키에 대한 내용은 여기서 확인해주세요.

HTTPS는 공개키 암호화 방식과 대칭키 암호화 방식을 함께 사용한다. 즉, 공개키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.

공개키(비대칭키) 암호화 방식은 느리다는 단점이 있기 때문에, 더 빠른 방식인 대칭키를 사용한다. 그렇지만, 대칭키 방식은 암호화와 복호화 시에 같은 키를 사용하기 때문에 대칭키를 전달하는 과정에서 여전히 보안에 취약할 수 있기 때문에 해당 대칭 키를 전달할 때 공개키 암호화를 사용해서 전달한다.

HTTPS를 우리 사이트에 적용하기 위해서는 인증 기관을 통해 인증서를 발급받고 우리 사이트의 신뢰성을 검증받아야 한다. 해당 과정에 대해 알아보기 전에 용어 정리부터 하려고 한다.

우선 서버는 자신의 사이트가 신뢰할 수 있는 사이트라는 것을 클라이언트에게 알려야 하는데, 이런 신뢰성을 보장하기 위해서 중간에 인증 기관(CA)를 거쳐서 검증 받아야 한다.
CA란 서버의 인증서를 발급해주는 기관으로, CA는 신뢰성이 엄격하게 공인된 기업들만 할 수 있다. 또한 각 CA는 자체적으로 공개키와 비밀키를 가지고 있다.

웹 브라우저에는 주요 CA들의 공개 키가 내장되어 있다.

CA는 인증서를 발급해줄 때 서버의 공개키를 인증서 안에 넣고 CA 자신의 개인키로 암호화한다.

즉, CA의 역할은 우리 사이트의 신뢰성을 검증해주는 것이다. 우리의 사이트의 자체적으로 신뢰성을 부여하는 것은 객관성이 떨어지기 떄문에 공인된 기관으로부터 신뢰성을 검증받아야 하고, 해당 결과로 CA는 신뢰성이 있다는 인증서를 발급해주게 된다.

우선 CA로부터 인증서를 발급받았다는 것을 전제로 한다.
사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저에게 보낸다.
즉, 웹 브라우저는 CA의 개인키로 암호화된 인증서를 받게 된다.
웹 브라우저는 해당 인증기관의 공개키로(웹 브라우저 내장) 인증서를 복호화하여 해당 서버가 실회할 수 있는 서버인 지 판단하고, 복호화된 인증서 안에 있는 서버의 공개키를 추출한다.
이렇게 얻은 서버의 공개키로 브라우저가 만든 대칭키를 암호화해서 서버 측에 보낸다.
서버는 개인키로 클라이언트가 보낸 암호문을 자신의 개인키로 복호화하여 대칭키를 얻게 되고, 이제 서로의 대칭키로 데이터를 주고받을 수 있게 된다.