HTTPS는 HTTP보다 무엇이 안전할까?

인터넷에서 웹사이트에 접속하다 보면 주소창에 http://가 붙어 있는 경우도 있고 https://가 붙어 있는 경우도 있다.

요즘은 대부분의 웹사이트가 HTTPS를 사용하기 때문에 사실상 HTTPS가 기본처럼 느껴진다. 그런데 막상 HTTP와 HTTPS의 차이를 물어보면 단순히 “HTTPS가 암호화된 거 아닌가?” 정도로만 알고 있는 경우가 많다.

실제로 HTTPS가 중요한 이유는 단순히 데이터를 암호화하기 때문만은 아니다.

HTTPS는 HTTP 통신에 TLS(Transport Layer Security)​를 적용해서 통신 내용을 보호하고, 접속한 서버가 정말 해당 사이트가 맞는지 확인하며, 전송 중 데이터가 변조되지 않았는지도 확인할 수 있도록 한다.

이번 글에서는 HTTP와 HTTPS의 차이를 중심으로 HTTPS가 어떤 부분에서 더 안전한지 정리해보려고 한다.

HTTP는 어떤 방식으로 통신할까?

HTTP는 웹 브라우저와 웹 서버가 데이터를 주고받기 위한 프로토콜이다.

예를 들어 사용자가 브라우저에서 다음과 같은 주소에 접속했다고 해보자.

http://example.com

브라우저는 서버에 HTTP 요청을 보내고 서버는 HTTP 응답을 돌려준다.

클라이언트
   ↓
HTTP Request
   ↓
서버
   ↓
HTTP Response
   ↓
클라이언트

문제는 HTTP 자체에는 통신 내용을 암호화하는 기능이 없다는 것이다.

예를 들어 로그인 과정에서 다음과 같은 정보가 전송된다고 생각해보자.

ID: user123
Password: abc123

HTTP를 사용하면 이 데이터가 네트워크를 통해 전송되는 과정에서 제3자가 내용을 볼 가능성이 있다.

특히 공용 Wi-Fi처럼 여러 사용자가 같은 네트워크를 사용하는 환경에서는 이런 문제가 더 중요해진다.

물론 실제 서비스에서는 비밀번호를 그대로 보내는 것이 아니라 HTTP 요청 자체가 네트워크를 통해 전달되는 과정에서 보호되어야 한다는 것이 핵심이다.

HTTPS는 무엇이 다른가?

HTTPS는 이름 그대로 HTTP + TLS라고 이해하면 편하다.

HTTP
  +
TLS
  =
HTTPS

TLS는 데이터를 안전하게 주고받기 위한 보안 프로토콜이다.

따라서 HTTPS에서는 HTTP 요청과 응답을 그냥 전송하는 것이 아니라 TLS를 통해 보호한 상태로 통신한다.

HTTP

브라우저 ───── HTTP 데이터 ─────→ 서버


HTTPS

브라우저 ── TLS로 보호된 데이터 ──→ 서버

여기서 중요한 보호 기능은 크게 세 가지로 볼 수 있다.

1. 기밀성(Confidentiality)
2. 무결성(Integrity)
3. 인증(Authentication)

이 세 가지가 HTTPS의 핵심이다.

1. 기밀성: 다른 사람이 내용을 보기 어렵게 만든다

가장 먼저 생각할 수 있는 것이 암호화다.

HTTPS에서는 TLS 연결이 만들어진 이후 HTTP 데이터가 암호화되어 전송된다.

예를 들어 브라우저가 서버에 다음과 같은 데이터를 보내더라도

GET /mypage HTTP/1.1
Cookie: session=123456

네트워크에서 패킷을 보는 제3자가 HTTP 내용을 그대로 읽기는 어렵다.

실제로 네트워크를 지나가는 데이터는 암호화된 형태로 보인다.

브라우저
   │
   │  암호화된 데이터
   ▼
네트워크
   │
   │  암호화된 데이터
   ▼
서버

따라서 같은 네트워크에 있는 사람이 패킷을 가로보더라도 HTTP 통신 내용을 그대로 확인하기 어려워진다.

여기서 중요한 점이 하나 있다.

HTTPS라고 해서 모든 정보가 완전히 숨겨지는 것은 아니다.

예를 들어 접속한 서버의 IP 주소나 통신량 같은 일부 정보는 네트워크 환경에 따라 관찰될 수 있다.

하지만 HTTP처럼 웹 페이지의 요청과 응답 내용을 그대로 노출하는 것과 비교하면 보안 수준이 크게 달라진다.

2. 무결성: 데이터가 중간에 바뀌었는지 확인한다

HTTPS의 또 다른 중요한 기능은 데이터 변조 방지다.

인터넷 통신은 여러 네트워크 장비와 경로를 거쳐 목적지에 도착한다.

만약 중간에서 누군가 데이터를 몰래 수정할 수 있다면 문제가 생긴다.

예를 들어 원래 서버가 보내려던 내용이

상품 가격: 100,000원

이었다고 하자.

그런데 통신 중간에서 누군가 데이터를 변경해서

상품 가격: 1,000,000원

으로 바꿀 수 있다면 상당히 위험하다.

TLS는 암호학적 검증을 이용해 전송된 데이터가 통신 중 변경되었는지를 확인한다.

따라서 단순히 “남이 못 보게 한다”​뿐만 아니라 “남이 몰래 바꾸는 것도 어렵게 한다”​는 것이 HTTPS의 중요한 특징이다.

3. 인증: 내가 접속한 서버가 정말 그 서버인지 확인한다

HTTPS에서 생각보다 중요한 부분이 바로 인증이다.

암호화만 되어 있다고 해서 무조건 안전한 것은 아니다.

예를 들어 공격자가 가짜 쇼핑몰 사이트를 만들어 놓았다고 생각해보자.

사용자가 그 사이트에 접속했는데 통신 자체는 HTTPS로 암호화되어 있다면 어떨까?

그래도 위험할 수 있다.

왜냐하면 가짜 사이트와 암호화된 통신을 하고 있을 뿐이기 때문이다.

그래서 HTTPS에서는 디지털 인증서(Certificate)​를 이용해 서버의 신원을 확인한다.

브라우저가 HTTPS 사이트에 접속하면 서버는 자신의 인증서를 제시한다.

브라우저
   │
   │ HTTPS 접속
   ▼
서버
   │
   │ 인증서 전달
   ▼
브라우저
   │
   │ 인증서 검증
   ▼
TLS 연결 진행

인증서에는 해당 도메인과 관련된 정보 및 공개키 등이 포함되어 있다.

브라우저는 인증서가 신뢰할 수 있는 인증기관(CA)에 의해 발급되었는지, 접속하려는 도메인과 인증서의 정보가 맞는지, 인증서가 유효한지 등을 확인한다.

그래서 브라우저 주소창에 자물쇠 표시가 나타나는 것이다.

HTTPS의 인증서는 누가 발급할까?

여기서 등장하는 것이 CA(Certificate Authority)​다.

CA는 디지털 인증서를 발급하고 그 인증서가 신뢰할 수 있는 것인지 확인하는 역할을 한다.

브라우저와 운영체제에는 일반적으로 신뢰할 수 있는 CA 목록이 포함되어 있다.

개념적으로 보면 다음과 같은 구조다.

신뢰하는 CA
    │
    │ 인증서 발급
    ▼
example.com 인증서
    │
    ▼
브라우저가 검증

그래서 브라우저는 단순히 서버가 “나는 example.com입니다”라고 주장한다고 믿는 것이 아니라, 신뢰 체인을 통해 인증서를 검증한다.

인증서 검증에 문제가 있다면 브라우저가 경고를 표시하는 이유도 여기에 있다.

HTTPS에서는 데이터를 어떻게 암호화할까?

여기서 HTTPS를 공부하다 보면 공개키와 대칭키라는 용어가 등장한다.

처음 보면 조금 복잡해 보이지만 역할을 나눠서 생각하면 이해하기 쉽다.

TLS에서는 연결을 설정하는 과정에서 암호화에 사용할 키를 안전하게 협상한다.

이후 실제 웹 데이터 통신에는 대칭키 암호화가 주로 사용된다.

개념적으로 보면

TLS 연결 설정
     ↓
암호화에 사용할 키 협상
     ↓
안전한 연결 구성
     ↓
HTTP 데이터 전송
     ↓
대칭키 기반 암호화 통신

이런 구조로 생각하면 된다.

대칭키 방식은 같은 비밀키를 이용해 데이터를 암호화하고 복호화하는 방식이다.

실제 데이터를 대량으로 주고받을 때 효율적이기 때문에 적합하다.

반면 공개키 암호 방식은 TLS 연결을 설정하고 상대방을 인증하거나 키 교환을 보호하는 과정에서 중요한 역할을 한다.

즉,

“HTTPS는 공개키로 모든 데이터를 암호화한다.”

라고 이해하면 정확하지 않다.

TLS에서는 각 암호 기술이 서로 다른 역할을 담당한다.

HTTPS 접속 과정은 어떻게 진행될까?

사용자가 HTTPS 사이트에 접속하는 과정을 전체적으로 연결해보면 이해하기 쉽다.

예를 들어

https://example.com

에 접속한다고 해보자.

먼저 브라우저는 example.com의 IP 주소를 알아내기 위해 DNS 질의를 수행한다.

1. DNS 조회
브라우저 → DNS → 서버 IP 확인

그다음 TCP 기반 연결이라면 서버와 TCP 연결을 설정한다.

2. TCP 연결
클라이언트 ↔ 서버
SYN
SYN-ACK
ACK

그리고 HTTPS이기 때문에 TLS 연결을 설정한다.

3. TLS 연결
클라이언트 ↔ 서버
인증서 확인
키 교환 및 보안 파라미터 협상

TLS 연결이 완료되면 이제 HTTP 요청을 안전하게 전송한다.

4. HTTP 요청
GET / HTTP/1.1

다만 네트워크에서 이 HTTP 내용은 TLS에 의해 보호된다.

그리고 서버가 응답을 보내면 브라우저가 이를 받아 웹 페이지를 표시한다.

전체 과정을 단순화하면 다음과 같다.

브라우저
   │
   ├── DNS 조회
   │
   ├── TCP 연결
   │
   ├── TLS 연결
   │
   ├── HTTPS 요청
   │
   └── HTTPS 응답
          ↓
        서버

이 과정 때문에 앞에서 공부했던 DNS, TCP 3-Way Handshake, HTTP가 HTTPS에서도 서로 연결되어 등장한다.

HTTP와 HTTPS의 차이를 정리하면

구분	HTTP	HTTPS
기본 프로토콜	HTTP	HTTP + TLS
데이터 암호화	없음	있음
데이터 변조 방지	제한적	TLS를 통해 보호
서버 인증	없음	인증서 기반
기본 포트	80	443
주요 목적	웹 데이터 전송	안전한 웹 데이터 전송

HTTPS는 단순히 HTTP에 암호 하나를 붙인 개념이라기보다는 HTTP 통신을 TLS라는 보안 계층으로 보호하는 구조라고 이해하는 것이 좋다.

HTTPS라고 무조건 안전한 것은 아니다

여기서 하나 주의해야 할 부분이 있다.

HTTPS가 적용되어 있다고 해서 해당 웹사이트 자체가 안전하다는 뜻은 아니다.

예를 들어 악성 사이트도 HTTPS 인증서를 사용할 수 있다.

HTTPS가 보장하는 것은 기본적으로 브라우저와 서버 사이의 통신을 보호하고 서버의 신원을 인증하는 것이다.

사이트 운영자가 악성 프로그램을 배포하거나 사용자를 속이는 사이트라면 HTTPS라고 해서 안전한 사이트가 되는 것은 아니다.

그래서

HTTPS = 안전한 웹사이트

라고 생각하면 안 된다.

정확하게는

HTTPS = 서버와의 웹 통신을 안전하게 보호하기 위한 기술

이라고 보는 것이 맞다.

HTTPS를 사용하면 무엇이 좋아질까?

실제 웹 서비스에서는 로그인, 결제, 개인정보 입력 등 민감한 정보가 오가는 경우가 많다.

이런 데이터를 HTTP로 전송하면 네트워크에서 정보가 노출되거나 변조될 위험이 커진다.

HTTPS를 사용하면 TLS를 통해 통신 내용을 보호하고, 서버 인증을 수행하며, 데이터가 전송 과정에서 변조되었는지도 검증할 수 있다.

특히 요즘 웹사이트에서는 로그인 세션을 유지하기 위한 쿠키 같은 정보도 중요하다.

HTTPS가 없다면 이런 정보가 네트워크에서 노출될 위험이 커지고, 계정 탈취 등의 문제로 이어질 가능성이 있다.

그래서 단순한 정보 페이지뿐만 아니라 로그인이나 결제가 없는 웹사이트에서도 HTTPS 사용이 일반화되고 있다.

마무리

HTTP와 HTTPS의 차이를 처음 공부하면 단순히

HTTP는 암호화되지 않고 HTTPS는 암호화된다.

정도로 정리하기 쉽다.

하지만 HTTPS의 핵심은 암호화 하나만 있는 것이 아니다.

TLS를 통해

기밀성
+
무결성
+
인증

을 제공한다는 것이 핵심이다.

기밀성은 다른 사람이 통신 내용을 쉽게 볼 수 없도록 하고, 무결성은 전송 중 데이터가 변조되지 않았는지 확인할 수 있게 한다. 그리고 인증서는 내가 접속한 서버가 주장하는 도메인의 서버인지 확인하는 데 도움을 준다.

결국 HTTPS는 HTTP 자체를 다른 프로토콜로 바꾸는 것이 아니라 HTTP 통신을 TLS로 보호하는 방식이라고 이해하면 가장 깔끔하다.

앞에서 HTTP 요청과 응답, TCP 연결 과정을 공부했다면 HTTPS는 그 위에 보안 계층이 하나 추가된 것으로 생각하면 이해하기 쉽다.

다음으로 TLS 자체를 조금 더 자세히 살펴보면 HTTPS가 연결을 시작할 때 인증서와 암호화 키를 어떻게 교환하는지까지 이해할 수 있다. 이 부분이 바로 다음 주제인 SSL과 TLS를 공부할 때 연결되는 내용이다.