HTTP와 HTTPS에 대해 알아보자

홍예석·2023년 6월 9일

개념에 대해 알아보자 시리즈

목록 보기

4/5

HTTP와 HTTPS

HTTP는 어플리케이션 계층에서의 통신 규약이다. HTTP 프로토콜을 사용하는 어플리케이션이란 서버와 통신할 때 HTTP라는 약속을 지켜서 요청을 보내야 하는 어플리케이션을 말하는 것이다. 그렇다면 HTTPS는 무엇일까? HTTPS는 HTTP 프로토콜과 SSL 프로토콜을 합친 통신 규약이다. HTTPS는 HTTP와 상당 부분에서 동일하지만, SSL 인증서에 의해 요청과 응답이 한 차례 암호화된다는 면에서 차이가 있다. 즉 Secure Socket Layer라는 이름에 Secure가 포함되어 있는 부분에서 알 수 있듯이, HTTP 프로토콜의 보안을 강화한 버전이라고 볼 수 있다.
그렇다면 SSL 인증은 어떻게 이루어질까? 이에 대해 알아보자.

SSL 인증

SSL 인증서

SSL 인증에 대해 알기 위해서는 SSL 디지털 인증서에 대해 알아야 한다. SSL 디지털 인증서는 서버와의 통신을 제3자가 보증해 주는 인증서다. SSL 디지털 인증서가 발급되어 있는 서버는 클라이언트로부터 요청이 들어오면 이 인증서 정보를 전달한다. 클라이언트는 이 인증서 정보가 신뢰할 수 있는지 검증한 후에 다음 절차를 수행한다. SSL 인증이 이루어지면 두 가지 절차가 이루어지는데, 요청이 암호화되는 동시에 요청에 대한 변경이 불가능하게 된다. 따라서 통신 내용을 악의적인 공격자가 탈취해 열람할 수 없게 되며 클라이언트가 요청한 사이트가 아닌 다른 사이트로 연결되는 것을 방지할 수 있어 사이트를 신뢰할 수 있게 된다.
그렇다면 SSL 인증은 어떻게 요청을 암호화하고, 변경이 불가능하게 하는 것일까?

대칭키와 공개키 방식

이 SSL 인증의 핵심은 바로 키에 있다. 키 방식의 인증에는 크게 대칭키와 공개키 방식이 있는데, 대칭키 방식은 서버와 클라이언트가 같은 키를 공유하는 방식이고 공개키 방식은 서버가 공개키와 비밀키를 함께 생성해 두고, 공개키는 서버에 접근하는 모든 클라이언트에게 제공하는 방식이다.
우선 공개키 방식의 경우 클라이언트는 받은 공개키를 이용해 자신이 보낼 요청을 암호화해 서버로 전송한다. 해당 공개키를 이용해 암호화된 요청을 복호화 할 수 있는 키는 함께 생성된 비밀키밖에 없기 때문에, 만약 요청을 도중에 누가 가로채더라도 해당 요청을 복호화 할 수 없다. 또한 서버 역시 응답을 비밀 키로 암호화해 클라이언트에게 반환하는데, 만약 공격자가 서버로부터 응답을 가로채 악의적인 응답을 반환했을 경우, 클라이언트는 공개키로 해당 응답을 복호화 시도를 한다. 하지만 공격자가 반환한 응답은 클라이언트가 들고 있는 공개키와 함께 생성된 비밀키로 암호화된 응답이 아니기 때문에 클라이언트는 해당 응답을 부적절한 응답으로 간주하고 보안 오류를 발생시킨다. 따라서 반드시 요청자와 응답자가 클라이언트와 서버라는 것이 보장된다.
이제 공개키 방식에서 SSL 인증 자체가 어떻게 이루어지는지는 이해가 됐다. 그런데, SSL 인증서를 발급해 주는 ‘제 3자’는 누굴까? 이들을 Certificate Authority, CA라고 한다.

CA (Certificate Authority)

SSL 인증을 필요로 하는 서버 관리자는 CA 기업들로부터 SSL 인증서를 구입해 서버에 적용한다. 물론 신청만으로 인증서를 발급해 주지는 않는다. 기업들은 제3자로서 해당 사이트의 보안에 대한 인증을 하는 것이기 때문에 신뢰성이 매우 중요하기 때문이다. 따라서 사이트에 대한 심사를 거친 후 문제가 없다면 그 때 인증서를 발급한다. 이러한 CA 기업에는 대표적으로 Symantec, Comodo with와 같은 전문 기업도 있고 Google, Microsoft와 같은 대형 기업들도 있으며 사설 인증기관도 있다. 이렇게 발급된 SSL 인증서에는 크게 2가지 정보가 포함되어 있는데, CA가 어느 기관인지, 서비스의 도메인과 같은 서비스의 정보와 서버 측의 공개키가 포함된다. 그런데, 이 SSL 인증서 역시 해당 CA의 비밀키로 암호화되어 있기 때문에 이를 복호화 하기 위해 해당 CA 기업의 공개키가 필요하다. 그렇다면 이 공개키는 어디에 있을까? 바로 브라우저에 있다. 브라우저는 업데이트할 때마다 공인된 CA기업의 리스트와 해당 기업들의 공개키를 브라우저에 내장한다. 따라서 우선적으로 이미 내장하고 있는 공개 키로 서버로부터 받은 SSL인증서를 복호화하고, 인증서 안에 있는 정보를 통해 해당 사이트가 신뢰할 수 있는 사이트임을 브라우저는 알 수 있게 된다. 이후 SSL 인증서 안에 CA 기업의 공개키가 아닌 서버의 공개키가 포함되어 있기 때문에 해당 공개키를 이용해 암호화 후 서버로 요청을 보내게 된다. 즉 CA기업으로부터 인증서를 신뢰하고, 인증서로부터 서버를 신뢰하는 구조로 이어지는 것이다. 물론 CA기업 자체를 신뢰할 수 없게 되는 경우가 있는데, 바로 해당 기업의 비밀키가 공개되는 경우다. 일례로 디지노타라는 기업이 비밀키가 공개되어 파산한 사례가 있다.
여기까지 이제 이론상 CA 기업만 신뢰할 수 있다면 클라이언트는 서버를 신뢰할 수 있을 것이다. 하지만 실제 SSL 인증은 이러한 공개키 방식만을 이용하지 않는다. 요청 하나하나에 모두 공개키와 비밀키를 이용해 암호화와 복호화를 진행하면 리소스 소모가 심하기 때문이다. 따라서 SSL 인증은 모든 요청을 공개키 방식으로 암호화하고 복호화 하지 않고 대칭키를 혼합한 방식으로 진행되며 이 과정은 악수 -> 세션 시작 -> 세션 종료의 단계를 거치도록 발전했다. 여기서 악수는 3way handshake를 말하는데, 실제로 사용되는 용어다. 각 단계에 대해 알아보자.

SSL 인증의 실제 과정

악수(3way handshake)

우선 클라이언트가 서버에 도메인 주소를 입력해 접속하는데 이를 Client Hello라고 한다. 이 때 클라이언트가 랜덤 데이터를 생성해 서버로 전송한다. 그리고 클라이언트에서 수행할 수 있는 암호화 기법 목록도 전송한다.

다음으로 Client Hello를 받은 서버는 Server Hello라는 응답을 반환한다. 이 때 클라이언트가 수신하게 되는 정보는 서버가 생성한 랜덤 데이터와 서버가 선택한 암호화 기법, 그리고 인증서이다.

마지막으로 Server Hello를 받은 클라이언트는 내장되어 있는 CA 기업 목록에 인증서를 발급한 CA가 있는지 검증하고 있다면 내장되어 있던 공개키를 이용해 복호화 과정을 거친다. 이후 복호화에 성공했다면 해당 서버를 이제는 신뢰할 수 있다. 이제 실제 데이터를 주고받는 세션 단계로 이어진다.
클라이언트는 앞서 서버와 각각 주고받은 랜덤 데이터를 조합해 pre master secret key를 생성한다. 생성된 pre master secret key는 인증서에 있던 서버의 공개키를 이용해 암호화되어 서버로 전달된다. 이를 받은 서버는 비밀키를 이용해 복호화 하여 이 키 값을 획득하고, 서버와 클라이언트는 동일한 키를 공유하게 된다. 이후 클라이언트와 서버는 모두 같은 방식으로 pre master secret 값을 master secret 값으로 만든다. Master secret값은 session key를 만드는데 활용된다. 같은 master secret을 같은 방식으로 암호화했기 때문에 session key는 클라이언트와 서버 모두 동일한 값을 갖게 되어 대칭키가 된다. 마지막으로 클라이언트와 서버는 handshaking 단계의 종료를 서로에게 알린다.

아직 본격적으로 데이터를 주고받지는 않았다. 그저 서로를 신뢰할 수 있는 상태라는 것을 확인한 상태인 것이다.

Session

세션 단계는 서버와 클라이언트가 데이터를 주고받는 단계이다. 이제 어려운 내용은 없다. 그저 session key를 이용해 클라이언트는 데이터를 암호화해 전송하고, 서버는 같은 session key를 이용해 데이터를 복호화 하여 요청을 처리한다. 앞서 악수 단계와 같이 복잡한 과정을 거친 이유는 공개키 방식이 리소스를 너무 많이 소모하기 때문에, 통신이 시작되는 첫 단계에서만 서로를 신뢰할 수 있는지, 앞으로도 신뢰할 수 있는 증표를 만들기 위해 한 차례만 공개키 방식을 이용한 후 이후에는 훨씬 효율적인 대칭키 방식을 이용하기 위해서이다.