HTTPS와 HTTP?

HTTP

인터넷 상에서 정보를 주고받는 통신목적으로 사용되는 프로토콜이다. 리소스를 받는 쪽을 클라이언트(Client)가 되고, 리소스를 보내주는 쪽이 서버(Server)가 된다. HTTP에 관련된 내용은 이전에 공부한 이전 글 - 클라이언트와 서버의 통신 HTTP 에서 일부 살펴볼 수 있다. 물론 내용은 불충분하지만, 기초적인 HTTP를 이해하는데 무리는 없다.

HTTP의 약점

HTTP는 사용하기 간편하고, 통신에 적합한 프로토콜이다. 그럼에도 불구하고 모든 통신 프로토콜이 그러하듯 보안과 관련한 몇 가지 약점을 가지고 있는데, HTTP의 약점을 한번 살펴보도록 하자.

• 평문(암호화 하지 않은)통신이기 때문에 도청 가능하다.
• 통신 상대를 확인하지 않기 때문에(인증절차가 없기 때문에) 위장 가능하다.
• 완전성을 증명할 수 없기 때문에 변조 가능하다.

평문이기 때문에 도청 가능하다.

HTTP를 사용한 Request나 Response 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않는다. 즉, 평문으로 HTTP 메시지를 보내게 된다.

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

TCP/IP 구조의 통신 내용은 전부 통신 도중에 경로에서 엿볼 수 있기 때문이다. 인터넷은 전 세계를 경유하는 네트워크로 되어있다. 어느 서버와 클라이언트가 통신할 때, 통신 경로 상에 있는 네트워크 기기나 케이블이나 컴퓨터 등을 모두 소유하고 있는 경우는 없다. 다자간의 통신으로 이루어지기 때문에 메시지가 도청당할 수 있다. 통신이 이루어지는동안 지나는 여러 기기들이 있다.

같은 세그먼트의 통신은 네트워크 상에 흐르고 있는 패킷을 수집하는 것으로 도청할 수 있다. 패킷을 수집하려면 패킷을 해석하는 패킷 캡처나 스니퍼라는 툴을 이용한다.

암호화로 도청을 피한다.

현재 통신데이터 도청으로부터 피하기 위해서 여러 방법이 고안되고 있다. 그 중에 가장 보급되어있는 기술이 암호화인데, 암호화에는 몇 가지의 대상이 있다.

1) 통신 암호화

한 가지는 통신을 암호화하는 방법이다. HTTP에는 암호화 구조는 없지만 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)(SSL 신버전이 TLS지만, SSL로 통합해서 부른다.)라는 다른 프로토콜을 TCP/IP 위, 애플리케이션 계층 아래에 조합함으로써, HTTP의 통신 내용을 암호화할 수 있다. SSL 등을 이용해 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 한다. 이렇게 SSL을 조합한 HTTP를 HTTPS(HTTP Secure)나 HTTP over SSL이라 불린다.

2) 콘텐츠 암호화

다른 한 가지는 통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법이다. HTTP에 암호화를 하는 기능은 없기 때문에 HTTP를 사용해서 운반하는 것을 암호화하는 것이다. 즉 HTTP메시지에 포함되는 콘텐츠(바디)를 암호화해버리는 것이다.

물론 콘텐츠 암호화를 유효하게 적용하려면 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 되므로, 평상시에 유저가 사용하는 브라우저와 웹 서버에서 이용하는 것은 어렵다. 주로 웹 서비스에서 적용한다.

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

HTTP를 사용한 Request나 Response에서는 통신 상대를 확인하지 않는다. Request를 보낸 곳이 정말 URI에서 지정된 호스트인지, Response를 반환한 클라이언트가 진짜 받은 곳인지 HTTP로는 모른다.

누구나 요청 가능!

HTTP에 의한 통신은 상대가 누구인지 확인하는(인증하는) 절차가 없기 때문에 누구든지 요청할 수 있다. 요청이 오면 상대가 누구든지 무언가의 Response를 반환한다.(host나 포트 등에 웹 서버 제한이 없을 경우)

HTTP는 누구이던 간에 요청을 보내면 응답을 무조건 주는 단촐한 구조로 되어있지만, 상대를 확인하지 않는 점이 약점일 수가 있다. 예상되는 약점은 아래와 같다.

• 요청을 보낸 곳의 웹 서버가 원래 의도한 응답을 보내야하는 웹 서버인지 아닌지를 모른다. 가짜 웹 서버 있을 수 있다. 서버 신뢰문제
• 응답을 돌려준 곳이 원래 의도한 요청을 보내는 클라이언트인지 모른다. 가짜 클라이언트일지도 모른다. 클라이언트 신뢰문제
• 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다. 중요한 정보를 불특정한 곳에 돌려보낼 수도 있다. 인증문제
• 어디에서 누가 요청한건지 확인이 안된다. 출처 불분명
• 의미없는 요청도 수신하게 된다. DDos 무분별 공격 우려

상대를 확인하는 증명서

HTTP에서는 통신 상대를 확인할 수 없지만, SSL로 간접적으로 확인할 수 있다. SSL은 암호화뿐 아니라 상대를 확인하는 수단으로 증명서를 제공한다. 증명서는 신뢰할 수 있는 제3자인 인증기관에서 발행하기때문에 서버나 클라이언트의 실존한다는 사실을 증명한다!(AWS SSL 인증 절차 관련 블로깅 필요!) 그 증명서를 위조하는 것은 기술적으로 상당히 어렵다.

이 증명서를 이용함으로써, 통신 상대가 내가 통신하고자하는 서버임을 알려주고, 이용자는 불특정한 곳으로 정보가 누설되는 위험성을 크게 줄일 수 있다.

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

완전성이란 정보의 정확성을 의미한다. 그것을 증명할 수 없다는 이야기는 정보가 진짜인지 가짜인지, 정확한지 틀린것이 있는지 알아내기가 어렵다는 뜻이다.

수신한 내용이 다를지도 모른다.

HTTP가 완전성을 증명할 수 없다는 뜻은 만약 요청이나 응답이 발신된 후에 수신할때까지 변조되어도 그 사실을 알 수 없다. 발신된 요청/응답 내용이 중간에 변조된지 확인이 어렵다.

예를 들어, 어떤 웹 사이트에서 콘텐츠를 다운로드했다고하면 내 컴에 다운로드 된 파일과 서버에서 날아오는 파일이 같은건지 알 수없다는 뜻이다. 정말 다른 내용으로 변경되었다해도 나는 그 사실을 파악할 수 없다.