HTTPS (HyperText Transfer Protocol Secure)

2023. 8. 9. - Last update: 2026. 8. 9.

hyoguoo

Backend Engineer

HTTP의 보안 취약점을 보완하기 위해 설계된 프로토콜이다.

HTTP 프로토콜 내용 자체를 암호화하여 TCP/IP 통신을 수행
SSL (Secure Socket Layer) 또는 TLS (Transport Layer Security) 보안 계층 위에서 동작

HTTP의 보안 취약점

HTTP는 텍스트를 평문으로 전송하기 때문에 네트워크 스니핑 (Sniffing)과 같은 공격에 취약하다.

도청 가능 (Confidentiality 침해)
- TCP/IP 패킷은 통신 경로 상의 라우터나 네트워크 장비에서 탈취 가능
- 패킷 캡처 도구 (Wireshark 등)를 사용하면 로그인이 ID/PW 등을 쉽게 탈취할 수 있음
위장 가능 (Authentication 부재)
- 클라이언트는 자신이 요청을 보낸 서버가 정말 네이버나 구글 같은 실제 신뢰할 수 있는 서버인지 확인할 방법이 없음
- 공격자가 위조된 서버를 만들어 클라이언트를 속일 수 있음
변조 가능 (Integrity 침해)
- 서버에서 보낸 데이터가 클라이언트에게 도착하기 전에 중간자 (Man-in-the-Middle)가 데이터를 가로채 악성코드를 심거나 내용 변경 가능

HTTPS의 핵심 원리

HTTPS는 위의 세 가지 문제를 해결하기 위해 SSL/TLS 프로토콜을 사용한다.

기밀성 (Encryption): 데이터를 암호화하여 도청되더라도 내용을 알 수 없게 함
무결성 (Integrity): 데이터가 전송 중에 변조되지 않았음을 보장 (MAC: Message Authentication Code 사용)
인증 (Authentication): 신뢰할 수 있는 인증기관 (CA)의 인증서를 통해 접속한 서버가 정당한 서버임을 보장

HTTP	HTTPS
HTTP - 애플리케이션 계층	HTTP - 애플리케이션 계층
-	SSL or TLS - 보안 계층
TCP - 전송 계층	TCP - 전송 계층
IP - 네트워크 계층	IP - 네트워크 계층
네트워크 인터페이스 - 데이터 링크 계층	네트워크 인터페이스 - 데이터 링크 계층

대칭키와 비대칭키의 혼용 (하이브리드 암호화)

HTTPS는 속도와 보안의 균형을 맞추기 위해 두 가지 암호화 방식을 혼합하여 사용한다.

연결 수립 단계 (Handshake): 공개키 (비대칭키) 암호화 사용
- 목적: 대칭키를 안전하게 공유하기 위함
- 특징: 보안성은 높으나 계산 비용이 비싸고 속도가 느림
데이터 전송 단계: 대칭키 암호화 사용
- 목적: 실제 HTTP 데이터를 빠르게 암호화하여 전송
- 특징: 계산 비용이 저렴하고 속도가 빠름

SSL과 TLS의 관계

SSL (Secure Sockets Layer): 넷스케이프사가 개발한 초기 프로토콜로, 현재는 보안 취약점으로 인해 사용되지 않음
TLS (Transport Layer Security): SSL을 표준화하여 발전시킨 프로토콜로, 현재는 TLS 1.2와 TLS 1.3이 주로 사용
실무에서는 관습적으로 SSL이라 부르지만, 실제로는 TLS 프로토콜을 의미

HTTP / HTTPS 트랜잭션 비교

URL 프로토콜 스키마에 따라 HTTP/HTTPS로 통신하게 되며, 각각 아래와 같은 트랜잭션을 거치게 된다.

암호화되지 않은 HTTP 트랜잭션	암호화된 HTTPS 트랜잭션
서버의 80포트로 TCP 커넥션 수립	서버의 443포트로 TCP 커넥션 수립
-	SSL 보안 매개변수 핸드셰이크
TCP를 통해 보내진 HTTP 요청	SSL을 통해 보내진 HTTP 요청 / TCP를 통해 보내진 암호화된 요청
TCP를 통해 보내진 HTTP 응답	SSL을 통해 보내진 HTTP 응답 / TCP를 통해 보내진 암호화된 응답
-	SSL 닫힘 통지
TCP 커넥션 닫힘	TCP 커넥션 닫힘

SSL Handshake (TLS 1.2 기준)

TCP 3-way Handshake로 논리적 연결이 맺어진 직후, 보안 통신을 위한 TLS Handshake가 추가로 수행된다.

sequenceDiagram
    participant Client
    participant Server
    Note over Client,Server: 1. TCP 3-Way Handshake 완료
    Client ->> Server: 2. Client Hello
    Note right of Client: 지원하는 암호화 방식(Cipher Suite), 랜덤 데이터 전송
    Server ->> Client: 3. Server Hello
    Note left of Server: 암호화 방식 선택, 랜덤 데이터, 서버 인증서 전송
    Client ->> Client: 4. 인증서 검증 (CA Public Key)
    Note right of Client: 브라우저에 내장된 CA 리스트로 서버 인증서 검증 및 Pre-Master Secret 생성
    Client ->> Server: 5. Client Key Exchange
    Note right of Client: 서버의 공개키로 Pre-Master Secret을 암호화하여 전송
    Client ->> Client: 6. Session Key 생성
    Server ->> Server: 6. Session Key 생성 (개인키로 복호화)
    Note over Client,Server: 이제 양쪽 모두 동일한 대칭키(세션키) 보유
    Client ->> Server: 7. Change Cipher Spec / Finished
    Server ->> Client: 8. Change Cipher Spec / Finished
    Note over Client,Server: 핸드셰이크 종료
    Client ->> Server: 9. HTTP Request (세션키로 암호화)
    Server ->> Client: 10. HTTP Response (세션키로 암호화)

Client Hello: 클라이언트가 지원하는 암호화 방식 목록 (Cipher Suite)과 난수 (Random Value)를 전송
Server Hello: 서버가 암호화 방식을 선택하고, 자신의 인증서와 난수를 전송
인증서 검증: 클라이언트는 CA의 공개키를 사용해 서버 인증서의 전자 서명을 검증
키 교환: 클라이언트는 임시 비밀키 (Pre-Master Secret)를 생성하고, 이를 서버 인증서에 있는 공개키로 암호화하여 전송
세션키 생성: 서버는 자신의 개인키로 이를 복호화함. 이제 양쪽은 동일한 키 (세션키)를 가지게 됨
통신 시작: 이후 모든 HTTP 메시지는 이 세션키를 이용해 암호화되어 전송

최신 TLS 1.3은 보안이 취약한 알고리즘을 제거하고, 위 핸드셰이크 과정을 간소화하여 (1-RTT) 연결 속도를 개선했다.

클라이언트가 첫 요청 (Client Hello)을 보낼 때 암호화 방식과 키 교환 데이터를 한 번에 묶어서 서버로 전송
불필요한 왕복 횟수가 1-RTT (Round Trip Time)로 줄어듬

사이트 인증서 검사

SSL 자체는 사용자에게 인증서 검증 과정을 하지 않지만, 최신 웹 브라우저들은 백그라운드에서 신뢰성을 엄격하게 검증한다.

인증서 검사 절차

브라우저는 통신을 수립하기 전 다음과 같은 단계로 서버 인증서를 검증한다.

날짜 검사: 인증서의 시작 및 종료일 검사
서명자 신뢰도 검사: 브라우저에 내장된 인증서 발급자 목록과 인증서 발급자의 이름을 비교 (신뢰할 수 있는 발급자인지 검사)
서명 검사: 서명기관의 공개키를 서명에 적용하여 체크섬과 비교하여 무결성 검사
사이트 신원 검사: 인증서 복사 혹은 트래픽 중간자 공격을 막기 위해 인증서의 도메인 이름과 통신 중인 서버 호스트의 도메인이 일치하는지 검사

SSL (HTTPS)에 이용되는 디지털 암호학 기초

참고자료

HTTP 완벽 가이드

Network