TLS는 실제로 HTTPS 연결을 어떻게 보호할까?

사람들은 "HTTPS는 암호화를 의미한다"고 말하고 끝내지만, 흥미로운 부분은 인터넷의 낯선 두 사람이 네트워크를 통해 누군가 들을 수 있는 상황에서 실제로 만나지 않고도 공유 비밀에 동의하는 방식이다. 이것이 TLS가 하는 일이며, 네트워킹, 웹 개발, 보안을 다루는 사람이라면 그 메커니즘을 이해할 가치가 있다.

핸드셰이크, 단계별

브라우저가 https://example.com에 연결할 때, 대략 다음과 같이 진행된다(대부분의 사이트가 현재 사용하는 TLS 1.3):

1. ClientHello — 브라우저가 지원하는 암호화 제품군, 임의의 nonce, 키 교환을 위한 키 공유(X25519 또는 secp256r1과 같은 것 사용)에 대한 추측을 전송한다.
2. ServerHello — 서버가 암호화 제품군을 선택하고, 자신의 키 공유를 전송한 뒤 인증서와 그 인증서와 일치하는 개인 키를 보유하고 있음을 증명하는 서명을 반환한다.
3. 키 도출 — 양쪽이 이제 키 공유에 대해 Diffie-Hellman 스타일의 수학을 사용하여 동일한 공유 비밀을 독립적으로 계산한다. 어느 쪽도 비밀 자체를 전송하지 않으며, 이는 도출되는 것이지 전송되는 것이 아니다.
4. Finished 메시지 — 양쪽이 핸드셰이크 전체 기록에 대한 MAC을 전송하여 핸드셰이크가 변조되지 않았음을 확인한다.

그 후, 모든 것은 공유 비밀에서 도출된 대칭 키(일반적으로 AES-128-GCM 또는 ChaCha20-Poly1305)로 암호화된다. TLS 1.3은 TLS 1.2의 2왕복 핸드셰이크를 효과적으로 1왕복으로 축소하여 규모에서 실제 지연 시간을 절감했다.

인증서가 암호화보다 더 중요한 이유

신원 검증 없는 암호화는 무의미하다 — 누구나 공격자가 중간자 공격을 수행하는 것을 포함하여 암호화된 채널을 설정할 수 있다. 인증서는 공개 키를 도메인 이름에 연결하는 것이며, Let's Encrypt나 DigiCine 같은 인증기관(CA)에 의해 서명된다.

브라우저는 OS나 브라우저 신뢰 저장소에 내장된 루트 CA의 고정된 목록을 신뢰한다. 서버의 인증서는 중간 인증서를 통해 그 루트 중 하나로 연결된다. 체인이 검증되지 않거나 인증서의 도메인이 요청한 도메인과 일치하지 않으면 빨간 경고 페이지가 표시된다. 이 신뢰 체인 모델이 실제 보안 경계다 — CA의 서명 키를 도용하면 모든 도메인에 대해 유효한 인증서를 발행할 수 있으므로 CA 침해가 주요 사건으로 취급되는 이유다.

대칭 및 비대칭 암호화가 여기서 하는 일

비대칭 암호화(RSA 또는 타원곡선)는 느리고 비용이 많이 들므로 TLS는 핸드셰이크 중에만 사용한다 — 서버를 인증하고 공유 비밀 설정을 돕기 위해. 그 후, 모든 실제 데이터(HTML, JSON 등)는 빠른 대칭 암호화로 암호화된다. 이 하이브리드 접근법은 SSH, PGP, 대부분의 실제 암호화 시스템에서 볼 수 있는 동일한 패턴이다: 신원 및 키 교환을 위한 비대칭, 대량 데이터를 위한 대칭.

전방 보안은 관련된 상세한 부분으로 알 가치가 있다: 공유 비밀이 세션마다 새로 생성되는 임시 Diffie-Hellman 키 공유에서 나오기 때문에, 누군가 트래픽을 기록했다가 나중에 서버의 개인 키를 도용하더라도 여전히 이전 세션을 복호화할 수 없다. 이 특성은 RSA만 사용하는 이전 키 교환에는 없었다.

직접 확인하기

녹색 자물쇠 아이콘을 맹목적으로 신뢰할 필요는 없다. 다음을 실행하자:

openssl s_client -connect example.com:443 -tls1_3

이것은 협상된 암호화 제품군, 인증서 체인, 핸드셰이크가 실제로 완료되었는지 여부를 표시한다. 브라우저가 보는 것을 빠르게 확인하려면 curl -v https://example.com으로 HTTP 응답 전에 TLS 버전과 인증서 세부 정보를 출력한다.

Chrome 또는 Firefox를 시작하기 전에 SSLKEYLOGFILE 환경 변수를 내보내면 Wireshark에서 자신의 트래픽을 복호화할 수 있다 — TLS 문제를 추측하는 대신 실제로 디버깅하는 데 유용하다.

실제로 이것이 중단되는 곳

대부분의 실제 HTTPS 오류는 암호화 중단이 아니라 운영 문제다: 만료된 인증서, 잘못 구성된 중간 체인, 오래된 TLS 버전에 고착된 클라이언트, 또는 혼합 콘텐츠(HTTPS 페이지가 HTTP 리소스를 로드). 최신 TLS 1.3에 대한 실제 프로토콜 수준 공격은 드물다. 왜냐하면 사양이 SSL 3.0과 초기 TLS를 괴롭혔던 대부분의 패딩 오라클 및 다운그레이드 트릭을 막았기 때문이다. 약점은 보통 끝점이다 — 손상된 CA, 도용된 개인 키, 또는 사용자가 무시해야 할 인증서 경고를 클릭함.

더 깊이 있게 배우고 싶다면, Korra Studio의 네트워킹 및 암호화 세그먼트에서 기본 Diffie-Hellman 수학과 패킷 수준 프로토콜 분석을 더 깊이 다룬다.