HTTPS에 대하여
: HTTPS = HTTP + [SSL(Secure Socket Layer) or TLS(Transport Layer Security)]
HTTP 의 문제점
- HTTP 는 평문 통신(암호화되지 않은 통신)이기 때문에 도청이 가능하다.
: TCP/IP 형태의 통신은 중간에 패킷을 엿볼 수 있다. 따라서 평문을 사용하는 HTTP는 중간에 메시지 도청이 가능하게 된다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
: 어디서 리퀘스트를 보냈는지, 어디다 리스폰스를 보내는건지 확인할 수 없다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
: 중간자 공격(man in the middle)이 발생해도 그걸 알아챌 수도 없다. 즉, 송신자측에서 보낸 정보가 수신자측에서 받은 정보와 일치한다는 확신(정보의 정확성)을 할 수 없는 것이다.
해결방안
- HTTP가 평문 통신이라는 점을 보완하기 위해 통신 자체를 암호화해버리는 것이다. HTTP에 또다른 프로토콜인 SSL(Secure Socket Layer) 혹은 TLS(Transport Layer Security) 를 조합해서 암호화 하는 방법으로 도청을 막을 수 있다.
- HTTP가 리퀘스트를 보내오는 상대 혹은 리스폰스를 받는 상대를 알 수 없다는 점을 보완하기 위해 역시 SSL을 이용해서 해결할 수 있다. SSL을 사용하면 신뢰할 수 있는 제3의 기관을 통해 증명서를 클라이언트에게 발급할 수 있고, 그 발급한 증명서를 통해 해당 클라이언트가 검증된 유저인지 알 수 있다. 또한, 유저는 증명서를 통해 해당 사이트에서 인증을 받을 수 있다.
- 중간자 공격 등을 막기 위해 MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 중간자 공격과 같은 송신자의 메시지와 수신자가 받은 메시지가 중간에 바뀌는 일 등을 방지하기에는 HTTPS를 사용해야 한다. SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.
HTTPS 정리
- HTTP 에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS
- 본래 HTTP는 TCP와 직접 통신했지만, HTTPS에서는 HTTP는 SSL과 통신하고, SSL이 TCP와 직접 통신하게 된다.
- 이렇게 좋은(?) HTTPS를 모든 웹 통신에서 사용해도 될까? 라는 질문에 예전에는 암호화 등의 방식에서 CPU, 메모리 등의 리소스 사용량이 늘어났기에 모든 통신을 대체하기에는 벅찼을 수 있으나, 요즘은 하드웨어 적으로 메모리 량도 충분히 늘어났기에 HTTPS를 사용한다해서 리소스의 사용량이 늘어남에 따라 비효율성이 생기지 않기에 (새로운 표준인 HTTP 2.0을 사용하면 오히려 빠름) 모든 웹페이지에서 HTTPS를 쓰는 방향으로 나아가고 있다.