[Network] HTTP and HTTPS

yongkini ·2021년 9월 24일
0

Network

목록 보기
2/5
post-custom-banner

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를 쓰는 방향으로 나아가고 있다.
profile
완벽함 보다는 최선의 결과를 위해 끊임없이 노력하는 개발자
post-custom-banner

0개의 댓글