1. HTTP (HyperText Transfer Protocol) 란?
HTTP는 인터넷상에서 클라이언트(브라우저)와 서버가 문서(HTML), 이미지, 데이터 등을 주고받기 위해 사용하는 표준 통신 규약이다.
⚠️ HTTP의 치명적인 한계: "평문(Plaintext) 통신"
HTTP는 데이터를 아무런 암호화 없이 평문 그대로 전송한다.
[클라이언트] --- "ID: admin / PW: 1234" (평문) ---> [서버]
▲
[네트워크 패킷 스니핑 공격자]
(중간에서 데이터 그대로 열람 가능)
- 도청(Sniffing) 위험: Wireshark 같은 패킷 분석 도구를 사용하면 네트워크 중간에서 로그인 정보, 개인정보, 쿠키/세션 ID 등을 쉽게 탈취할 수 있음.
- 변조(Tampering) 위험: 클라이언트와 서버 사이에서 악의적인 공격자가 데이터 내용을 임의로 수정하여 전달할 수 있음 (Man-in-the-Middle, MITM 공격).
- 위장(Spoofing) 위험: 접속하려는 서버가 진짜 서버인지 검증할 수 없어 피싱 사이트에 노출되기 쉬움.
2. HTTPS (HTTP Secure) 란?
HTTPS는 기존 HTTP 프로토콜에 SSL/TLS(Transport Layer Security) 암호화 프로토콜을 얹어 데이터를 보호하는 보안 통신 규약이다. 기본 포트로 HTTP는 80, HTTPS는 443을 사용한다.
[클라이언트] --- "a8f!9#z1$kL..." (암호화) ---> [서버]
▲
[공격자 (내용 해독 불가)]
🛡️ HTTPS가 제공하는 3가지 핵심 보안 가치
- 기밀성 (Confidentiality): 모든 데이터를 암호화하여 제3자가 도청해도 내용을 알 수 없음.
- 무결성 (Integrity): 전송 중 데이터가 위변조되었는지 검증 가능함.
- 인증 (Authentication): 전자 서명된 CA 인증서를 통해 접속한 서버가 진짜 신뢰할 수 있는 서버인지 확인.
3. HTTPS의 핵심 암호화 방식 (대칭키 + 공개키)
HTTPS는 효율적인 암호화를 위해 대칭키 암호화와 공개키(비대칭키) 암호화 방식을 혼합하여 사용한다.
| 구분 | 대칭키(Symmetric Key) 암호화 | 공개키(Public Key / Asymmetric) 암호화 |
|---|---|---|
| 원리 | 암호화와 복호화에 동일한 키 사용 | 공개키(암호화용)와 개인키(복호화용) 한 쌍 사용 |
| 장점 | 연산 속도가 매우 빠름 | 키 전달 시 유출 위험이 없음 (안전한 키 교환) |
| 단점 | 키를 상대방에게 전달할 때 유출 위험 존재 | 연산 속도가 느려 대용량 데이터 전송에 부적합 |
💡 HTTPS의 하이브리드 메커니즘:
속도가 느린 공개키 암호화는 최초 접속 시 '데이터를 암호화할 대칭키(세션키)'를 안전하게 공유하는 용도로만 사용하고, 실제로 데이터를 주고받을 때는 속도가 빠른 대칭키 암호화를 이용함.
4. SSL/TLS 핸드셰이크 (Handshake) 동작 흐름
클라이언트와 서버가 HTTPS 통신을 시작하기 전, 안전하게 암호화 키를 교환하고 인증서를 검증하는 과정을 Handshake라고 함.
[Client] [Server]
| |
| -------- (1) Client Hello (지원 cipher suite) -----> |
| <------- (2) Server Hello + CA 인증서 -------------- |
| |
| [3. 인증서 검증 (CA 공개키로 서명 확인)] |
| [4. Pre-Master Secret 생성 및 서버 공개키로 암호화] |
| |
| -------- (5) 암호화된 Pre-Master Secret 전송 ------> |
| |
| [6. 양쪽 모두 세션키(대칭키) 생성 완료] |
| |
| <====== (7) 대칭키 기반의 안전한 암호화 통신 ======> |
- Client Hello: 클라이언트가 서버에게 지원 가능한 암호화 방식(Cipher Suite)과 난수 값을 전달함.
- Server Hello & Certificate: 서버가 사용할 암호화 방식을 선택하고, 발급받은 SSL/TLS CA 인증서를 클라이언트에 전달함.
- 인증서 검증: 클라이언트는 브라우저에 미리 내장된 CA(인증 기관)의 공개키로 서버 인증서의 서명을 검증함 (신뢰할 수 있는 서버인지 확인).
- Pre-Master Secret 전달: 클라이언트는 새로운 난수(Pre-Master Secret)를 생성한 뒤, 인증서에서 추출한 서버의 공개키로 암호화하여 서버로 전송함.
- 세션키 생성: 서버는 자신의 개인키로 이를 복호화함. 이제 클라이언트와 서버 양쪽 모두 동일한 대칭키(세션키)를 보유하게 됨.
- 암호화 통신 개시: 이후 실제 데이터 요청/응답은 이 세션키(대칭키)를 이용해 빠르게 암호화/복호화하여 주고받음.
💡 개발자/보안 관점
- 혼합 콘텐츠 (Mixed Content) 주의: HTTPS 페이지 내에서 HTTP로 이미지나 API 요청(AJAX)을 보낼 경우 브라우저가 이를 블로킹함. 전 리소스 HTTPS 전환 필수.
- HSTS (HTTP Strict Transport Security): 최초 접근 시 HTTP 접속 시도를 서버 측에서 강제로 HTTPS로만 리다이렉트 및 고정하도록 브라우저에 지시하는 보안 헤더 설정.
- 쿠키 보안 플래그 연동: HTTPS 환경에서는 인증 관련 쿠키에 반드시
Secure및HttpOnly플래그를 설정하여 네트워크 스니핑 및 XSS로 인한 탈취 방지.
파인애플 좋아하세요?