Chapter#7
HTTP의 약점
- 평문(암호화 X) 통신이기에 도청 가능
- 통신 상대를 확인하지 않기에 위장 가능
- 완전성을 증명할 수 없기에 변조 가능
1. 평문이기 때문에 도청 가능
HTTP 자신을 암호화하는 기능이 없어서 통신 전체가 암호화 X -> 평문으로 HTTP 메시지를 보내게 된다.
- TCP/IP는 도청 가능한 네트워크
TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있다. 어느 서버와 클라이언트가 통신할 때 통신 경로 상에 있는 모든 것을 자기 자신이 소유하고 있는 일은 없기 때문에, 악의를 가지고 접근한다면 엿볼 수 있다. - 암호화로 도청 피하기
-> 통신 암호화 : 통신을 암호화 한다. SSL(Secure Socket Layer), TLS(Transport Layer Security)이라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화
-> 콘텐츠 암호화 : 통신하고 있는 콘텐츠 내용 자체를 암호화. 클라이언트에서 HTTP 메시지를 암호화하여 출력하는 처리가 필요하다.
2. 통신 상대를 확인하지 않기 때문에 위장 가능
HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않는다. 리퀘스트를 보낸 서버가 정말로 URI에서 지정된 호스트인지 아닌지, 리스폰스를 반환한 클라이언트가 정말로 리퀘스트를 출력한 클라이언트인지 아닌지를 모른다.
- 상대를 확인하는 증명서 : SSL로 상대를 확인할 수 있다. SSL은 암호화 외에도 상대를 확인하는 수단으로 증명서를 제공.
-> 증명서는 신뢰할 수 잇는 제3자 기관에 의해 발행되는 것. 서버나 클라이언트가 실재하는 사실을 증명.
3. 완전성을 증명할 수 없기 때문에 변조 가능
완전성이란 정보의 정확성을 가리킴. 그것을 증명할 수 없다는 것은 정보가 정확한지를 확인할 수 없음을 의미한다.
-> 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하기 전의 사이에 변조되었다고 하더라도 이 사실을 알 수 없다.
<변조 방지 방법>
- MD5, SHA-1 등의 해시 값을 확인하는 방법, 파일의 디지털 서명을 확인하는 방법
- HTTPS 사용
HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
1. HTTPS
HTTP통신 - 암호화되지 않은 평문으로 실시. 통신 상대의 서버나 클라이언트를 인증하는 수단이 없다.
HTTPS -> HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS(HTTP Secure)라고 부른다.
HTTPS를 사용하는 통신은 웹 페이지의 로그인이나 쇼핑의 결제화면 등에서 사용되고있다.
URI에 http:// 가 아닌 https:// 를 사용한다.
2. SSL의 껍질을 덮어쓴 HTTP
HTTP 통신을 하는 소켓 부분을 SSL이나 TLS프로토콜로 대체하는 것이다.
보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.
SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 된다.
3. 상호간에 키를 교환하는 공개키 암호화 방식
SSL에서는 공개키 암호화 방식이라 불리는 암호화 방식을 채용하고 있다. 현대의 암호는 알고리즘이 공개되어 있고, 키를 비밀에 부침으로써 안전성을 유지한다. 암호화나 복호화할 때 이 키를 사용한다. 키가 없으면 암호를 풀 수는 없지만, 반대로 키를 가지고 있다면 누구라도 암호를 풀 수 있다.
-> 딜레마 - 해당 방식은 상대방에게 키를 넘겨주지 않으면 안된다. 키를 보내면 도청될 가능성이 있다.
- 두 개의 키를 사용하는 공개키 암호
공개키 암호에서는 서로 다른 두 개의 키 페어를 사용한다. 한쪽은 비밀키, 한쪽은 공개키이다.
공개키 암호를 사용한 암호화 : 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다. -> 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다. -> 해당 방식은 비밀키를 통신으로 보낼 필요가 없어 도청에 의한 위험은 없다.
4. 공개키가 정확한지 아닌지를 증명하는 증명서
공개키가 진짜인지 아닌지를 증명할 수 없다는 문제점이 있다.
-> 인증 기관(CA : Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다. 인증 기관이란 클라이언트와 서버가 모두 신뢰하는 제3자 기관.
- 인증기관
서버의 운영자가 인증 기관에 공개키 제출 -> 인증 기관은 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키를 만든다. -> 공개키 인증서에 서명이 끝난 공개키를 담는다. -> 서버는 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신한다.
-> 조직의 실제성을 증명하는 EV SSL 증명서
상대방이 실제로 있는 기업인지를 확인하는 역할을 하는 증명서를 EV SSL 증명서라고 한다.
-> 클라이언트를 확인하는 클라이언트 증명서
서버 증명서와 같이 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증을 할 수 있다.
안전성이 매우 높은 인증 기능을 제공하지만, 입수와 배포에 문제점이 있다. 유저가 해당 증명서를 인스톨할 필요가 있고, 증명서는 유료로 구입해야하기에 비용이 든다. 따라서 특정 용도로만 사용되고 있다.
- SSL과 TLS
HTTPS에서는 SSL과 TLS라는 두 개의 프로토콜이 사용되고 있다. SSL3.0을 기반으로 한 TLS1.0이 책정되어 1.1,1.2가 있다. TLS는 SSL을 바탕으로 한 프로토콜이지만, 이 프로토콜을 총칭해서 SSL이라고 부르기도 한다.
-> SSL은 느리다?SSL통신이 지연되는 이유 : 통신 속도가 떨어진다. CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려진다.
-네트워크의 부하는 HTTP를 사용하는 경우에 비해 2배~100배 정도 느려질 수 있다. TCP접속과 HTTP의 리퀘스트/리스폰스 이외에 SSL에 필요한 통신이 추가되기 때문에 전체적으로 처리해야 할 통신이 증가한다.
-SSL은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화나 복호화를 위한 계산을 할 필요가 있다. 따라서 서버나 클라이언트의 리소스를 소비하게 되어 HTTP에 비해 부담이 크다.
