HTTP의 한계
- HTTP 와 같이 암호화하지 않은(평문 통신인) 프로토콜은 도청 가능, 위장가능, 변조 가능 의 위험성을 가지고 있다.
- TCP/IP는 전세계 적으로 연결된 네트워크로 되어있고 내가 보내는 통신이 다른 사람 소유의 케이블을 거의 반드시 지나가게 된다. 따라서 악의를 가진 누군가가 통신내용을 엿볼 수 있다.
서버는 통신 상대를 확인하지 않기 때문에 위장 가능
HTTP를 사용한 리퀘스트나 리스폰스는 통신상대를 확인하지 않기 때문에 누구나 리퀘스트할 수 있다. 따라서 접근이 허가된 클라이언트에게만 정보를 제공하는 것도 하지 못한다. 만약 의미없는 대량의 리퀘스트가 들어온다면 (DoS 공격) 속수무책으로 당하게 된다.
이럴 경우 SSL로 증명서를 발급해서 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.
완전성을 증명할 수 없기 때문에 변조 가능
HTTP가 완전성을 증명할 수 없다는 것은 클라이언트가 수신할 때까지의 사이에 변조되었다고 하더라도 이 사실을 알 수 없다는 뜻이다.
이렇게 응답 중간에 리퀘스트와 리스폰스를 빼앗아서 변조하는 것을 중간자 공격이라고 한다.
이를 방지하기 위해서는 MD5나 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 있다. 하지만 확실히 방지하지는 못한다.
이와 같은 HTTP의 한계는 암호화를 통해서 해결할 수 있다.
1. 통신 암호화
SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)와 같은 다른 프로토콜을 조합해서 통신을 암호화할 수 있다. 즉, 안전한 통신로를 확립하고 나서 HttpRequest를 보내는 것이다.
2. 콘텐츠 암호화
이는 통신 자체는 암호화되지 않고, request 메시지 바디에 들어가는 콘텐츠를 암호화하는 방법이다. 물론 클라이언트와 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 것이 전제가 된다. 주로 웹 서비스에서 이용되는 방법이다.
HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS(HTTP Secure)라고 부른다.
HTTP 통신을 소켓하는 부분을 SSL이나 TLS라는 프로토콜로 대체하고 있는 것이다.
SSL에서는 공개키 암호화 방식이라는 불리는 암호화 방식을 한다.
공개키 방식에서는 서로 다른 두 개의 키 쌍을 사용하는데 한쪽은 비밀키(private key), 다른 한 쪽은 공개키(public key)라고 부른다.
이와 반대되는 개념으로 공통키(대칭키) 암호화 방식이 있다. 공통키는 상대방에게 키를 넘겨줘야 하기 때문에 사실상 중간에 키를 빼앗기게 될 경우 암호화의 의미가 없게 된다. 하지만 공개키 방식보다 처리 속도가 빠르기 때문에 HTTPS는 필요할 때만 공개키 방식을 사용하는 하이브리드 방식을 채택하고 있다.
공개키를 증명하는 증명서
공개키가 진짜인지를 증명해야 하는데 이 문제를 해결하는데 인증기관(CA: Certificate Authority)에서 발행한 증명서가 이용된다. 인증기관와 증명서 발급의 순서는 다음과 같다.
- 서버의 공개키를 인증 기관에 등록
- 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성 등록
- 서버의 공개키 증명서를 입수하고, 디지털 서명을 인증 기관의 공개 키로 검증하고 공개키가 진짜인지 확인
- 서버의 공개키로 암호화해서 메시지를 송신 기관에 등록
- 서버의 비밀키로 메시지를 복호화
안전한 통신을 하는 HTTPS의 구조
1) Client Hello의 메시지 전송으로 SSL 통신 시작
2) Server Hello 메시지로 응답하면서 SSL 버전과 암호 스위트 포함
3) 서버가 공개키 증명서가 포함된 Certificate 메시지 송신
4) 서버가 Server Hello Done 메시지 송신하여 최초 네고시에이션 끝났음을 통지
5) 최초 네고시에이션 종료 시 Client Key Exchange 메시지로 응답
6) 클라이언트는 앞으로 암호키 사용해서 진행한다는 Change Cipher Spec 메시지를 전송
7) 클라이언트는 Finished 메시지 전송
8) 서버도 Change Cipher Spec 메시지 전송
9) 서버도 Finished 메시지 송신
10) Finished 메시지 교환 완료 시 SSL 접속 확립 후 HTTP 리퀘스트 송신
11) HTTP 리스폰스 송신
12) 클라이언트가 close_notify메시지 송신 후 접속 종료
그러나 SSL은 느리다
SSL은 통신 속도가 떨어지는 것과, CPU나 메모리 리소스를 다량으로 소비함으로써 처리가 느려진다. 이 부하는 HTTP에 비해 2배에서 100배 가량 느려질 수 있다.
이와 더불어 HTTPS는 속도가 느리다는 점과 인증서를 발급하기 위해 증명서의 구입비용을 지불해야 한다는 점 때문에 항상 사용하지는 않는다.
