포트 443: HTTPS

인터넷은 모든 사용자가 신뢰할 수 있다고 가정했던 시대에 만들어졌습니다. 대학의 연구자들, 정부 연구소, 방위 산업체 직원들—그들이 서로를 감시할 이유가 있었을까요? 그래서 초기 웹 프로토콜인 HTTP는 모든 것을 평문으로 전송했습니다. 모든 요청, 모든 응답, 모든 비밀번호, 모든 개인 메시지—네트워크를 지켜보는 누구에게나 읽힐 수 있었습니다.

포트 443은 인터넷을 처음부터 다시 만들지 않고도 그 가정을 바로잡는 방법입니다.

갑옷을 입힌 HTTP

HTTPS는 HTTP와 다른 프로토콜이 아닙니다—HTTP를 전송 계층 보안(TLS)으로 감싼 것입니다. 메시지 형식은 그대로이고, 겉으로 드러나는 것이 달라질 뿐입니다. 엽서와 봉투에 밀봉된 편지의 차이라고 생각하면 됩니다.

브라우저가 포트 443에 연결하면 HTTP 통신이 시작되기 전에 TLS 핸드셰이크가 이루어집니다. 서버는 디지털 인증서로 자신의 신원을 증명합니다. 클라이언트와 서버는 암호화 알고리즘을 협상하고 세션 키를 수립합니다. 그제야 익숙한 요청-응답 사이클이 시작됩니다—이제 네트워크를 감시하는 누구도 내용을 읽을 수 없습니다.

포트 80에서는 네트워크 트래픽을 감시하는 공격자가 모든 것을 볼 수 있습니다: 사용자 이름, 비밀번호, 신용카드 번호, 개인 메시지, 의료 관련 검색어, 새벽 2시에 읽는 기사들까지. 포트 443에서는 그 공격자에게 암호화된 노이즈만 보입니다.

대전환

"은행 거래에만 HTTPS를"에서 "모든 것에 HTTPS를"로의 전환은 인터넷 역사에서 가장 성공적인 보안 대전환 중 하나입니다.

여러 힘이 이 전환을 가속화했습니다. 2014년 구글은 HTTPS가 검색 순위를 높여줄 것이라고 발표했습니다—갑자기 보안이 "올바른 일을 하는 것" 이상의 사업적 이유를 갖게 되었습니다. 2016년에는 Let's Encrypt가 출시되어 자동 갱신 기능과 함께 신뢰할 수 있는 TLS 인증서를 무료로 제공했습니다. 소규모 사이트들이 HTTP에 머물게 했던 재정적·기술적 장벽이 하룻밤 사이에 사라졌습니다.

브라우저 제조사들도 압박을 높였습니다. 미묘한 보안 표시가 눈에 띄는 "안전하지 않음" 경고로 진화했습니다. HTTP가 오히려 설명이 필요한 것이 되어버렸습니다.

그 결과: 현재 웹 트래픽의 93% 이상이 HTTPS를 사용합니다. 주요 브라우저들은 일반 도메인 이름을 입력해도 먼저 HTTPS를 시도합니다. 질문이 "HTTPS를 써야 할까?"에서 "왜 HTTPS를 안 쓸까?"로 바뀌었습니다.

브라우저가 모든 HTTP 사이트에 경고를 표시하는 이유

브라우저들이 HTTP에 대한 경고를 표시하기 시작하자 웹사이트 운영자들은 반발했습니다. "제 사이트는 레시피만 있어요"라고 주장했습니다. "요리 블로그에 암호화가 왜 필요한가요?"

보안 커뮤니티는 이 주장을 받아들이지 않았습니다. 그 이유가 중요합니다.

첫째, 사용자는 민감한 페이지와 무해한 페이지를 구별할 수 없습니다. 그 레시피 사이트에도 로그인 페이지가 있습니다. "안전한" 사이트에서 HTTP를 허용하도록 사용자를 길들이면, 피싱 공격을 무시하도록 길들이는 것이기도 합니다.

둘째, 암호화되지 않은 트래픽은 전송 중에 변조될 수 있습니다. 커피숍 와이파이에 접속한 공격자는 그 레시피 페이지에 악성 자바스크립트를 삽입하여 합법적인 사이트를 악성코드 배포 지점으로 만들 수 있습니다. 사이트 소유자는 절대 알 수 없습니다. 이것은 이론상의 이야기가 아닙니다—항상 실제로 일어나고 있습니다.

셋째, HTTP는 내용이 무해해 보일 때도 여러분의 브라우징 패턴을 노출합니다. 관찰자는 여러분이 방문하는 모든 URL을 볼 수 있습니다: 검색하는 건강 상태, 찾는 재정 조언, 한밤중에 읽는 관계 관련 기사들까지. HTTPS는 URL 경로를 암호화하여 도메인 이름만 노출합니다.

넷째, 보편적인 암호화는 전체 생태계에 파급 효과를 일으킵니다. 사용자들이 어디서나 HTTPS를 기대하게 되면, 피싱 사이트와 손상된 연결이 더 쉽게 눈에 띕니다. 암호화가 예외가 아닌 기본값이 될 때 전체 생태계의 보안이 높아집니다.

인증서와 신뢰

HTTPS 서비스를 운영하려면 신뢰할 수 있는 인증 기관(Certificate Authority)이 서명한 TLS 인증서가 필요합니다. 인증서는 서버의 신원을 증명하고 암호화를 수립하기 위한 공개 키를 제공합니다.

브라우저가 HTTPS 사이트에 연결할 때, 신뢰 체인을 통해 인증서를 검증합니다. 서버의 인증서는 중간 기관이 서명하고, 그 중간 기관은 브라우저의 신뢰 저장소에 등록된 루트 기관이 서명합니다. 어떤 고리라도 끊어지면—만료된 인증서, 취소된 인증서, 잘못된 호스트 이름—브라우저가 경고를 표시합니다.

인증서 관리는 예전에는 고통스러운 일이었습니다: 수동 요청, 연간 갱신, 누군가 갱신을 잊었을 때의 새벽 3시 비상사태. ACME 프로토콜(Let's Encrypt가 선도한)이 이것을 바꿨습니다. 이제 서버는 인증서를 자동으로 요청하고, 검증하고, 설치하고, 갱신합니다. 사람이 직접 손댈 필요가 없습니다.

인증서 투명성 로그는 발급된 모든 인증서의 공개 감사 기록을 제공합니다. 누군가 인증 기관을 속여 여러분의 도메인에 대한 위조 인증서를 발급받으면 이를 탐지할 수 있습니다.

브라우저 너머

HTTPS는 웹 브라우저뿐만 아니라 어디서나 중요합니다. API, 모바일 앱, IoT 기기, 서버 간 통신—모두 HTTPS를 기본으로 점점 더 요구하고 있습니다.

API는 HTTPS를 강제합니다. HTTP로 전송된 인증 토큰은 너무나 쉽게 가로챌 수 있기 때문입니다. 토큰 하나가 도용되면 전체 시스템이 위험에 노출될 수 있습니다. PCI DSS, HIPAA, GDPR 같은 규정 준수 프레임워크는 전송 중 데이터의 암호화를 요구합니다.

모바일 앱은 특별한 도전에 직면합니다: 브라우저와 달리, 보안 경고를 위한 표준화된 UI가 없습니다. 사용자는 앱이 안전하지 않은 연결을 하고 있는지 알 수 없습니다. 현대 모바일 플랫폼은 기본적으로 HTTPS를 요구함으로써 이 문제를 해결합니다—iOS는 앱 전송 보안(App Transport Security)을 통해, 안드로이드는 네트워크 보안 구성(Network Security Configuration)을 통해서요. HTTP를 사용하려면 명시적으로 설정해야 합니다.

기기 간 통신에서는 종종 상호 TLS(mutual TLS)를 사용합니다. 클라이언트와 서버 모두 인증서를 제시하여 서로를 인증합니다. 도용될 비밀번호나 API 키 자체가 없습니다. 보안 수준이 높은 환경에서는 인증서 고정(certificate pinning)이 예상되는 인증서를 애플리케이션에 하드코딩하여 인증 기관이 침해되더라도 중간자 공격을 차단합니다.

교훈

포트 443은 업계가 공유 표준을 중심으로 협력할 때 전체 시스템의 보안을 개선할 수 있다는 것을 보여줍니다. 은행을 위한 값비싼 사치처럼 보였던 것이 모든 사람—그 레시피 블로그 포함—을 위한 기본 기준이 되었습니다.

인터넷은 개방성을 위해 설계되었습니다. 포트 443이 그 개방성을 지속 가능하게 만들었습니다.

포트 443과 HTTPS에 관한 자주 묻는 질문

왜 포트 443이 HTTPS에 사용되나요?

1024 미만의 포트 번호는 IANA가 표준 서비스에 할당한 "잘 알려진 포트"입니다. 포트 443은 1994년 프로토콜이 표준화될 때 HTTPS용으로 지정되었습니다. 선택 자체는 다소 임의적이었습니다—중요한 것은 모든 사람이 같은 포트를 사용하기로 합의하여 브라우저가 보안 트래픽을 위해 어디에 연결해야 하는지 알 수 있다는 점입니다.

HTTPS를 다른 포트에서 사용할 수 있나요?

가능하지만 불편함이 생깁니다. 포트 8443에서 HTTPS를 실행하면 사용자가 https://example.com:8443을 명시적으로 입력해야 합니다. 브라우저는 포트가 지정되지 않은 HTTPS URL에 대해 포트 443을 기본으로 가정합니다. 비표준 포트는 개발 환경에서는 흔하지만 프로덕션에서는 드뭅니다.

HTTPS가 웹사이트를 느리게 만드나요?

요즘은 체감할 만한 수준이 아닙니다. TLS 핸드셰이크가 초기 연결에 약간의 시간을 더하지만, 현대적인 최적화(TLS 1.3, 세션 재개, HTTP/2 멀티플렉싱)가 이 부담을 크게 줄였습니다. 오히려 많은 사이트가 HTTPS에서 더 빠릅니다. 상당한 성능 향상을 제공하는 HTTP/2가 브라우저에서 암호화된 연결에서만 지원되기 때문입니다.

자물쇠 아이콘은 실제로 무엇을 의미하나요?

자물쇠는 서버와의 연결이 암호화되어 있고 서버가 해당 도메인에 대한 유효한 인증서를 제시했음을 의미합니다. 웹사이트가 신뢰할 수 있거나 합법적이거나 안전하다는 의미는 아닙니다. 피싱 사이트도 유효한 인증서로 HTTPS를 사용할 수 있습니다. 자물쇠는 연결을 검증하는 것이지 목적지를 검증하는 것이 아닙니다.

일부 HTTPS 사이트가 여전히 경고를 표시하는 이유는 무엇인가요?

보통 "혼합 콘텐츠" 때문입니다—페이지는 HTTPS로 로드되었지만 일부 리소스(이미지, 스크립트, 스타일시트)가 HTTP로 로드된 경우입니다. 이러한 HTTP 리소스는 변조될 수 있으므로 보안 보장이 깨집니다. 브라우저는 암호화된 페이지의 무결성을 유지하기 위해 혼합 콘텐츠에 대해 경고하거나 차단합니다.