현대 스크레이퍼가 사용자 지정 지문으로 TLS를 우회하는 방법

bonnie

2025-11-29 05:47

웹 스크래핑을 해본 사람이라면, 최근 몇 년 사이에 각종 CAPTCHA뿐 아니라 점점 더 “똑똑해지는” 반(反)스크래핑 기술이 개발자들에게 가장 큰 골칫거리가 되고 있다는 것을 잘 알고 있을 것입니다.

특히 TLS 핑거프린팅, HTTP/2 핑거프린팅, 브라우저 핑거프린팅과 같은 최신 기술의 등장으로, 이제는 헤더를 추가하거나 User-Agent를 바꾸는 정도로는 시스템을 속일 수 있는 시대가 아닙니다.

그렇다면 웹사이트는 어떻게 TLS와 HTTP/2 핑거프린트만으로 사용자가 “스크래퍼”인지 “진짜 브라우저”인지 구분할 수 있을까요? 다음에서 자세히 설명하겠습니다.

1. 왜 웹사이트는 TLS 핑거프린팅을 사용하는가?

이유는 간단합니다—전통적인 User-Agent / 쿠키 / IP 기반의 제한은 더 이상 효과가 없기 때문입니다.

실제 브라우저가 HTTPS 연결을 설정할 때, TLS 핸드셰이크가 수행됩니다. 이 핸드셰이크에는 매우 세부적인 정보가 대량으로 포함되어 있습니다. 예를 들어:

이러한 조합은 브라우저, 운영체제, 버전에 따라 모두 다릅니다.

서버가 보게 되는 것은 다음과 같습니다:

“이 TLS ClientHello는 Chrome도 Firefox도 Safari도 아닌데? 스크립트로 생성된 클라이언트일 가능성이 높다.”

이것이 TLS 핑거프린팅의 기본 원리입니다.

TLS 핑거프린팅이 첫 번째 필터라면, HTTP/2 핑거프린팅은 두 번째 필터입니다.

HTTP/2에는 다음과 같은 특징이 있습니다:

이러한 요소들은 실제 브라우저에서는 매우 일관성을 보이지만, 많은 네트워크 라이브러리(예: 기본 Python/Go 구현)에서는 크게 다릅니다.

따라서 스크래퍼를 “더 사람처럼” 보이게 하려면 HTTP/2 계층의 핑거프린트 차이도 해결해야 합니다.

TLS / H2와 같은 네트워크 계층을 넘어, 브라우저 자체도 많은 핑거프린트를 노출합니다.

ToDetect 핑거프린팅 도구가 전문적이라고 평가받는 이유가 바로 이것이며, 단일 포인트가 아닌 다차원적 분석을 기반으로 하기 때문입니다.

최신 스크래핑 프레임워크는 “핑거프린트 템플릿” 방식을 자주 사용합니다. 이는 다양한 브라우저, 운영체제, 버전의 TLS / HTTP/2 / JS 환경의 핑거프린트를 미리 기록하여 핑거프린트 라이브러리를 만든다는 의미입니다.

이 라이브러리에는 다음과 같은 정보가 포함될 수 있습니다:

요청을 보낼 때 스크래퍼는 이러한 템플릿 중 하나를 선택하여 “진짜 브라우저처럼” 보이게 됩니다.

이는 “화장”과 같습니다—아무렇게나 칠하는 것이 아니라 실제 사람의 얼굴을 모방하는 것입니다.

그 이유는 실제 브라우저의 행동이 안정적이고 일관적이며 예측 가능하기 때문입니다.

스크래퍼가 실제 브라우저의 행동 패턴을 “학습”하면 당연히 탐지가 더 어려워집니다. 예를 들어:

TLS 핑거프린팅, HTTP/2 핑거프린팅, 브라우저 핑거프린팅은 본질적으로 인터넷 보안 기술입니다. 이러한 기술은 반드시 법적으로, 사이트 이용약관을 준수하는 범위에서만 사용해야 하며, 허가받지 않은 데이터 수집이나 접근 우회 목적으로 사용되어서는 안 됩니다.

합법적이고 승인된 환경—예: 자체 사이트의 반(反)스크래핑 성능 테스트, 리스크 제어 전략 개선, 보안 연구 등—에서는 핑거프린트 시뮬레이션 기술이 매우 유용합니다.