HTTP와 HTTPS

🐰 HTTP ( HyperText Transfer Protocol )

공통된 개념

• TCP/IP의 최상위 계층(4계층:응용계층)에서 클라이언트-서버간의 리소스 요청-제공을 담당하는 프로토콜입니다.
  • 클라이언트는 리소스를 요청(Request)하고, 서버는 리소스를 제공(Response)합니다.
    
    
• 상태를 유지하지 않는 무상태성(Stateless) 프로토콜입니다.
  • 이전에 클라이언트에서 보냈던 Request나 이미 되돌려준 Response에 대해서는 전혀 기억하지 않습니다.
  • 새로운 Request에는 새로운 Response가 생성됩니다.
  • 많은 데이터를 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위해 다음과 같이 설계되었습니다.
  • 해당 문제를 해결하기 위해 쿠키나 세션 또는 토큰 방식의 OAuth 및 JWT가 사용되어 HTTP 통신상태에서도 상태를 계속 관리할 수 있게 되었습니다.
    
    
• Request URI로 리소스를 식별합니다.
  
  

버전별 특징(HTTP 1.0 기준)

• 초기 버전(HTTP 1.0) : 비-연결지향(Connectionless)
  • HTTP 통신을 한 번 할때마다 TCP에 의해 연결-종료를 할 필요가 있었습니다. 👉🏻 한번 Request, Response를 주고받으면 연결을 끊음
  • 서버의 부담을 줄일 수 있지만, 리소스 요청시마다 오버헤드가 발생해 더 많은 부하를 발생시킬 가능성이 있습니다.
  • Request Header의 Connection 속성에 keep-alive를 적용해 연결 상태를 유지할 수 있습니다.
    
    
• 현재 버전(HTTP 1.0 이후) : 지속 연결(Persistent Connections), 파이프라이닝(Pipelining)
  • 서버 또는 클라이언트에서 명시적으로 연결을 종료하지 않는 이상 TCP 연결(TCP Connection)을 계속 유지합니다.
  • TCP 연결/해제를 위한 오버헤드가 줄어, 서버에 대한 부하가 경감됩니다.
  • HTTP Request, Response가 빠르게 완료되기 때문에, 웹 페이지를 빨리 표시할 수 있습니다.
  • HTTP 파이프라이닝(Pipelininig) 기능이 추가되어 Request를 병행해서 보내는 것이 가능해졌습니다.
    👉🏻 Communication Latency 감소

🐰🐰 HTTPS ( HTTP Secure )

HTTPS = HTTP + 암호화 + 증명서 + 완전성

• HTTP의 보안적 약점을 보완한 프로토콜 입니다.
  • HTTP의 보안적 약점과 보완 방법
  1. 평문(암호화 하지 않은) 통신이기 때문에 도청이 가능합니다.
     • 패킷 캡처나 스니퍼라는 툴을 이용하면, 패킷을 수집할 수 있습니다.
       👉🏻 HTTPS는 통신, 콘텐츠 암호화를 통해 이를 해결합니다.
  2. 통신 상대를 확인하지 않기 때문에 위장이 가능합니다.
     • 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버가 맞는지 확인 할 수 없습니다.
     • 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 확인할 수 없습니다.
     • 통신하고 있는 상대가 접근이 허가된 상대인지 확인할 수 없습니다.
       👉🏻 HTTPS는 인증서(Certification)를 통해 이를 해결합니다.
  3. 완전성을 증명할 수 없기 때문에 변조가 가능합니다.
     • 완전성은 정보의 정확성을 말합니다.
     • 발신된 Request, Response나 수신된 Request, Response가 같은지를 확인할 수 없습니다.
     • 중간자 공격(Man-in-the-Middle)을 받아 도중에 Request, Response를 변조할 가능성이 있습니다.
       👉🏻 HTTP로 완전성을 증명하는 완벽한 방법✨이 없으므로, HTTPS를 사용해야 합니다. 인증, 암호화, 다이제스트 기능 제공
       
       

HTTPS의 주요 개념

• SSL(Secure Socket Layer)나 TLS(Transport Layer Security)라는 프로토콜을 조합하여 안전한 통신로를 확립(전송 계층에서 신뢰성 확보)하고 나서 그 통신로를 통해 HTTP 통신을 합니다. 👉🏻 통신 암호화
  

• HTTP 자체를 암호화하는 것이 아니라, HTTP를 사용해서 운반하는 내용(HTTP Message의 Body)을 암호화합니다. 👉🏻 콘텐츠 암호화

  • HTTP Body 부분에 들어가는 콘텐츠를 암호화 합니다.
  • 통신을 나타내는 HTTP Header는 암호화하지 않습니다.
    
    

• SSL(또는 TLS)에서 사용하는 인증서로 상대방을 확인할 수 있습니다.
  👉🏻 인증서 사용 -> 인증성, 기밀성
  

  • 인증서는 신뢰할 수 있는 제 3자에 (CA(Certificate authority) 혹은 Root Certificate)의해 발행됩니다.
    
    

• HTTPS에서는 대칭키 암호화 기법을 사용합니다.

  • 공개키의 신뢰성을 위해 CA 인증서를 사용합니다.
  • 그 인증 과정은 다음과 같습니다.
    1. 서버의 공개키를 인증 기관(CA)에 등록합니다.
    2. 인증 기관은 해당 서버의 유효성을 판단한 후, 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 인증서를 작성 후 등록합니다.
       👉🏻 공개키 인증서 = 서버의 공개키 + 인증 기관의 디지털 서명 + 암호화 된 사이트 정보
       ⭐️ 인증 기관의 공개키는 사전에 브라우저에 내장되어 있습니다.
    3. 클라이언트가 서버에 접속요청을 하면 서버는 인증 기관에서 받은 인증서를 보냅니다.
    4. 클라이언트는 브라우저에 내장된 인증 기관의 공개키로 디지털 서명을 검증해 신뢰할 수 있는 공개키인지 확인합니다.
    5. 클라이언트는 대칭키를 생성합니다. (공개키, 비밀키)
    6. 클라이언트는 생성한 공개키를 서버의 공개키로 암호화해 서버에게 전송합니다.
    7. 서버는 자신의 비밀키로 해당 내용을 복호화하고 그 대칭키를 가지고 리소스를 주고 받습니다.
  • 해당 과정의 및 원리에 대한 자세한 내용은 도난 당한 패스워드 책을 참고하면 좋을 것 같습니다.
    
    

• HTTPS는 SSL이 통신 속도가 떨어지고, CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리 속도가 HTTP보다 느립니다.

  • 그러나, 최근 CPU의 성능 및 메모리 용량이 크게 향상되면서, 속도가 느리다로 정의할 수 없게 되었습니다.
  • UDP를 기반으로 하는 최신 전송 프로토콜(QUIC)를 사용하는 HTTP/3에서는 QUIC는 전송 프로토콜 자체에서 일반적으로 상위 계층 프로토콜 (예 : TLS)에 의해 처리되는 인증 및 암호화와 같은 보안 기능을 제공하기 때문에 해당 오버헤드가 감소하였습니다. 참고
    

개인적으로 공부한 내용을 정리한 것입니다. 오타나 제안 사항이 있으시면 댓글로 지적 부탁드리겠습니다.🙇🏻‍♀️

Reference

• JBee님의 Interview_Question_for_Beginner
• baeharam님의 Must-Know-About-Frontend
• MDN - HTTP의 진화
• 생활코딩 - HTTPS와 SSL인증서
• 도서 - 그림으로 배우는 Http & Network Basic(영진닷컴)
• 이미지 출처
  • HTTPS 구조
  • 인증서
  • HTTPS 동작방식, QUIC 동작방식