HTTP의 문제점

HTTP는 다음과 같은 문제점을 갖는다.

  1. HTTP는 평문 통신이기 때문에 도청이 가능하다.
  2. 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
  3. 완전성을 증명할 수 없기 때문에 변조가 가능하다.

위 세 가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.

TCP/IP는 도청 가능한 네트워크이다.

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로도 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

1번 문제를 보완하는 방법은 다음과 같다.

  1. 통신 자체를 암호화
    SSL(Secure Socket Layer) or TLS(Transport Layer Security) 라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.

  2. 콘텐츠를 암호화
    말 그대로 HTTP를 사용해서 운반하는 내용인 HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대를 확인하지 않기 때문에 위장이 가능하다.

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 Request를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 엑세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

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

2번 문제를 보완하는 방법은 다음과 같다.

SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 써드 파티로부터 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다.

이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

SSL의 작동 과정

  1. 클라이언트가 SSL로 암호화된 페이지를 요청한다.(일반적으로 https://가 사용된다.)
  2. 서버는 Public Key와 인증서를 함께 전송한다.
  3. 인증서가 신용있다고 판단한 CA(Certificate Authority)로부터 서명된 것인지 판단한다.
  4. 클라이언트는 Public Key를 사용해서 랜덤 대칭 암호화키와 URL, http 데이터를 암호화하여 서버로 전송한다.
  5. 서버는 Private Key를 이용하여 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.
  6. 서버는 요청받은 URL에 대한 응답을 랜덤 대칭 암호화키를 이용해서 암호화해서 클라이언트로 전송한다.
  7. 클라이언트는 대칭 키를 이용해서 http 데이터를 복호화하고 데이터를 이용한다.

SSL의 인증과 암호화 과정을 통해 3번 문제 또한 해결할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능하다.

여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 으해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Main-in-the-Middle)이라고 부른다.

3번 문제를 보완하는 방법은 2번 문제를 보완하는 방법으로도 해결이 가능하다.

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

HTTPS

HTTPS는 HTTP 통신하는 소켓 부분은 SSL or TLS라는 프로토콜로 대체한 것이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 모두 사용한다.(두 개를 혼합한 하이브리드 암호화 시스템) 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식아.

[공통키, 공개키, 대칭키 암호화 방식이 뭘까…?]

모든 웹 페이지에서 HTTPS를 사용하지 않는다. 그 이유는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 많이 필요로 하기 때문이다. 통신할 때마다 암호화를 하면 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 Request 수가 줄어들게 된다. 따라서 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다.
그러나! 개인정보를 주고 받지 않아도 SSL을 이용해야 한다. 어느 사이트에 접속하는지, 어떤 행동을 하는지 공개될 수 있다. 모든 사용자의 행동 및 정보는 보호받아야 할 권리가 있다. 예를 들어, A 사이트에서 로그인 페이지로 넘어갈 때 해커가 가짜 로그인 페이지로 보낼 수 있는 확률도 존재한다.

참고