TLS 1.0과 1.1은 브라우저에서는 죽었고, 인프라에서는 짜증 나게 살아 있다.
그 엇갈림이 이야기 전부다.
브라우저의 눈으로 웹을 보면 이전은 거의 끝난 것처럼 보인다. 서버와 장비의 긴 꼬리를 보면, 모두가 없애자고 합의한 지 몇 년이 지나도 인터넷 어딘가에서 계속 덜그럭거리는 기술 중 하나로 보인다. 폐기는 정책 사건이다. 제거는 청소 작업이다. 둘은 같이 움직이지 않는다.
브라우저 쪽 이야기는 끝났다
RFC 8996이 2021년 3월 TLS 1.0과 1.1을 공식 폐기했다. 브라우저는 이미 움직인 뒤였다. Chrome, Firefox, Safari, Edge 모두 2020년 무렵 옛 버전을 껐다. TLS 1.0만 지원하는 사이트는 추억의 핸드셰이크를 받지 못한다. 에러 페이지를 받는다.
이 부분은 정리됐다. 사용자 입장에서 옛 TLS는 사라졌다.
서버 쪽 이야기는 안 끝났다
약 15만 개의 인기 HTTPS 사이트를 추적하는 Qualys SSL Pulse는 수년째 TLS 1.0·1.1 지원이 줄어드는 추이를 그려 왔고, SSL Labs는 이 버전을 아직 제공하는 서버의 등급을 B로 묶는다. 인기 사이트는 쉬운 쪽이다. 범위를 넓히면 그림이 덜 좋다. SANS 인터넷 스톰 센터에 Jan Kopriva가 쓴 Shodan 데이터 연말 분석에 따르면, 2024년 한 해 동안 TLS 1.0·1.1 지원은 443번 포트에 응답하는 서버의 약 22%에서 거의 그대로였다. 주요 브라우저 중 어느 것도 이 버전으로 협상하지 않던 해에 말이다.
그러니 “아직 누가 쓰는가?”에 대한 답은 이렇다. 큰 사이트는 아니다. 작은 서버, 잊힌 인프라, 아무도 업데이트하지 않는 장비 — 인터넷의 긴 꼬리가 옛 TLS가 숨는 곳이다.
이런 서버 상당수는 더 이상 브라우저에 웹 페이지를 내주지 않는다. 레거시 클라이언트에 API를 내주거나, 프로토콜 버전이 박혀 있는 기계 간 통신을 처리하거나, 2018년 이후 설정을 한 번도 안 바꾼 로드 밸런서 뒤에 앉아 있다.
왜 남아 있나
결제 단말기. 오래된 POS 단말기와 결제 장비에는 TLS 1.0까지만 말하는 펌웨어가 들어 있을 수 있다. 흩어져 있는 수천 대의 펌웨어를 바꾸는 건 설비 투자라서 해마다 미뤄진다. PCI DSS는 2018년 6월 30일까지 SSL과 초기 TLS에서 벗어나라고 요구했지만, 알려진 공격에 취약하지 않다고 입증할 수 있는 POS 단말기와 그 단말기가 접속하는 서버에는 예외를 뒀다. 이런 예외는 대개 이유보다 오래 산다.
임베디드·산업 시스템. SCADA 컨트롤러, 의료 기기, 건물 관리 시스템 — 수명이 10~20년이고 원격 업데이트 수단이 없는 하드웨어다. TLS 라이브러리는 제조할 때 구워져 들어갔다. 라이브러리를 바꾸려면 장비를 바꿔야 한다.
“돌아가니까 건드리지 마.” 아마 가장 흔한 이유. 서버가 몇 년째 돌고 있다. 뭐가 붙는지 정확히 아는 사람이 없다. TLS 1.0을 끄면 모르는 클라이언트가 깨질 수도 있다. 뭔가 깨뜨릴 위험이 켜 둘 때의 위험보다 크게 느껴진다. 그래서 그대로 둔다.
잊힌 서버. 몇 년 전에 띄운 가상 머신이 아직 돌고, 아직 접속되고, 아무도 관리하지 않는다. 설정할 당시 기본값이라 옛 TLS가 켜져 있다. 그 뒤로 아무도 로그인하지 않았다.
특정 버전을 적어 둔 규정. 어떤 규제 환경은 요구 사항에 프로토콜 버전을 적는다. 2015년 문서에 “TLS 1.0 이상 사용”이라고 적혀 있으면, 대충 읽은 결과로 1.0이 새 버전들과 나란히 켜진 채 남는다.
켜 둘 때의 위험
TLS 1.0에는 알려진 취약점이 있다. BEAST(2011)는 TLS 1.0의 예측 가능한 CBC 초기화 벡터를 이용해 데이터를 복호화한다. POODLE(2014)은 주로 SSL 3.0 공격이었지만, 나중에 패딩 검사를 건너뛰는 TLS 구현을 노린 변종이 나왔다. 1.0과 1.1 모두 AES-GCM이나 ChaCha20-Poly1305 같은 AEAD 암호 스위트를 지원하지 않고, 핸드셰이크 안에서 MD5와 SHA-1에 기댄다 — RFC 8996이 이 둘을 은퇴시킨 핵심 근거다.
TLS 1.1은 BEAST의 초기화 벡터 문제를 고쳤지만, 여전히 현대 암호 스위트도, TLS 1.2가 도입한 더 강한 핸드셰이크 해시도 없다.
그럼 실제로 위험한 건 누구인가? 최신 브라우저는 아니다. TLS 1.2 아래로는 아예 내려가지 않고, TLS 1.3에는 다운그레이드 확인 장치가 들어 있으며, 그 전부터 TLS_FALLBACK_SCSV 신호도 있었다. 노출된 건 아직도 1.0이나 1.1로 접속하는 클라이언트다 — 낡은 단말기, 잊힌 스크립트, 임베디드 장비. 그 트래픽은 약점이 알려진 프로토콜 위로 흐르고, 서버가 받아 주는 한 아무도 그런 클라이언트가 있다는 걸 모른다. 다른 사람은 몰라도 감사는 알아챈다. PCI 스캔도 SSL Labs 등급도 이걸 지적한다.
흔한 반론은 이렇다. “어차피 우리 클라이언트는 전부 1.2나 1.3으로 붙는데.” 그게 사실이라면 1.0을 꺼도 잃을 게 없다. 사실이 아니라면, 방금 내 클라이언트에 대해 중요한 걸 하나 알게 된 것이다.
폐기와 제거 사이의 간극
브라우저는 빨랐다. 메이저 릴리스 몇 번 만에 클라이언트 쪽에서 옛 TLS가 사라졌다. 결정이 중앙에 모여 있었다 — 브라우저 벤더 몇 곳이 생태계 전체를 쥐고 있다.
서버는 빙하처럼 느리다. 독립적인 서버 운영자가 수백만이고, 각자 설정을 결정한다(혹은 결정하지 않는다. 그게 더 나쁘다). 모든 서버의 TLS 1.0을 한 번에 끌 수 있는 중앙 권한은 없다. 누군가 기억날 때, 접근 권한이 있다면, 설정 파일 하나씩 바뀐다.
이 비대칭 — 빠른 클라이언트 폐기, 느린 서버 제거 — 때문에 옛 TLS는 주류 브라우저가 못 쓰게 된 뒤로도 몇 년 동안 인터넷에서 관측될 것이다. 프로토콜은 폐기됐다. 청소에는 10년이 걸릴 것이다.
해야 할 일
서버가 아직 TLS 1.0이나 1.1을 제공한다면 오늘 끄자. 설정을 확인하라.
nginx: ssl_protocols TLSv1.2 TLSv1.3;
Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
정상적인 최신 클라이언트 중 TLS 1.0이나 1.1이 필요한 것은 없다. 껐을 때 뭔가 깨진다면, 그건 이미 보안 부채였다. 사고 중에 찾는 것보다 지금 찾는 게 낫다.
표준이 폐기했다. 브라우저가 거부했다. TLS 1.0을 살려 두는 건 관성뿐이다. 그리고 관성은 보안 전략이 아니다.