What is HTTPS?

HTTPS

HTTP 에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS , S는 secure를 나타낸다

 

그렇다면 HTTPS 란 무엇일까? 이에 관련해서는 HTTP가 가지는 통신상의 문제점을 언급해야 한다. 간략히 말하면 HTTP는 보안이 취약한 통신 메시지이다. 보안이 취약하다는 말은 우리가 생각하는 웹상의 모든 안좋은 점(해킹 등)이 발생할 가능성이 높은 통신 규칙이라는 것이다. HTTP의 메시지들을 보면 "Who"가 없다. 즉 통신 상대를 확인하지 않으므로, 웹 브라우저와 웹 서버 간의 통신 규칙만 알면 다른 누군가도 그 통신에 끼어들 수 있게 되는 것이다. 

• 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
• 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
• 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
• 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
• 의미없는 리퀘스트도 수신한다. 

이에 더하여 HTTP는 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이는 정보의 정확성 즉 완전성을 증명할 수 없다는 HTTP의 문제점 중 하나이다. 이러한 것은 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

 

이에 따라, SSL(Secure Socket Layer)라는 보안된 프로토콜과 HTTP를 통합함으로써 통신 내용을 암호화 할 수 있으며, 이 SSL로 WHO를 파악할 수 있게 된다. SSL 은 상대를 확인하는 수단으로 증명서 를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3 자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 또한 SSL을 통해서 위에서 언급한 정보의 정확성 또한 보장할 수 있다.

SSL 을 조합한 HTTP 를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.

 

HTTPS는 SSL 의 껍질을 덮어쓴 HTTP 라고 할 수 있다. 즉, HTTPS 는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer)라는 프로토콜로 대체하는 것 뿐이다.

 

HTTPS에서 SSL의 핵심은 WHO와 WHAT에 대한 정확성을 보장하는 보안 방식이라는 것이다. 그렇다면 어떠한 방식을 통해서 이것이 가능하게 하는 걸까? SSL은 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

 

보안키에 대해서는 대칭키와 공개키가 있다. 대칭키라는 것은 메시지를 암호화 해주는 키값이 존재하고, 이는 일반 메시지로 복호화도 진행해준다. 따라서 통신하는 둘 사이에는 키값을 주고 받는다. 이때 키값을 중간에 누군가가 보거나 가지고 가게 된다면, 문제가 발생한다.

이를 보완한 새로운 방식이 공개키이다. 대칭키 방식과는 다르게 암호화는 A로만 가능하고, 복호화는 B로만 가능하다. 반대의 경우 또한 가능하다. 즉 A와 B는 서로 반대의 기능을 하지만 하나의 짝인 것이다. 따라서 서버는 A만 공개하고, 사용자들은 이 A로 암호화하여 데이터를 서버로 보낸다. 복호화는 오로지 B키를 가진 서버만 가능하다. 
반대로 웹브라우저 기준에서는 B로 암호화된 사이트여야만 적합한 사이트라고 인지하게 된다. 
이 때 이 공개키가 인증된 키임을 보증해주고 관리해주는 곳이 CA이다.

 

아래의 흐름은 실제 SSL인증서를 통해 진행되는 예시이다.

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
   -> CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
   -> CA에서 해당 공개키가 A서버의 것이라는 것을 보장해준다.
3. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.
4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
5. 클라이언트는 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
   -> CA 기업의 공개키는 브라우저가 이미 알고있다. 
6. 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되었다. 이제 A서버와 통신할 때는, 얻은 A서버의 공개키로 암호화해서 요청을 날리게 된다.