[7장]

HTTP의 약점

• 평문(암호화하지 않은) 통신이기 때문에 도청 가능

  • TCP/IP는 도청 가능한 네트워크
    
    TCP/IP 구조 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있기에 통신 경로 상에 있는 네트워크 기기 등을 전부 자신이 소유하고 있는 일은 있을 수 없습니다.
    
    
  • 암호화로 도청을 피하다
    
    1) 통신 암호화 : HTTP엔 암호화 구조가 없으나, SSL, TLS 암호화 프로토콜을 조합하여 안전한 통신로를 확보한 뒤 HTTP 통신 내용을 암호화할 수 있다.
    
    2) 컨텐츠 암호화 : HTTP 메시지에 포함되는 컨텐츠만을 암호화하는 것을 의미한다.

• 통신 상대를 확인하지 않기 때문에 위장 가능

  • 누구나 리퀘스트할 수 있다.
    
    HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기에 누구든지 리퀘스트를 보낼 수 있어, 의미없는 리퀘스트라도 수신하게 된다.
    
    
  • 상대를 확인하는 증명서
    
    HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있다.
    SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있다.

• 완전성을 증명할 수 없기 때문에 변조 가능

  • 완전성이란 정보의 정확성을 의미한다.
  • 완전성을 증명할 수 없다는 것은 수신한 정보가 정확한지 아닌지를 확인할 수 없음을 의미한다.

HTTPS : HTTP + 암호화 + 인증 + 완전성 보호

• HTTPS는 HTTP 통신을 하는 소켓 부분을 SSL or TLS라는 프로토콜로 대체하고 있을 뿐이다.
  => HTTP : HTTP -> TCP -> IP
  => HTTPS : HTTP -> SSL or TLS -> TCP -> IP

상호 간에 키를 교환하는 공개키 암호화 방식

• 공통키 암호의 딜레마

  • 암호화와 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 한다.
  • 네트워크를 사용해서 키를 넘겨줄 때 통신이 도청되어 공격자에게 키를 빼앗기게 되면 암호화의 의미가 없다.
  • 또한, 받은 키를 안전하게 보관하기 위한 노력을 하지 않으면 안된다.

• 두 개의 키를 사용하는 공개키 암호

  • 공통키 암호의 문제를 해결하려고 한 것이 공개키 암호라는 방식이다.
  • 공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화를 한다. (공개키를 사용하여 데이터 암호화)
  • 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 실시한다. (비밀키를 사용하여 데이터 복호화)
  • 이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해 키를 빼앗길 걱정이 없다.

• HTTPS는 하이브리드 암호 시스템

  • HTTPS : 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템
  • 키를 안전하게 보관할 수 있다면, 공개키 암호만을 사용해서 통신을 해도 괜찮을지 모르나,
    공개키 암호는 공통키 암호에 비해 처리 속도가 늦기에 모든 통신에 공개키 암호를 사용하는 것은 비효율적이다.

---

SSL & TLS

• HTTPS는 서버, 클라이언트 모두 암호화, 복호화 처리가 필요하기 때문에 CPU나 메모리 등의 하드웨어 리소스를 소비한다.

• HTTPS 통신만큼이나, SSL 또한 통신 처리에 시간이 걸린다.

• 참고로 TLS는 SSL 바탕으로 한 프로토콜로 총칭하여 SSL이라고 부르곤 한다.

| SSL 통신이 지연되는 이유

1. TCP 접속과 HTTP 리퀘스트, 리스폰스 이외 SSL에 필요한 통신이 추가되기에 전체적으로 처리해야 할 통신이 증가하기 때문
2. SSL은 반드시 암호화 처리를 하기에 그에 대한 서버, 클라이언트의 리소스가 소비되어 HTTP에 비해 부담이 커진다.