HTTP와 HTTPS 차이 정리, TLS 핸드셰이크와 인증서 검증이 로그인 정보를 지키는 방식

핵심 메시지

• HTTPS는 HTTP를 대체하는 게 아니라 같은 HTTP 메시지를 TLS라는 보호된 통로 안에 넣어 보내는 방식이다.
• 평문 HTTP는 요청 줄과 헤더, 쿠키, 본문이 그대로 노출돼 같은 네트워크에 있는 누군가가 아이디와 비밀번호를 읽을 수 있다.
• TLS 핸드셰이크는 서버가 진짜인지 확인하는 일과, 이후 통신을 보호할 공유 키를 만드는 일 두 가지를 한다.
• 인증서는 도메인 이름과 공개 키를 담은 신분증이며, 만료·호스트 불일치·신뢰 사슬 문제가 있으면 브라우저가 연결을 멈춘다.
• 최신 TLS 1.3은 공유 키를 매번 새로 만들어, 나중에 서버 개인 키가 유출돼도 과거 기록을 풀 수 없게 한다.

쉽게 이해하기

로그인 화면에 비밀번호를 넣고 전송을 누르면 브라우저는 서버에 HTTP 요청을 보내고 서버는 응답을 돌려준다. 이 구조 자체는 단순하지만, 문제는 그 사이 구간에서 벌어진다. 영상은 같은 요청이 HTTP일 때와 HTTPS일 때 네트워크 위에서 어떻게 다르게 취급되는지를 단계별로 따라간다.

고전적인 경로에서는 먼저 TCP 세 번의 악수로 연결이 만들어진다. 평문 HTTP라면 연결 직후 곧바로 요청을 보내는데, 이때 요청 줄과 헤더, 쿠키, 본문이 모두 읽을 수 있는 형태로 흘러간다. 공용 와이파이의 악성 접속점이나 중간에 놓인 프록시가 이를 그대로 들여다볼 수 있고, 트래픽을 바꿀 수 있는 공격자라면 응답이 브라우저에 닿기 전에 내용을 고칠 수도 있다. 정리하면 HTTP에는 비밀 유지, 서버 신원 증명, 변조 방지라는 세 가지가 빠져 있다.

HTTPS는 여기에 TLS를 더해 이 문제를 메운다. TCP 연결까지는 같지만 요청을 바로 보내지 않고 먼저 TLS 핸드셰이크를 시작한다. 브라우저가 지원하는 버전과 암호 방식을 알리면 서버가 설정을 정하고 인증서를 보낸다. 인증서에는 도메인 이름과 서버의 공개 키가 담겨 있고 브라우저가 이미 신뢰하는 인증 기관의 서명이 붙어 있다. 브라우저는 만료 여부와 호스트 이름 일치, 인증 기관까지 이어지는 신뢰 사슬을 확인하고, 서버가 해당 공개 키에 맞는 개인 키를 실제로 갖고 있는지도 검증한다.

다음은 키 교환이다. 흔히 알려진 옛 방식은 클라이언트가 임시 비밀값을 서버의 공개 키로 암호화해 보내는 형태지만, TLS 1.3에서는 이 방식이 제거됐다. 대신 양쪽이 일회용 공개값만 주고받고 각자 가진 비밀값과 조합해 같은 공유 비밀을 따로 계산해 낸다. 공유 비밀 자체는 네트워크를 건너가지 않는다. 덕분에 누군가 암호화된 트래픽을 지금 기록해 두었다가 나중에 서버의 인증서 개인 키를 훔쳐도 과거 세션은 풀 수 없다.

핸드셰이크가 끝나면 브라우저는 상대가 누구인지 알고 통신을 보호할 키도 갖게 된다. 이제 보내는 HTTP 요청은 경로와 헤더, 쿠키, 본문까지 암호화된다. 관찰자는 서버 IP 같은 연결 정보 정도만 볼 수 있을 뿐 내용을 읽거나 조용히 바꾸지 못한다. 이후 실제 데이터는 속도가 빠른 대칭 암호로 처리한다. 비대칭 암호는 신원 확인과 키 합의에는 유용하지만 대량 데이터에는 비용이 크기 때문이다.

주요 인사이트

• HTTPS를 'HTTP의 다른 버전'으로 이해하면 헷갈린다. 메시지 형식은 완전히 같고, 달라지는 것은 그 메시지가 지나가는 통로의 보안 모델뿐이다.
• 인증서는 데이터를 암호화하는 물건이 아니라 신원을 증명하는 문서다. 실제 통신을 감싸는 키는 핸드셰이크 과정에서 따로 만들어진다.
• 사람들이 아직도 'SSL 인증서'라고 부르지만 현대 HTTPS가 쓰는 것은 그 후속인 TLS다. 용어가 관습으로 남아 있는 셈이다.
• 많은 설명이 예시로 드는 옛 키 교환 방식은 공개 키와 개인 키의 역할을 이해하기엔 좋지만, 최신 표준에서 실제로 쓰이는 방식은 아니다.
• 브라우저 경고창을 무시하고 지나갈 때 사라지는 것은 '암호화'만이 아니다. 지금 접속한 서버가 정말 그 서비스인지 확인하는 절차 자체가 무너진다.

자주 묻는 질문

관련 AI 소식