[Network] HTTP와 HTTPS에 관하여

HTTP는 클라이언트와 서버 간 통신의 프로토콜로, 백엔드 개발자는 이 프로토콜을 이해해야 효율적인 API와 서비스를 개발할 수 있다. 최근 많이 사용하는 RESTful API를 개발할 때도, HTTP는 필수적인 개념이다. 개발자는 각 상황에 적합한 HTTP 메서드(GET, POST, PUT, DELETE 등)를 선택하고, 적절한 상태 코드를 반환함으로써 일관되고 직관적인 API를 개발할 수 있어야 한다. 하지만 HTTP는 데이터가 평문으로 전송되기 때문에 보안이 취약하다는 문제점이 있다. 이를 해결하기 위해 SSL/TLS 암호화를 더한 HTTPS가 등장했다. 따라서, 백엔드 개발자는 HTTP와 HTTPS에 대해 철저히 이해하고 있어야 한다. 

 

HTTP에 관하여

HTTP(Hyper Text Transfer Protocol)은 웹에서 클라이언트와 서버 간 데이터를 주고받기 위한 애플리케이션 계층의 통신 프로토콜이다. HTTP 메세지는 텍스트 기반 형식으로 다음과 같이 생겼다. 

 

HTTP의 특징

1. 비연결성
   서버는 클라이언트의 요청에 응답한 후 연결을 유지하지 않는다. 이는 서버 리소스를 효율적으로 사용할 수 있게 하지만, 매 요청마다 새로운 TCP 연결해야 하므로 오버헤드가 크다. (HTTP/1.1은 Keep-Alive 헤더를 통해 여러 요청/응답을 하나의 TCP 연결로 처리한다. 클라이언트는 응답을 기다리지 않고 여러 요청을 연속적으로 전송하고, 서버는 요청 순서대로 응답을 처리하여 전송한다. 큰 응답이 작은 응답을 차단하는 블로킹 문제가 있어 대부분의 브라우저에서 비활성화된다.)
   
   
2. 무상태(Stateless)
   각 요청은 독립적이며, 서버는 이전 요청의 상태를 저장하지 않는다. 이러한 특징 때문에 세션 관리나 사용자 인증을 위한 쿠키, 세션, 토큰 등이 필요하다. 
   
   
3. 요청-응답 구조
   클라이언트가 요청을 보내면 서버는 응답을 반환하는 통신 방식이다. 

 

HTTP 통신 기본 흐름

1. 클라이언트가 서버와 TCP 연결
2. 클라이언트가 HTTP 요청을 서버로 전송
3. 서버가 요청을 처리
4. 서버가 HTTP 응답을 클라이언트에게 전송
5. HTTP 버전에 따라 연결을 종료하거나 유지

 

HTTP 메세지 구조

HTTP 요청 메세지

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: sessionId=abc123; userId=johndoe
Cache-Control: max-age=0

• `GET /index.html HTTP/1.1`
  • HTTP 메서드: GET
  • 요청 경로: /index.html
  • HTTP 버전: HTTP/1.1
• `Host: www.example.com` - 요청하는 호스트 서버 정보
• `User-Agent` - 클라이언트 정보
• `Accept` - 클라이언트가 처리할 수 있는 컨텐츠 타입
• `Accept-Language` - 선호하는 언어
• `Accept-Encoding` - 지원하는 압축 방식
• `Connection: keep-alive` - 연결 유지 요청
• `Cookie` - 서버에 전송되는 쿠키 정보 (세션 ID와 사용자 ID)
• `Cache-Control: max-age=0` - 캐시 저장하지 않고 매번 서버에 확인

 

HTTP 응답 메세지

HTTP/1.1 200 OK
Date: Mon, 23 May 2022 22:38:34 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2022 23:11:55 GMT
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

• `HTTP/1.1 200 OK`
  • HTTP 버전: HTTP/1.1
  • 상태 코드: 200
  • 상태 메세지: OK
• `Date: Mon, 23 May 2022 22:38:34 GMT` - 응답이 생성된 날짜와 시간
• `Server: Apache/2.4.41 (Ubuntu)` - 서버 소프트웨어 정보
• `Content-Type: text/html; charset=UTF-8` - 응답 본문의 미디어 타입과 문자 인코딩
• `Content-Length: 138` - 응답 본문의 길이
• `Last-Modified: Wed, 08 Jan 2022 23:11:55 GMT` - 리소스가 마지막으로 수정된 시간
• `ETag: "3f80f-1b6-3e1cb03b"` - 리소스의 특정 버전을 식별하는 태그(캐싱에 사용)
• `Accept-Ranges: bytes` - 서버가 범위 요청을 지원함을 나타냄
• `Connection: close` - 응답 후 연결을 닫음

 

HTTP 버전별 특징

1. HTTP/1.0
   • 단순한 요청-응답 모델
   • 연결당 하나의 요청만 처리 (비연결성)
2. HTTP/1.1
   • Keep-Alive 연결을 통해 여러 요청-응답을 하나의 TCP에서 처리 ➡️ 파이프라이닝
   • HOL 블로킹 문제 발생
3. HTTP/2
   • 텍스트 기반 프로토콜에서 바이너리 프로토콜로 변경 ➡️ 효율적인 파싱과 처리 가능
   • 멀티플렉싱을 지원 ➡️ 하나의 TCP 연결 내에서 다수의 요청과 응답을 동시에 처리 가능, 각 요청과 응답은 스트림이라는 독립적인 양방향 시퀀스로 식별해, 스트림 ID를 사용하여 여러 메세지가 뒤섞여도 올바르게 재조합이 가능 ➡️ HOL 블로킹 문제 해결
4. HTTP/3
   • UDP 기반 QUIC 프로토콜 사용
   • 첫 연결에서 통합된 핸드셰이크를 사용해 1-RTT만 소요

 

HTTP 메서드

HTTP 메서드는 클라이언트가 서버에게 요청의 목적과 종류를 알려주는 방법이다.

1. GET: 리소스 조회
   • 서버로부터 데이터를 요청할 때 사용한다.
   • URL에 데이터가 노출되므로 보안이 취약하다.
   • 요청 본문을 가질 수 없다.
2. POST: 리소스 생성 및 데이터 제출
   • 서버에 데이터를 전송하여 새 리소스를 생성할 때 사용한다.
   • 요청 본문에 데이터를 포함한다.
   • 멱등성이 보장되지 않는다.
3. PUT: 리소스 전체 수정
   • 리소스를 완전히 대체할 때 사용한다.
   • 멱등성이 보장된다. (같은 요청을 여러 번 보내도 결과가 동일하다.)
4. PATCH: 리소스 부분 수정
   • 리소스의 일부만 수정할 때 사용한다.
   • 멱등성이 보장되지 않을 수 있다.
5. DELETE: 리소스 삭제
   • 지정된 리소스를 삭제할 때 사용한다.
   • 멱등성이 보장된다. 

 

HTTP의 문제점

HTTP는 데이터를 평문으로 전송하기 때문에 네트워크 경로 상의 어느 지점에서든 패킷을 캡쳐하면 그 내용을 그대로 읽을 수 있다. HTTP 통신은 여러 네트워크 장비를 통과하며, 공격자가 쉽게 패킷을 가로챌 수 있는데 상대방의 신원을 확인하는 인증이 없어 공격자가 중간에 통신을 가로채도 클라이언트나 서버가 이를 감지할 수 없다. 

 

 

 

HTTPS에 관하여

HTTPS = HTTP + TLS(SSL) 이다. 위의 HTTP의 문제점을 해결하기 위해 암호화를 추가했다. HTTPS는 데이터 암호화를 통해 패킷이 캡쳐되어도 제3자는 내용을 읽을 수 없다. 또, MAC(Message Authentication Code) 또는 HMAC(Hash-based Message Authentication Code)를 통해 데이터 무결성을 보장하고, 디지털 인증서와 PKI(Public Key Infrastructure)를 통해 클라이언트가 통신하고 있는 서버가 신뢰할 수 있는 서버인지 확인할 수 있는 인증을 제공한다. 

💡SSL와 TLS란?
SSL과 TLS는 모두 보안 프로토콜이며 사실상 같은 프로토콜이다. SSL이 먼저 개발되었으며, TLS은 SSL의 후속 버전이다. 현재는 보안상의 이유로 SSL은 완전히 폐기되고 TLS1.2, TLS1.3 프로토콜만 사용한다. SSL이 일반적으로 사용되지만 더 정확한 표현은 TLS이다. 

 

HTTPS의 암호화

HTTPS는 비대칭 암호키와 대칭 암호키를 사용한다. 

 

비대칭 암호키(공개키 암호화)

비대칭 암호키는 공개키와 개인키를 사용하는 방식이다. 공개키는 누구나 접근 가능하며, 이 키로 암호화된 데이터는 개인키로만 복호화할 수 있다. 개인키는 소유자만 접근 가능하며, 이 키로 암호화된 데이터는 공개키로만 복호화할 수 있다. 

비대칭 암호키는 키 분배 문제를 해결하지만, 적은 양만 암호화가 가능하며 키의 길이가 길어 속도가 느리다.

대칭 암호키

대칭 암호키는 암호화와 복호화에 동일한 키를 사용하는 방식이다. 같은 키를 사용하기 때문에 키 분배에 문제가 발생한다. 하지만 많은 의 암호화가 가능하고 키가 짧아 속도가 빠르다. 

 

CA와 디지털 인증서

CA는 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제 3자 기관이다. 기존 HTTP는 상대방의 신원을 확인하는 인증이 없어 중간자 공격에 취약했다. CA가 발급한 디지털 인증서를 서버가 클라이언트에 전송하면 클라이언트는 디지털 인증서를 검증해 서버의 신원을 확인할 수 있다. 클라이언트는 서버로 받은 디지털 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인하고 인증서에 포함된 CA의 디지털 서명을 CA의 공개키로 검증한다. 인증서에 명시된 도메인 이름이 실제로 접속한 도메인과 일치하는지 확인한 후 인증서의 유효기간이 만료되었는지 확인해 서버가 진짜임을 신뢰하고 통신을 진행한다.

💡 CA의 신뢰성은 어떻게 보장될까?
CA는 계증척 구조로 설계되어 있다. 
1. 루트 CA: 신뢰의 최상위 기관으로, 자체 서명된 인증서를 가지며 오프라인 환경에서 관리된다.
2. 중간 CA: 루트 CA에 의해 인증되어 실제 인증서 발급 업무를 수행한다. 
3. 최종 인증서: 웹 사이트나 서비스에 발급되는 인증서이다. 
이 구조를 통해 루트 CA의 노출을 최소화하고, 문제가 발생하면 피해 범위를 제한할 수 있다. 

 

 

TLS/SSL 핸드셰이크 과정

HTTPS가 연결될 때 클라이언트와 서버는 TLS 핸드셰이크라는 과정을 거친다.

1. Client Hello
   클라이언트가 서버에게 보내는 첫 메세지이다. 클라이언트는 다음 정보들을 포함해 보낸다:
   • 클라이언트가 지원하는 가장 높은 TLS(SSL) 버전
   • 클라이언트의 무작위 데이터(나중에 세션 키 생성에 사용)
   • 세션 ID
   • 클라이언트가 지원하는 암호화 알고리즘 목록
2. Server Hello
   Client Hello에 대한 서버의 응답 메세지이다. 서버는 다음 정보들을 포함해 보낸다:
   • 서버가 지원하는 가장 높은 버전의 TLS(클라이언트가 제안한 버전 중)
   • 서버의 무작위 데이터(나중에 세션 키 생성에 사용)
   • 세션 ID
   • 클라이언트가 제공한 암호화 알고리즘 중 선택한 암호화 알고리즘
3. 인증서 전송
   서버가 자신의 신원을 증명하기 위해 디지털 인증서를 전송한다. 서버는 다음 정보들을 포함해 보낸다:
   • 서버의 공개키
   • 서버 도메인 이름
   • 인증서 발급자 정보
   • 유효 기간
   • 디지털 서명(CA의 개인키로 서명)
4. 키 교환(서버 키 교환)
   선택한 암호화 알고리즘에 따라 서버가 추가 키 파라미터를 전송한다.
5. 서버 핸드셰이크 종료
6. 클라이언트 키 교환
   클라이언트가 pre-master secret을 생성하고 서버에 전송한다.
7. pre-master secret에서 master secret 생성
   클라이언트와 서버 양쪽에서 독립적인 master secret을 생성한다. (이 때, 1번과 2번에서 서로 주고 받은 무작위 데이터를 사용한다.)
8. master secret에서 실제 암호화와 무결성 보호에 사용할 여러 키들을 추출