[Book - 그림으로 배우는 Http & Network Basic] 7. 웹을 안전하게 지켜주는 HTTPS
HTTP의 약점
- 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
- 통신 상대를 확인하지 않기 때문에 위장 가능
- 완전성을 증명할 수 없기 때문에 변조 가능
위 약점은 HTTP만이 아닌 다른 암호화하지 않은 프로토콜에도 공통되는 문제이다.
평문이기 때문에 도청 가능
HTTP를 사용한 Request나 Response 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않는다.
- TCP/IP는 도청 가능한 네트워크
- TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있다.
- 암호화 통신은 메시지 속의 의미는 간파할 수 없을 수도 있지만 암호화된 메시지 자체는 엿볼 수 있다.
- 인터넷은 모든 곳에서 통신 내용이 도청될 가능성이 있다.
- 네트워크 상을 흐르고 있는 패킷을 수집하는 것만으로 도청할 수 있다.
- 암호화로 도청 회피
통신 암호화
HTTP에는 암호화 구조는 없지만 SSL(Secure Socker Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다.
SSL을 조합한 HTTP를 HTTPS(HTTP Secure)나 HTTP over SSL이라 불리고 있다.
콘텐츠 암호화
HTTP에 암호화를 하는 기능은 없기 때문에 HTTP를 사용해서 운반하는 내용을 암호화 한다.
즉, HTTP 메시지에 포함되는 콘텐츠만 암호화한다.
주로 웹 서비스에서 이용되는 방법이다.
통신 상대를 확인하지 않기 때문에 위장 가능
Request를 보낸 서버가 정말로 URI에서 지정된 호스트인지 아닌지, Response를 반환한 클라이언트가 정말로 Request를 출력한 클라이언트인지 아닌지를 모른다.
누구나 Request 가능
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 Request를 보낼 수 있다. 또한, Request가 오면 상대가 누구든지 무언가의 Response를 반환한다.
HTTP는 누구이던 간엔 Request를 보내면 Response가 반환되는 쉬운 구조로 되어 있는만큼 상대를 확인하지 않아 아래와 같은 약점이 있다.
- 위장한 웹 서버일 우려가 있다.
- 위장한 클라이언트일 우려가 있다.
- 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
- 어디의 누가 Request를 했는지를 확인할 수 없다.
- 의미없는 Request라도 수신하게 되어 대량의 Request에 의한 DoS 공격(서비스 불능 공격)을 방지할 수가 없다.
상대를 확인하는 증명서
HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다.
증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다.
또한, 클라이언트가 증명서를 가짐으로써 보인 확인을 하고, 웹 사이트 인증에서 이용할 수도 있다.
완전성을 증명할 수 없기 때문에 변조 가능
완전성이란 정보의 정확성을 가리킨다.
즉, 완전성을 증명할 수 없다는 것은 정보가 정확한지 아닌지를 확인할 수 없음을 의미한다.
수신한 내용이 다를지도 모른다.
Request나 Response가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다 하더라도 이 사실을 알 수 없다.
이와 같이 공격자가 도중에 Request나 Response를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the Middle 공격)이라고 부른다.
변조 방지
파일 다운로드 서비스를 제공하는 있는 웹 사이즈에서는 파일을 작성했다는 증명을 위한 서명인 PGP와 단방향성 함수에 의한 해시 값인 MD5를 사용한다. 어느 쪽을 사용하더라도 클라이언트를 이용하고 있는 유저 자신이 다운로드 받은 파일을 토대로 검사할 필요가 있다.
SSL에는 인증이나 암호화, 다이제스트 기능을 제공하고 있기 때문에 확실히 방지하기 위해서는 HTTPS를 사용할 필요가 있다.
HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS
HTTP에 암호화나 인증 등의 구조를 더한 것을 HTTPS라고 부른다.
HTTPS는 SSL의 껍질을 덮어쓴 HTTP
HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체하고 있을 뿐이다.
SSL이나 TLS를 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 된다.
상호간에 키를 교환하는 공개키 암호화 방식
SSL에서는 공개키 암호화 방식을 사용한다.
이 암호화 방식은 공격자가 키를 알게 되면 암호화의 의미가 없어진다.
공통키 암호의 딜레마
암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 부른다.
두 개의 키를 사용하는 공개키 암호
공통키 암호의 문제를 해결하기 위해 서로 다른 두 개의 키 페어(쌍)을 사용한다.
한쪽은 비밀키(private key)라 부르고 다른 한쪽은 공개키(public key)라고 부른다.
공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다.
HTTPS는 하이브리드 암호 시스템
키를 안전하게 교환할 수만 있다면 공개키 암호만을 사용해서 통신을 해도 괜찮다고 생각할 지도 모르지만, 공개키 암호는 공통키 암호에 비해서 처리 속도가 늦다.
따라서, 키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.
공개키가 정확한지 아닌지를 증명하는 증명서
공개키 암호에도 공개키가 진짜인지 아닌지를 증명할 수 없는 문제점이 있다.
이 문제를 해결하기 위해 인증 기관(CA: Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다.
클라이언트를 확인하는 클라이언트 증명서
서버 증명서와 같이 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증을 할 수 있다.
클라이언트 인증은 비용을 들일 필요가 있는 곳에서만 사용되고 있다.
예시) 은행 인터넷 뱅킹에서의 클라이언트 증명서 요구
안전한 통신을 하는 HTTPS의 구조
Handshake: ClientHello
클라이언트가 Client Hello 메시지를 송신하면서 SSL 통신을 시작한다.
메시지에는 클라이언트가 제공하는 SSL의 버전을 지정하고, 암호 스위트(Cipher Suite)로 불리는 리스트(사용하는 암호화 알고리즘이나 키 사이즈 등) 등이 포함되어 있다.
Handshake: ServerHello
서버가 SSL 통신이 가능한 경우에는 Server Hello 메시지로 응답한다.
클라이언트와 같이 SSL 버전과 암호 스위트를 포함한다.
서버의 암호 스위트 내용을 클라이언트에서 받은 암호 스위트의 내용에서 선택된 것이다.
Handshake: Certificate
서버가 Certificate 메시지를 송신한다.
메시지에는 공개키 증명서가 포함되어 있다.
Handshake: ServerHelloDone
서버가 Server Hello Done 메시지를 송신하여 최초의 SSL 네고시에이션 부분이 끝났음을 통지한다.
Handshake: ClientKeyExchange
SSL의 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange 메시지로 응답한다.
메시지에는 통신을 암호화하는데 사용하는 Pre-Master secret이 포함되어 있다.
이 메시지는 3번의 공개키 증명서에서 꺼낸 공개키로 암호회되어 있다.
ChangeCipherSpec
클라이언트는 Change Cipher Spec 메시지를 송신한다.
이 메시지는 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타낸다.
Handshake: Finished
클라이언트는 Finished 메시지를 송신한다.
이 메시지는 접속 전체의 체크 값을 포함하고 있다.
네고시에이션이 성공했는지 어떤지는 서버가 이 메시지를 올바르게 복호화할 수 있는지 아닌지가 결정된다.
ChangeCipherSpec
서버에서도 마찬가지로 Change Cipher Spec 메시지를 송신한다
Handshake: Finished
서버에서도 마찬가지로 Finished 메시지를 송신한다
Application Data (HTTP)
서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의해서 접속은 확립된다.
물론 통신은 SSL에 의해서 보호되고 있다.
이제부터는 애플리케이션 계층의 프로토콜에 의해 통신을 한다.
즉, HTTP request를 송신한다.
Application Data (HTTP)
애플리케이션 계층의 프로토콜에 의한 통신이다.
즉, HTTP Response를 송신한다.
Alert: warning, close notify
마지막에 클라이언트가 접속을 끊는다.
접속을 끊을 경우에는 close_notify 메시지를 송신한다.
이후에는 TCP FIN 메시지를 보내 TCP 통신을 종료한다.
애플리케이션 계층의 데이터를 송신할 때 MAC을 이용하면 변조를 감지할 수 있어서 완전성 보호를 실현할 수 있다.
SSL은 느리다
SSL을 사용하면 처리가 늦어지게 된다는 점에서 HTTPS에도 문제가 있다.
통신 속도가 떨어지는 점
TCP 접속과 HTTP의 Request/Response 이외에 SSL에 필요한 통신이 추가되기 때문에 전체적으로 처리해야 할 통신이 증가한다. 따라서, 네트워크 부하가 HTTP를 사용하는 경우에 비해 2배에서 100배 정도 느려질 수 있다.
CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려지는 점
SSL은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서는 암호화나 복호화를 위한 계산을 할 필요가 있어서 HTTP에 비해 부담이 커진다.
항상 HTTPS를 사용하지 않는 이유
평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하기 때문에 HTTPS를 계속해서 사용하지 않는다.
따라서, 민감한 정보를 포함하지 않는 통신에서는 HTTP를 사용하고 개인 정보 등 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다.
또한, HTTPS를 사용하기 위해서는 CA에서 증명서를 구입해야 하기 때문에 증명서의 구입 비용이 부담되는 서비스나 개인적인 웹 사이트 등에서는 HTPP만 선택하는 경우도 있다.