HTTP & HTTPS: 웹 통신의 기초와 보안 버전의 차이

☀ HTTP (Hypertext Transfer Protocol)

클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜

• 사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고, 웹 서버는 HTTP 응답으로 응답한다.
• 웹 서버와 사용자 브라우저는 데이터를 일반 텍스트로 교환한다. 간단히 말해 HTTP 프로토콜은 네트워크 통신을 작동하게 하는 기본 기술이다.

작동 방식

• HTTP는 OSI (Open Systems Interconnection) 네트워크 통신 모델의 어플리케이션 계층 프로토콜이다.
• HTTP는 여러 유형의 요청과 응답을 정의한다. 예를 들어, 웹 사이트의 일부 데이터를 보려는 경우 HTTP GET 요청을 전송한다. 연락처 양식 작성과 같은 일부 정보를 전송하려는 경우 HTTP PUT 요청을 전송한다.
• 서버는 숫자 코드 및 데이터 양식으로 다양한 HTTP 응답을 전송한다.
  • 200 - OK (정상)
  • 400 - Bad request (잘못된 요청)
  • 404 - Resource not found (리소스 찾을 수 없음)

이러한 요청 및 응답 통신은 일반적으로 사용자에게 보이지 않는다. 브라우저와 웹 서버가 사용하는 통신 방식이므로 World Wide Web은 모든 사용자에게 일관되게 작동한다.

☀ HTTPS (Hypertext Transfer Protocol Secure)

더 안전한 HTTP의 확장 버전.

• HTTP는 암호화되지 않은 데이터를 전송하기 때문에, 브라우저에서 전송된 정보를 제 3자가 가로채고 읽을 수 있다. 이를 보완하기 위해 통신에 또 다른 보안 계층을 추가하기 위해 HTTPS로 확장되었다.
• 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정한다.
• CA (Certiicate Authority)
  • 클라이언트와 서버 간의 통신을 제 3자가 인증해주어야 한다. 이러한 일을 해주는 공인된 독립된 인증 기관을 CA라고 한다.
  • CA는 SSL 인증서를 기준으로 클라이언트가 접속한 서버가 맞는지 확인해준다.
• SSL 인증서
  • 클라이언트와 서버 간의 통신을 제 3자가 보증해주는 전자화된 문서이다.
  • 인증서를 통해 클라이언트가 접속한 서버가 신뢰할 수 있는 서버인지 판단하고, SSL 통신에 사용될 공개키를 클라이언트에게 전달한다.
  • SSL 인증서로 서버가 신뢰할 수 있는지 판단하기 위해서 공개키 서명 방식을 사용하는데, 이때 방식을 SSL/TLS Handshake라고 한다.
• HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합한다.

작동 방식

HTTPS 웹 사이트는 독립된 인증 기관(CA)에서 SSL/TLS 인증서를 획득해야 한다. 이러한 웹 사이트는 신뢰를 구축하기 위해 데이터를 교환하기 전에 브라우저와 인증서를 공유한다.

SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블된 데이터를 교환할 수 있다.

1. 서버 준비

   애플리케이션 서버를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.

2. CA와의 계약

   서버는 신뢰할 수 있는 CA(Certiicate Authority) 기업을 선택하고, 해당 CA에게 자신의 인증서 발급을 부탁하며 계약한다.

3. 인증서의 생성과 전달

   계약 완료된 CA 기업은 서버의 정보(서버의 공개키, 인증서의 유효기간, 발급자 정보)를 포함한 인증서를 생성하고, 이를 CA의 개인키로 서명하여 서버에게 제공한다. 클라이언트는 이 서명을 CA의 공개키로 검증할 수 있다.

4. 사용자 브라우저 접속

   사용자가 웹 브라우저를 통해 A서버에 https:// URL 형식으로 접속을 시도한다.

5. 인증서 요청과 전달

   브라우저는 서버의 SSL 인증서를 요청한다. 서버는 전자 서명된 인증서를 클라이언트에게 전송한다.

6. 인증서의 검증

   클라이언트의 브라우저는 이미 내장된 CA의 공개키로 인증서를 복호화한다. 이를 통해 서버의 공개키를 얻는다.

7. pre-master-key의 생성 및 전송

   • 클라이언트는 랜덤한 값를 생성하여 pre-master-key를 만든다. 이 값은 나중에 세션 키를 도출하기 위한 원본이 된다.
   • 클라이언트는 서버의 공개키(서버의 인증서에 포함되어 있음)를 사용하여 pre-master secret를 암호화하고, 이 암호화된 값을 서버에 전송한다.

8. (클라이언트 인증서)

   만약 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.

9. **pre-master secret의 수신 및 복호화**

   서버는 (클라이언트의 인증서를 확인 후) 자신의 개인키를 사용하여 클라이언트로부터 받은 암호화된 pre-master secret를 복호화한다. 이로써, 서버와 클라이언트 모두 동일한 pre-master secret 값을 가지게 된다.

10. 대칭키 생성

    이제 클라이언트와 서버는 각자 pre-master secret와 함께 핸드쉐이크 과정에서 교환된 다른 랜덤한 값들 (예: 클라이언트 랜덤, 서버 랜덤)을 결합하여 실제 세션 키를 생성한다. 이렇게 생성된 세션 키는 대칭키 암호화에 사용된다.

11. 대칭키 확인

    • 핸드쉐이크 과정에서 교환된 모든 메시지의 무결성을 확인하기 위한 과정
    • 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.
    • 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보낸다.

12. 암호화된 통신의 시작

    클라이언트와 서버가 세션 키를 확보한 후, 이 키를 사용하여 모든 메시지를 암호화 및 복호화하며 안전하게 통신한다.

☀ HTTP/2, HTTP/3, HTTPS의 차이점

HTTP/1.1

1996~1997년에 출시된 최초의 HTTP 버전이 HTTP/1.1이다.

특징

• 연결 당 하나의 요청: 각 HTTP 요청 및 응답은 별도의 TCP 연결에 대해 순차적으로 처리된다. 이로 인해 "헤드 오브 라인 블로킹"이라는 문제가 발생할 수 있다.
• Keep-Alive: 연결을 재사용하여 여러 요청을 수행할 수 있게 해서 연결 설정 오버헤드를 줄인다.
• 호스트 기반 가상 호스팅: 여러 도메인을 단일 IP 주소에 매핑할 수 있다.

HTTP/2

2015년에 표준화되었다. 프로토콜의 업그레이드 버전이다.

특징

• 다중화: 단일 TCP 연결에서 여러 요청 및 응답을 동시에 처리할 수 있습니다.
• 헤더 압축: HPACK 압축을 사용하여 헤더 데이터의 크기를 줄입니다.
• 서버 푸시: 서버가 클라이언트에게 미래의 요청에 필요한 리소스를 미리 보낼 수 있습니다.
• 이진 프로토콜: 이전의 텍스트 기반 프로토콜과 달리 HTTP/2는 이진 기반입니다.

⇒ 성능 향상을 위해 여러 기능을 도입했고, 헤더 압축 및 다중화와 같은 기능으로 속도를 향상시켰다.

HTTP/3

2020년대 중반에 표준화되기 시작했다.

특징

• QUIC 프로토콜: TCP 대신 QUIC을 사용하는 것이 주요 변경 사항이다. QUIC은 UDP 위에 구축된 새로운 전송 프로토콜로, 연결 설정 지연 시간을 줄이고 헤드 오브 라인 블로킹 문제를 해결한다.
• 보안 내장: QUIC은 기본적으로 TLS 암호화를 포함합니다.

⇒ QUIC을 도입하여 통신의 효율성과 속도를 더욱 향상시켰다.

HTTPS

HTTPS는 HTTP에서 데이터 보안 문제를 우선시한다. 최신 시스템에서는 SSL/TLS와 함께 HTTP/2를 HTTPS로 사용한다. HTTP/3이 더욱 발전하면 브라우저 및 서버 기술도 결국 HTTPS에 통합될 것이다.

특징

• 데이터 암호화: 중간자 공격이나 데이터 탈취에 대한 리스크를 줄인다.
• 데이터 무결성: 데이터가 전송 중에 손상되거나 변경되지 않았음을 보장한다.
• 인증: 사용자가 연결된 서버가 주장하는 서버임을 확신할 수 있게 해준다.

☀ HTTP보다 HTTPS를 선택하는 이유

HTTP와 비교했을 때 HTTPS의 장점

보안

HTTP 메시지는 일반 텍스트이므로, 권한이 없는 당사자가 인터넷을 통해 쉽게 액세스하고 읽을 수 있다. 반면, HTTPS는 모든 데이터를 암호화된 형태로 전송한다. 사용자가 민감한 데이터를 제출할 때 제 3자가 네트워크를 통해 해당 데이터를 가로챌 수 없음을 확신할 수 있다. 민감한 정보를 보호하려면 HTTPS를 선택하는 것이 좋다.

권위

검색 엔진은 HTTP의 신뢰성이 더 낮기 때문에 보통 HTTP 웹 사이트 콘텐츠의 순위를 HTTPS 웹 페이지보다 낮게 지정한다. 고객도 HTTP보다 HTTPS 웹 사이트를 더 선호한다. 사용자는 이러한 추가 보안 및 신뢰 요소 때문에 HTTPS 웹 사이트 및 어플리케이션을 선호한다.

성능 및 분석

• 성능

  HTTPS는 HTTP/2 프로토콜을 사용할 수 있는 기능을 제공한다. HTTP/2는 HTTP/1.1에 비해 여러 개선 사항을 도입하여 웹 페이지 로드 속도를 높인다. 이 개선 사항에는 병렬 요청 처리, 헤더 압축, 서버 푸시 등이 포함된다. 대부분의 주요 브라우저는 HTTP/2를 HTTPS 연결에서만 지원한다. 따라서 HTTPS를 사용하면 이러한 성능 향상을 경험할 수 있다.

• 분석

  HTTPS에서 HTTP로의 참조자(referrer) 데이터는 대부분 차단된다. 즉, HTTPS 웹 사이트에서 HTTP 웹 사이트로 이동할 때 원래의 웹 사이트에서 어떤 페이지를 방문했는지에 대한 정보는 전달되지 않는다.

  반대로, HTTPS 웹 사이트에서 다른 HTTPS 웹 사이트로 이동할 때는 참조자 데이터가 유지된다. 이것은 웹 사이트 소유자가 어디서 트래픽이 오는지 더 정확하게 알 수 있게 해주는 중요한 분석 데이터이다.

☀ 참고 자료

HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS

[브라우저에 URL 입력 후 일어나는 일들] 5_TLS/SSL Handshake