1년 전만 해도 스킴은 명확했습니다: TLS 핸드셰이크를 조작할 수 있는 클라이언트를 가져오고, 최신 Chrome에 맞는 프로필을 선택한 후, 일치하는 JA4를 얻으면 안티봇이 통과하게 됩니다. 그러나 2026년에는 이 레시피가 실패하기 시작했습니다. 그 이유는 '보안 우회'와는 전혀 관련이 없습니다. 브라우저들이 대규모로 포스트 양자 키 교환으로 전환했지만, 대부분의 스크래핑 스택은 그렇지 않았습니다. 이제 포스트 양자 키 공유의 부재 자체가 자동화의 지표가 되었습니다.
기준에 따라 살펴보겠습니다: 핸드셰이크에서 정확히 무엇이 변경되었는지, 어떤 스택이 이미 전환되었는지, 어떤 스택이 그렇지 않은지, 그리고 왜 일치하는 해시 JA4가 충분한 조건이 되지 않는지.
무슨 일이 일어났는가: 포스트 양자 교환이 이국적인 것이 아닌 표준이 되었다
하이브리드 포스트 양자 키 교환은 고전적인 타원 곡선 X25519와 격자 기반 메커니즘 ML-KEM(NIST FIPS 203 표준)의 조합입니다. 세션은 두 구성 요소 중 하나라도 견고하다면 보호됩니다. 이의 의미는 '지금 가로채고 나중에 해독하라'는 시나리오로부터의 보호입니다. 이는 트래픽이 미래의 양자 컴퓨터를 염두에 두고 아카이브에 기록되기 때문입니다.
클라이언트에서의 도입 연대기:
- Chrome 124 (2024년 4월) — 하이브리드 포스트 양자 교환이 기본적으로 활성화됨; curl-impersonate 패치에서 'Chrome 124 및 130에 도입된 X25519Kyber768/X25519MLKEM 곡선'으로 기록됨.
- Firefox 132 (2024년 11월) — 지원이 활성화됨.
- iOS 및 macOS의 Safari — 포스트 양자 교환이 2025년 10월에 도입됨.
- OpenSSL 3.5.0 (2025년 4월) — 하이브리드 그룹 X25519MLKEM768, SecP256r1MLKEM768 및 SecP384r1MLKEM1024가 TLS 기본 그룹 목록에 포함됨.
- Go 1.24 (2025년 2월) — Config.CurvePreferences가 명시적으로 설정되지 않은 경우 X25519MLKEM768이 crypto/tls에 기본적으로 포함됨.
인프라 측면에서 상황은 더욱 뚜렷합니다. 2026년 4월 Cloudflare Radar는 약 67%의 인간 HTTPS 트래픽이 포스트 양자 암호화로 이루어졌다고 보여주었습니다 — 2025년 1월의 32%에 비해. Akamai는 2026년 1월 31일에 모든 클라이언트 연결에 대해 포스트 양자 키 교환을 기본값으로 설정하고, 3월에 네트워크 전반에 걸쳐 배포를 완료했습니다. 업계 측정에 따르면, 약 57.4%의 모든 브라우저 트랜잭션이 이미 포스트 양자 준비가 되어 있으며, Chrome의 경우 PQ를 지원하는 비율은 약 93%입니다.
비대칭성에 주목하십시오: 오리진 서버 측의 지원은 훨씬 느리게 증가하고 있습니다(Cloudflare의 경우 약 9%). 즉, 오늘날 포스트 양자성은 주로 클라이언트의 특성입니다. 이는 안티봇에게 흥미로운 점입니다.
기준 1: 키 공유의 크기와 ClientHello 구조
포스트 양자 키 공유는 '확장 내의 또 다른 플래그'가 아닙니다. 그것은 물리적으로 큽니다: 약 1124 바이트에 비해 고전적인 X25519는 36 바이트입니다. 그 결과는 패킷 수준에서 명확히 드러납니다.
포스트 양자 키 공유를 포함한 ClientHello는 1400 바이트를 초과하여 하나의 TCP 세그먼트에 들어가지 않게 됩니다. 두 개 이상의 패킷으로 나누어집니다. 그리고 여기서 감지에 가장 흥미로운 부분이 시작됩니다: 다양한 구현에서의 조각화 패턴은 다릅니다. 스택이 큰 ClientHello를 어떻게 자르고, 세그먼트를 어떤 순서로 보내며, 어떤 타이밍으로 보내는지는 관찰 가능한 행동이며, 이는 JA4 해시에서 도출되지 않으며, 거의 모든 스크래핑 도구 작성자가 의식적으로 재현하지 않습니다.
실용적인 결론: 안티봇에게는 기존의 지문보다 아래에서 작동하는 레이어가 생겼습니다. 암호 및 확장 목록을 완벽하게 수집할 수 있지만, 스택이 바이트를 소켓에 넣는 방식으로 자신을 드러낼 수 있습니다.
기준 2: 선언된 브라우저 버전과의 일관성
2026년의 주요 함정은 자신이 누구인지와 실제로 TLS 스택이 수행하는 것 사이의 비동기입니다.
안티봇 플랫폼은 기준 ClientHello의 데이터베이스를 유지합니다. User-Agent와 JA4에서 Chrome 131을 선언하지만 포스트 양자 키 공유 없이 오는 요청은 어떤 알려진 유효한 Chrome 131과도 일치하지 않습니다. 이는 '의심스럽다'가 아니라 논리적으로 불가능한 조합입니다. 실제 Chrome은 기본 설정에서 고전적인 키 공유를 보낼 수 없습니다.
기계 학습이 이를 얼마나 잘 구분하는지도 계산되었습니다. JA4 특성을 기반으로 한 CatBoost 분류기는 연구에서 AUC 0.998 및 정확도 0.9863을 보여줍니다; 포스트 양자 트래픽은 고전적인 트래픽과 약 98%의 정확도로 구별됩니다. 이는 '거짓 긍정이 있는 휴리스틱'이 아니라 거의 결정적인 특성입니다.
기준 3: 특정 스택의 준비 상태
여기서 진정한 경계가 발생합니다. 그룹으로 나누어 보겠습니다.
기본적으로 PQ 키 공유를 전송합니다
- Chrome 124+, Firefox 132+, Safari (2025년 10월부터 iOS/macOS) — 비교 기준입니다.
- Go 1.24+ — crypto/tls는 CurvePreferences를 재정의하지 않는 한 X25519MLKEM768을 자동으로 포함합니다. 중요한 점: 포스트 양자성이 있지만, 기본 Go 클라이언트의 JA4는 여전히 브라우저와 다릅니다. 'PQ 호환이지만 Chrome과는 다른' 지문을 얻게 됩니다.
- Node.js 24 — 자체 OpenSSL 3.5를 포함하고 있어 기본 그룹 목록에 하이브리드가 포함되어 있습니다. 또한 node:crypto에 ML-KEM이 crypto.encapsulate()/decapsulate() 및 ML-DSA에서 sign()/verify()를 통해 추가되었습니다.
연결된 것에 따라 다릅니다
- Python: requests, aiohttp, httpx — ssl 모듈을 사용하며, 이는 시스템 OpenSSL을 사용합니다. Ubuntu 24.04에서는 OpenSSL 3.0.x가 시스템에 있으며, 포스트 양자 그룹이 전혀 없습니다. PQ를 얻으려면 OpenSSL 3.5를 소스에서 빌드하고 LD_LIBRARY_PATH를 통해 추가해야 하며, 아마도 Python 자체를 다시 빌드해야 합니다. 실제로 이는 2026년의 전형적인 Python 스크래퍼가 고전적인 키 공유를 전송하고 Akamai에서 이상으로 보인다는 것을 의미합니다.
가능하지만 올바른 프로필을 선택해야 합니다
- curl_cffi / curl-impersonate — 포스트 양자 곡선에 대한 지원이 포크에 존재하며 명시적으로 선언되어 있습니다. 그러나 타겟 목록은 chrome99부터 chrome146까지(포크에서는 chrome150까지) 이어지며, 오래된 프로필은 그 시대의 핸드셰이크를 재현하므로 PQ 없이 진행됩니다. 2년 전 가이드에서
impersonate="chrome116"를 복사하는 것은 감지로 가는 직접적인 경로입니다. - uTLS — 동일한 원칙: HelloChrome 프로필 131 이하에는 PQ 키 공유가 포함되어 있지 않습니다. 또한 2026년 버전에서 두 개의 지문 취약점이 수정되었습니다: CVE-2026-26995 (버전 1.6.0–1.8.1) 및 CVE-2026-27017 (1.6.0–1.8.0, GREASE ECH에 대한 암호 선택 비동기 — Chrome은 이를 결정적으로 선택하지만, uTLS의 parrot는 AES와 ChaCha20 사이에서 동전을 던졌습니다. 이는 실제 Chrome에서는 불가능합니다). 최소한 1.8.2로 업데이트해야 합니다.
공통점: 도구들이 대부분 따라잡았습니다. 문제는 그들이 아니라 구성이 브라우저보다 더 빨리 노후화된다는 점입니다. 2024년에 완벽했던 프로필이 오늘날에는 마커로 작용합니다.
5분 안에 스택을 확인하는 방법
- 전투 클라이언트로
https://tls.peet.ws/api/all또는ja4db.com에 요청을 보내십시오 — 이들은 실시간 JA3/JA4 및 ClientHello 분석을 JSON 형식으로 반환합니다. - 분석에서 supported_groups 및 key_share 목록을 찾으십시오. X25519MLKEM768(또는 오래된 프로필의 경우 X25519Kyber768)를 찾으십시오. 만약 x25519/secp256r1만 있다면 — 포스트 양자 교환이 없습니다.
- 이것을 자신이 선언한 브라우저 버전과 비교하십시오. Chrome 131+을 선언하고 PQ 그룹을 보지 못한다면 — 조합이 유효하지 않으니 프로필을 수정하십시오.
- ClientHello의 크기를 확인하십시오. 선언된 최신 Chrome에서 ~1400 바이트 미만이라면 — 동일한 징후이며, 다른 측면에서 나타납니다.
- 작업 머신뿐만 아니라 모든 출구 노드에서 검사를 실행하십시오: 기업 게이트웨이나 공급자의 SSL 검사기가 핸드셰이크를 수정할 수 있습니다.
여기서 프록시가 하는 일
두 개의 독립적인 레이어를 혼합하지 않는 것이 중요합니다. 포스트 양자 키 공유는 핸드셰이크에 관한 것이고, 주소의 평판은 네트워크에 관한 것입니다. 안티봇은 이를 별도로 고려하고 합산합니다.
여기서 두 가지 실용적인 결과가 나옵니다. 첫 번째: 이상적인 레지던트 IP는 TLS 레벨에서 PQ 그룹 없이 Chrome 131로 자신을 드러내는 요청을 구할 수 없습니다 — 서버가 주소를 확인하기 전에 이미 패배하게 됩니다. 두 번째, 반대로: 올바르게 구성된 포스트 양자 핸드셰이크는 수백 개의 세션이 평판이 손상된 동일한 데이터 센터 서브넷에서 오는 경우 도움이 되지 않습니다. 두 레이어를 모두 수정해야 하며, 수정하는 도구는 다릅니다.
작업에 대한 실용적인 분류: Akamai와 Cloudflare의 목표를 위해, 여기서는 핸드셰이크와 네트워크를 모두 고려하므로 레지던트 프록시를 사용하고 동시에 타겟 impersonate를 최신 Chrome으로 올리는 것이 합리적입니다. 모바일 애플리케이션과 IP 평판의 중요성이 TLS 요구 사항보다 높은 플랫폼에서는 모바일 프록시가 더 자주 이깁니다. 그리고 안티봇이 없는 자체 API, 파트너 데이터 덤프 및 내부 모니터링의 경우 레지던트에 대해 과도한 비용을 지불할 필요는 없습니다 — 데이터 센터 프록시로 충분합니다.
지문을 처음부터 다루고 있다면, 기본부터 시작하십시오: JA4가 어떻게 구성되어 있고 무엇을 포함하는지. HTTP 클라이언트가 아닌 완전한 브라우저에 관한 경우, 스텔스 빌드와 그 약점에 대한 비교는 별도로 수집되었습니다 — nodriver, Camoufox 및 Patchright의 2026년 측정.
결론
포스트 양자 키 교환은 안티봇 메커니즘으로 설계되지 않았습니다. 그것은 부수적으로 그렇게 되었습니다: 브라우저들이 빠르고 대규모로 전환하였고, 인프라(Akamai는 2026년 1월 31일부터)는 이를 기본값으로 설정하였으며, 스크래핑 스택은 세 그룹으로 나뉘었습니다 — 이미 전환된 것, 시스템 OpenSSL에 의존하는 것, 그리고 최신 프로필에서만 가능한 것.
검사는 하나의 질문으로 귀결됩니다: 클라이언트가 X25519MLKEM768을 전송하고, 자신이 선언한 브라우저 버전과 일치하는가. 그렇지 않다면 — 일치하는 JA4가 당신을 구해주지 않을 것입니다. 왜냐하면 이제 해시가 아니라 핸드셰이크의 전체 형태가 비교되기 때문입니다: 키 공유의 크기, TCP 세그먼트의 수 및 전송 순서. 좋은 소식은 대부분의 경우 프로필 및 라이브러리 버전을 업데이트하여 수정할 수 있다는 것입니다. 스크래퍼를 다시 작성할 필요는 없습니다.