HTTP와 HTTPS의 차이

웹사이트를 돌아다니다 보면 주소가 http://로 시작하는 곳도 있고, https://로 시작하는 곳도 있다.

요즘은 대부분의 웹사이트가 HTTPS를 사용하고 있어서 HTTP 주소를 볼 일이 많지는 않다. 오히려 HTTP 사이트에 접속하면 브라우저에서 '주의 요함'이나 '안전하지 않음' 같은 경고가 표시되기도 한다.

그런데 HTTP와 HTTPS는 정확히 뭐가 다른 걸까?

단순히 보안이 적용됐다는 것만 알고 넘어가기에는 생각보다 흥미로운 차이가 있다.

HTTP는 데이터를 그대로 보낸다

HTTP(Hypertext Transfer Protocol)는 웹 브라우저와 서버가 데이터를 주고받을 때 사용하는 프로토콜이다.

우리가 웹사이트에 접속하면 브라우저가 서버에 요청을 보내고, 서버는 그 요청에 맞는 데이터를 응답한다.

예를 들어 브라우저에서 http://example.com에 접속하면 다음과 같은 요청이 전송될 수 있다.

GET / HTTP/1.1
Host: example.com

서버는 요청을 받아 HTML 문서 등을 반환한다.

여기까지는 특별할 게 없다.

문제는 HTTP가 데이터를 암호화하지 않고 그대로 전송한다는 것이다.

로그인 요청을 예로 들어보자.

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "username": "developer",
  "password": "12345678"
}

이 요청을 별도의 암호화 없이 HTTP로 전송하면 아이디와 비밀번호가 평문(Plaintext) 상태로 네트워크를 지나간다.

쉽게 말해서 비밀번호를 종이에 적어 봉투도 없이 우편으로 보내는 셈이다.

우편물을 전달하는 과정에서 누군가 내용을 볼 수 있다면 비밀번호도 그대로 드러나는 것이다.

물론 인터넷에서 모든 사람이 남의 HTTP 통신을 볼 수 있다는 뜻은 아니다. 하지만 네트워크 경로에서 패킷을 가로챌 수 있는 공격자라면 내용을 확인하거나 변조할 수 있다.

이런 문제 때문에 민감한 정보를 처리하는 서비스에서 HTTP를 그대로 사용하는 것은 위험하다.

HTTPS는 뭐가 다를까?

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 TLS(Transport Layer Security)를 적용해 통신을 보호하는 방식이다.

HTTP가 데이터를 그대로 보낸다면, HTTPS는 데이터를 암호화해서 보낸다.

아까 우편에 비유했으니 조금 더 이어서 생각해 보자.

HTTP는 내용을 누구나 읽을 수 있는 엽서에 적어 보내는 것과 비슷하다.

반면 HTTPS는 내용을 잠긴 상자에 넣어 보내는 것과 같다. 상자를 전달하는 사람은 어디로 보내는지는 알 수 있지만, 안에 무엇이 들어 있는지는 쉽게 확인할 수 없다.

실제 통신에서도 비슷한 일이 일어난다.

[HTTP]

브라우저
   |
   | username=developer
   | password=12345678
   |
   v
서버


[HTTPS]

브라우저
   |
   | TLS로 암호화된 데이터
   | (원본 내용을 바로 읽을 수 없음)
   |
   v
서버
   |
   | 복호화
   v
원본 데이터

여기서 중요한 점은 브라우저가 HTTP 요청을 만들지 않는 게 아니라는 것이다.

HTTP 요청을 TLS로 암호화해 전송하는 것이다.

서버는 암호화된 데이터를 복호화한 뒤 원래 HTTP 요청을 처리한다.

덕분에 통신을 중간에서 가로채더라도 암호화 키가 없다면 그 내용을 알아보기 어렵다.

그런데 서버는 암호를 어떻게 풀까?

이쯤에서 의문이 생길 수 있다.

데이터를 암호화해서 보내는 건 알겠는데, 서버는 무슨 수로 그걸 복호화하는 걸까?

여기서 TLS가 등장한다.

HTTPS 연결을 시작할 때 브라우저와 서버는 TLS 핸드셰이크(Handshake)라는 과정을 거친다.

TLS 1.3을 기준으로 간단하게 설명하면 다음과 같다.

브라우저가 서버에 자신이 지원하는 암호화 방식과 키 교환 정보를 보낸다.
서버는 사용할 암호화 방식을 선택하고 필요한 정보를 응답한다.
브라우저는 서버가 제시한 인증서를 확인한다.
양쪽은 키 교환을 통해 공유 비밀을 계산하고 암호화 키를 생성한다.
이후 생성된 키를 사용해 데이터를 암호화하여 통신한다.

여기서 흥미로운 점이 있다.

브라우저와 서버는 암호화에 사용할 비밀키를 네트워크에 그대로 보내지 않고도 서로 통신할 수 있다.

TLS 1.3에서는 주로 ECDHE와 같은 키 교환 방식을 사용한다. 양쪽이 교환한 공개 정보와 각자가 가진 비밀 정보를 이용해 동일한 공유 비밀을 계산하는 방식이다.

이렇게 얻은 정보를 바탕으로 대칭키를 만들고, 실제 HTTP 데이터는 이 키로 암호화한다.

즉, 데이터를 안전하게 보내기 위해 처음부터 끝까지 하나의 암호화 방식만 사용하는 것은 아니다.

HTTPS라고 무조건 안전할까?

그렇지는 않다.

주소창에 HTTPS가 표시되더라도 웹사이트 자체가 안전하다고 보장할 수는 없다.

예를 들어 피싱 사이트도 정상적인 TLS 인증서를 발급받아 HTTPS를 사용할 수 있다.

HTTPS가 보호하는 것은 기본적으로 브라우저와 서버 사이의 통신이지, 서버에 저장된 개인정보나 웹사이트 내부 코드까지 전부 보호하는 것은 아니다.

또 하나 알아둘 점은 HTTPS라고 해서 모든 정보가 숨겨지는 건 아니라는 것이다.

HTTP 요청의 본문이나 URL 경로, 쿠키 등의 내용은 TLS로 보호되지만, 연결 대상 IP 주소나 트래픽 크기 같은 정보는 여전히 관찰될 수 있다.

따라서 HTTPS는 익명성을 보장하는 기술이라기보다, 통신 내용을 안전하게 보호하기 위한 기술이라고 이해하는 것이 정확하다.

HTTP와 HTTPS 비교

지금까지 설명한 내용을 간단하게 정리해 보자.

항목	HTTP	HTTPS
기본 포트	80	443
데이터 암호화	없음	TLS 사용
데이터 도청	평문 노출 가능	암호화로 보호
데이터 변조	자체 보호 없음	무결성 검증
서버 인증	기본적으로 없음	TLS 인증서
사용 환경	일부 개발 및 내부 환경	일반 웹사이트, API 등

그렇다면 HTTPS를 사용하면 암호화 과정 때문에 웹사이트가 느려지지 않을까?

물론 암호화에는 추가적인 연산이 필요하다.

하지만 TLS 1.3은 연결 설정 과정을 효율적으로 개선했고, 현대적인 서버에서는 암호화에 따른 성능 부담이 대체로 크지 않다.

여기에 HTTP/2나 HTTP/3 같은 프로토콜을 사용하면 멀티플렉싱 등 통신 효율을 개선하는 기술도 활용할 수 있다.

참고로 HTTP/3는 기존의 TCP 대신 QUIC을 사용하며 TLS 1.3 기반 보안 기능이 통합되어 있다.

직접 확인해 보기

터미널에서 curl을 사용하면 HTTP와 HTTPS 연결을 간단하게 확인할 수 있다.

먼저 HTTP 요청을 보내보자.

curl -v http://example.com

이번에는 HTTPS로 요청해 보자.

curl -v https://example.com

-v 옵션을 사용하면 연결 과정에 관한 상세 정보가 출력된다.

HTTPS 요청에서는 TLS 연결 협상과 인증서 검증 관련 정보를 확인할 수 있다.

실제로 데이터가 암호화되어 전송되는 모습까지 확인하고 싶다면 Wireshark 같은 패킷 분석 도구를 이용할 수도 있다.

평문 HTTP 통신과 HTTPS 통신을 비교해 보면 둘의 차이를 더 확실하게 이해할 수 있다.

단, 자신의 네트워크나 분석 권한이 있는 환경에서 확인해야 한다.

마무리

HTTP와 HTTPS의 가장 큰 차이는 결국 데이터를 어떻게 전송하느냐에 있다.

HTTP는 데이터를 암호화하지 않고 전송하기 때문에 중간에서 통신을 가로챌 수 있다면 내용을 읽거나 변경할 위험이 있다.

반면 HTTPS는 TLS를 이용해 데이터를 암호화하고, 서버의 신원을 검증하며, 전송 중 데이터가 변조되는 것을 방지한다.

물론 HTTPS를 적용했다고 모든 보안 문제가 해결되는 것은 아니다. 서버 보안이나 인증 처리, 웹 애플리케이션의 취약점은 별도로 관리해야 한다.

그래도 웹 서비스를 개발한다면 HTTPS는 기본적으로 적용하는 것이 맞다.

주소에 붙은 s는 한 글자에 불과하지만, 그 뒤에는 생각보다 많은 보안 기술이 동작하고 있다.

HTTP와 HTTPS의 차이, 뒤에 붙은 S는 무슨 의미일까?