7.1 HTTP의 약점
HTTP에는 다음과 같은 약점을 가지고 있다.
1.암호화 하지 않은 평문 통신이기 때문에 도청 가능
TCP/IP 구조의 통신은 내용을 통신 도중에 엿볼 수 있다. 인터넷은 전 세계를 경유하는 네트워크로 되어 있고, 네트워크 기기나 케이블 컴퓨터 등을 전부 자신이 소유하고 있지 않으므로 악의를 가진 누군가가 엿볼 수 있다.
암호화로 도청을 피할 수 있다.
1)통신 암호화 : SSL(Secure Socket Layer), TLS(Transport Layer Security)와 같은 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 ‘HTTPS’, ‘HTTP over SSL’ 이라 부른다.
2)콘텐츠 암호화 : 통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법으로 HTTP 메시지에 포함되는 콘텐츠만 암호화 하는 것이다. 콘텐츠 암호화를 유효하게 하기 위해서는 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 되므로 주로 웹 서비스 등에서 이용되는 방법이다.
2.통신 상대를 확인하지 않기 때문에 위장 가능
누구나 리퀘스트를 보낼 수 있는데 리퀘스트가 오면 상대가 누군지 상관 없이 무언가의 리스폰스를 반환한다. 이처럼 상대를 확인하지 않는 점이 약점이 될 수가 있다.
1)위장한 웹서버일 우려가 있다.
2)위장한 클라이언트일 우려가 있다.
3)접근이 허가된 상대인지 아닌지를 확인할 수 없다.
4)누가 리퀘스트를 했는지 확인할 수 없다.
5)대량의 리퀘스트에 의한 Dos 공격을 방지할 수 없다.
HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있다. 이 증명서를 위조하는 것은 기술적으로 어렵기 때문에 통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.
3.완전성을 증명할 수 없기 때문에 변조 가능
완전성은 정보의 정확성을 가리키는 것으로 정보가 정확한지 아닌지를 확인할 수 없음을 나타낸다.
상대가 수신전에 변조되었다고 하더라도 이를 알 수가 없기 때문에 발신된 리퀘스트, 리스폰스와 수신된 리퀘스트, 리스폰스가 같은지 아닌지를 확인할 수 없다. 이와 같이 공격자가 중간에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 ‘중간자 공격(Man in the Middle 공격)’ 이라고 한다.
변조를 방지하려면 자주 사용되는 방법으로 MD5, SHA-1등의 해시 값을 확인하는 방법과 디지털 서명을 확인하는 방법이 있다. 하지만 이 방법도 확실한 것은 아니다 이또한 적절하게 수정한다면 유저로서는 알 수가 없다. 확실히 방지하기 위해서는 HTTPS를 사용하면 된다. SSL에는 인증이나 암호화 그리고 다이제스트 기능을 제공하고 있다.
7.2 HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS라고 부른다. 주로 웹페이지의 로그인이나 쇼핑의 결제 화면등에서 사용된다.
HTTPS는 통신을 하는 소켓 부분을 SSL 또는 TLS라는 프로토콜로 대체하고 있을 뿐 새로운 프로토콜은 아니다. 보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용하는 경우에 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.
SSL에서는 공개키 암호화 방식이라 불리는 암호화 방식을 사용하고 있다. 이전에는 암호화와 복호화에 하나의 키를 사용하는 공통키 암호화 방식을 사용했으나 하나의 키를 사용하므로써 키를 전달하는 과정에서 키를 도청 당할 수 있는 문제가 있어 이러한 문제를 해결하기 위해 나온 방식이 공개키 암호화 방식이다. 공개키 암호화 방식은 서로 다은 두 개의 키를 사용하고, 한쪽은 비밀키(누구에게도 알려지면 안되는 키), 공개키(누구에게나 알려져도 괜찮은 키)이다.
암호를 보내는 측이 상대의 공개키로 암호화를 하고 암호화된 정보를 받아들이는 상대는 자신의 비밀키를 사용해 복호화를 실시한다. 이 방식은 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해 키를 빼앗길 걱정이 없다.
HTTP는 공통키 암호화와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템이다. 키를 교환하는 곳에서는 공개키 암호를 사용하고, 그 후의 동신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.
[증명서]
공개키 암호에도 문제점이 있는데 그 문제점은 공개키가 진짜인지 아닌지를 증명할 수 없다는 점이다. 공격자가 도중에 공개키를 바꿔치기 하면 알 방법이 없다. 그래서 이러한 문제를 해결하기 위해 인증기관과 인증기관이 발행한 공개키 증명서가 이용된다. 유명한 인증기관은로 ‘VeriSign’사가 있다.
인증 기관의 공개키는 안전하게 클라이언트에 전달되지 않으면 안된다. 통신 중에는 어떤 방법을 사용하더라도 안전하게 전달하는 것은 어렵기 때문에 많은 브라우저가 주요 인증기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있다.
- 위의 증명서의 역할은 서버가 올바른 통신 상대임을 증명하지만 상대방이 실제로 있는 기업인지를 확인하는 역할도 있다. 그 역할을 가진 증명서를
EV SSL 증명서라고 한다. 브라우저의 주소창이 녹색으로 변하면 EV SSL 증명서로 증명된 웹사이트인 것을 시각적으로 알 수 있다. - 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는
클라이언트 증명서도 있으나 문제점으로 증명서의 입수와 배포가 있다. 유저가 클라이언트 증명서를 install 해야하고, 유료로 구입해야하기 때문에 많은 비용이 든다. - SSL 인증 기관은 신용이 중요한데 가짜 증명서가 발행되 버린 사건이 있었다. 잘못 발행된 증명서라 해도 믿을 수 있는 인증 기관의 서명이 있기 때문에 브라우저는 올바른 증명서로 인식한다.
- OpenSSL 등의 소프트웨어를 사용하면 누구든지 인증 기관을 구축할 수 있어 서버 증명서를 발행할 수 있으나 인터넷상에서 증명서로 구실을 하지 못하고 쓸모가 없다.
[HTTPS의 구조]
- 클라이언트가 메시지를 송신하면서 SSL 통신이 시작된다. 메시지에는 SSL의 버전을 지정하고 암호 스위트가 포함되어 있다.
- 서버가 SSL 통신이 가능한 경우 메시지로 응답하고 SSL 버전, 암호 스위트를 내용에 포함한다.
- 메시지에 공개키 증명서를 포함하여 송신한다.
- 최초의 SSL 네고시에이션 부분이 끝났음을 통지
- 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange 메시지로 응답한다.
- 클라이언트는 Change Cipher Spec 메시지를 송신한다.
- 클라이언트는 Finished 메시지를 송신한다. 이 메시지는 접속 전체의 체크 값을 포함하고 있다.
- 서버에서 Change Cipher Spec 메시지를 송신한다.
- 서버에서 Finished 메시지를 송신한다.
- 서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의해서 접속은 확립된다. 그리고 이제부터 애플리케이션 계층의 프로토콜에 의해 통신을 한다. 즉 HTTP 리퀘스트 송신
- HTTP 리스폰스 송신
- 클라이언트가 마지막으로 접속을 끊는다.
[SSL, TLS]
HTTPS에서는 SSL과 TLS라는 두 개의 프로토콜이 사용되고 있다. TLS는 SSL을 바탕으로 한 프로토콜로 이 프로토콜을 총칭해서 SSL이라 부르기도 한다.
SSL통신은 HTTP에 비해 통신속도가 떨어지고, CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려진다. 또 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화나 복호화를 위한 계산을 할 필요가 있어 리소스를 소비하게 되어 HTTP에 비해 부담이 커진다. 느려지는 것에 근본적인 해결방법은 없기 때문에 SSL 엑셀레이터라는 하드웨어를 사용해서 이 문제를 해결하기도 한다.