[WEB] HTTP/HTTPS 알아보기

웹을 사용하면서 가장 자주 접하는 HTTP와 HTTPS에대해서 알아보자.

---

HTTP

Hyper Text Transper Protocol의 약자로, 문서나 데이터를 교환하기 위한 텍스트 기반 프로토콜이다. 

웹에서 사용하던 프로토콜이었지만, 현재는 gRPC나 패키지 다운로드(NPM, Maven 등) 등 에서도 사용하며 범용적인 프로토콜이 되었다.

 

구조적 특징

1. 클라이언트-서버 구조
   • 클라이언트(브라우저, 앱)가 요청(Request)을 보내고, 서버가 응답(Response)을 돌려주는 구조
2. Stateless (무상태)
   • 요청 간에 상태를 저장하지 않음.
   • 예: 로그인 상태 유지가 필요하면 쿠키/세션/토큰 같은 별도 메커니즘 필요.
3. Connectionless (단일 요청-응답 후 종료)
   • 기본적으로 한 번 요청-응답이 끝나면 연결이 종료됨.
   • 다만 HTTP/1.1의 Keep-Alive, HTTP/2/3의 멀티플렉싱으로 이 단점을 보완.

 

기술적 특징

1. 텍스트 기반 프로토콜
   • 바이너리 기반 프로토콜(gRPC의 Protobuf, IP/UDP/TCP 헤더 등)과 는 달리 사람이 읽고 이해할 수 있는 형태 (예: GET /index.html HTTP/1.1).
2. TCP/IP 기반
   • OSI 7계층 중 Application Layer에서 동작, 전송 계층으로 TCP(80 포트 기본) 사용.
   • HTTPS의 경우 TLS/SSL을 추가하여 보안성 강화(443 포트).
3. 비연결 지향에서 연결 지향으로 발전
   • HTTP/1.0 → 매 요청마다 새 연결.
   • HTTP/1.1 → 지속 연결(Keep-Alive).
   • HTTP/2 → 멀티플렉싱(여러 요청 동시 처리).
   • HTTP/3 → QUIC(UDP 기반) 사용으로 더 빠른 연결.

 

동작 원리

1. 클라이언트 요청 (Request)
   • 클라이언트(웹, 앱)가 서버로 요청을 보냄.
   • 예: GET /index.html HTTP/1.1
     헤더에 User-Agent, Accept, Cookie 같은 정보 포함.
2. 서버 응답 (Response)
   • 서버가 요청받은 자원(html, json, 이미지 등)을 반환.
   • 상태 코드(200 OK, 404 Not Found, 500 Internal Server Error)와 함께 전송.
3. 데이터 전송
   • 데이터는 평문(plain text)으로 전송되기 때문에, 네트워크 상에서 가로채면 내용이 그대로 노출됨.

 

---

HTTPS

HTTP Secure으로서, 기존의 HTTP의 Secure(SSL/TLS)가 추가된 프로토콜이다.

1990년대 중반, 웹이 전자 상거래와 온라인 결제에 사용되면서 보안의 필요성이 증가되었다. 

넷스케이프가 1994년에 SSL(Secure Socket Layer)을 개발하고 이를 HTTP에 붙여서 사용하기 시작했다.

SSL은 이후 TLS로 표준화되었다.

 

구조적 특징

1. HTTP + SSL/TLS 계층
   • HTTPS는 독립된 새로운 프로토콜이 아니라, HTTP를 SSL/TLS 계층 위에 얹은 것.
   • 즉, HTTP 메시지를 암호화된 통신 채널을 통해 주고받는 구조.
2. 클라이언트-서버 구조 유지
   • 기본 구조는 HTTP와 동일하게 클라이언트(Request) ↔ 서버(Response).
   • 차이점은 두 엔드포인트 사이에 암호화 계층이 추가된 것.
3. 표준 포트 번호
   • HTTP: 80번
   • HTTPS: 443번 (TLS 암호화가 적용된 채널).
4. 디지털 인증서 기반
   • 서버는 인증서(Certificate)를 클라이언트에 제시.
   • 인증서는 공인된 인증기관(CA)에서 발급받으며, 서버 신뢰성을 보장.

 

기술적 특징

1. 암호화 (Encryption)
   • 데이터는 네트워크에서 가로채도 해독 불가.
   • 초기에는 서버 공개키를 이용해 대칭키를 안전하게 교환 → 이후에는 대칭키 암호화로 통신 (속도 효율성).
2. 무결성 (Integrity)
   • 전송 중 데이터가 변조되면 검출 가능.
   • 메시지 인증 코드(MAC)와 해시를 통해 데이터 위변조 탐지.
3. 서버 인증 (Authentication)
   • 클라이언트는 서버가 제시한 인증서의 유효성(발급자, 만료일, 도메인 일치 여부)을 확인.
   • 필요에 따라 클라이언트 인증(양방향 인증, Mutual TLS)도 가능.
4. TLS 핸드셰이크 과정
   • 클라이언트와 서버가 암호화 방식 협상 → 인증서 교환 및 검증 → 세션키 공유 → 암호화된 통신 시작.
5. HTTP/2, HTTP/3와의 결합
   • HTTPS는 HTTP/1.1뿐 아니라 HTTP/2, HTTP/3과 함께 사용 가능.
   • 이때도 모든 데이터 프레임은 TLS로 암호화.

 

동작 원리 (TLS 1.3 기준)

TLS 1.3은 실제 메시지 교환은 3~4개 패킷 수준이다.

1. ClientHello
   • 지원 암호화 스펙 + 클라이언트 난수 + 클라이언트 ECDHE 공개키
2. ServerHello
   • 선택된 암호화 스펙 + 서버 난수 + 서버 ECDHE 공개키
   • 이어서 바로: Certificate, CertificateVerify, Finished 포함
3. Client Finished
   • 클라이언트가 세션키로 암호화한 Finished 메시지 전송

하지만 논리적으로 절차를 이해하기 위해 세분화해보자.

 

동작 절차 

1. 클라이언트 헬로 (ClientHello)
   • 브라우저(또는 앱)가 서버에 접속 시도.
   • 클라이언트가 보내는 정보 :
     • 지원하는 암호화 알고리즘 목록 (Cipher Suites)
     • 무작위 난수(Random) : 최종 세션 키를 도출에 사용
     • 키 교환에 쓸 ECDHE 공개키
   • TLS 1.2와 달리, 이전에 동일한 서버에 세션을 맺은 기록(세션 티켓/PSK)이 남아있다면 0-RTT(옵션) 데이터도 보낼 수 있음.
     
     • 0-RTT: 이전 세션에서 합의된 키를 재사용해 즉시 암호화된 데이터 전송 → 성능 최적화.
2. 서버 헬로 (ServerHello)
   • 서버가 응답 :
     
     • 사용할 암호화 알고리즘 선택
     • 서버의 무작위 난수(Random) : 최종 세션 키를 도출에 사용
     • 서버의 ECDHE 공개키
   • 서버 인증서(공개키 포함)를 전송 → 클라이언트가 검증.
   • 필요한 경우 인증기관(CA) 체인도 함께 전송.
3. 인증서 검증 (Certificate Verify)
   • 클라이언트는 서버가 보낸 인증서를 확인:
     • 신뢰할 수 있는 CA에서 발급했는가?
     • 만료되지 않았는가?
     • 접속하려는 도메인과 일치하는가?
   • 검증 성공 시, 서버 신뢰 확보.
4. 키 교환 및 세션키 생성
   • 클라이언트와 서버는 ECDHE(Elliptic Curve Diffie–Hellman Ephemeral) 알고리즘을 사용해
     서로 보낸 공개키와 자신의 비밀키를 조합하여 동일한 Pre-Master Secret 생성.
   • 이 값과 양쪽 Random 값을 이용해 최종 세션키(Session Key) 도출.
5. Finished 메시지 교환
   • 클라이언트와 서버는 이제 계산된 세션키로 암호화된 Finished 메시지를 교환.
   • 이 과정을 통해 “우리가 같은 세션키를 가지고 있다”는 걸 상호 검증.
6. 암호화된 데이터 통신 시작
   • 핸드셰이크가 끝나면, 모든 HTTP 요청/응답은 세션키 기반의 대칭키 암호화(AES-GCM, ChaCha20-Poly1305 등)로 보호됨.
   • 이후 중간에서 패킷을 가로채도 복호화 불가.