TLS Fingerprinting là gì? JA3 và JA4 được giải thích

Tóm lại:

• Nhận dạng dấu vân tay TLS xác định phần mềm khách hàng từ quá trình bắt tay TLS, trước khi gửi một byte HTTP nào. Một máy chủ đọc ClientHello — các phiên bản TLS, bộ mã hóa và phần mở rộng mà khách hàng của bạn cung cấp — và tạo ra một băm cho biết "đây là Chrome" hoặc "đây là một đoạn mã Python."
• JA3 là phương pháp ban đầu; JA4 là phiên bản hiện đại của nó. JA3 (từ Salesforce) đã băm các trường ClientHello thô theo thứ tự, vì vậy khi Chrome bắt đầu ngẫu nhiên hóa thứ tự phần mở rộng TLS của mình, các băm JA3 trở nên không ổn định. JA4 sắp xếp các bộ mã hóa và phần mở rộng trước, vì vậy dấu vân tay giữ được ổn định.
• JA4 có thể đọc được bởi con người, không phải là một băm mờ đục duy nhất. Định dạng a_b_c của nó mã hóa phiên bản TLS, sự hiện diện của SNI, số lượng bộ mã hóa và phần mở rộng, và ALPN ngay từ đầu, sau đó băm các danh sách bộ mã hóa và phần mở rộng đã sắp xếp — để bạn có thể so khớp trên một phần của nó, không chỉ toàn bộ.
• Một khách hàng HTTP tùy chỉnh có một dấu vân tay không phải của trình duyệt. requests, curl, hoặc một thư viện đã được sửa đổi gửi một bộ mã hóa/phần mở rộng mà không có trình duyệt Chrome thực sự nào sẽ làm, vì vậy JA4 của nó nổi bật ngay cả khi ở phía sau một IP sạch.
• Một trình duyệt thực sự là câu trả lời đáng tin cậy. Trình duyệt Scrapeless Scraping là Chromium thật, vì vậy ClientHello của nó — và do đó là JA3/JA4 của nó — là của một Chrome thực sự, không thể phân biệt với của một khách truy cập thông thường.
• Miễn phí để bắt đầu. Tài khoản Scrapeless mới bao gồm thời gian chạy Scraping Browser miễn phí — đăng ký tại app.scrapeless.com.

---

Giới thiệu: quá trình bắt tay tiết lộ bạn trước HTTP

Nhận dạng dấu vân tay TLS xác định phần mềm đứng sau một kết nối từ cách nó mở phiên TLS, không từ bất cứ điều gì nó gửi sau đó. Mỗi kết nối HTTPS bắt đầu với một thông điệp ClientHello trong đó khách hàng quảng bá các phiên bản TLS mà nó hỗ trợ, các bộ mã hóa mà nó ưa thích và một danh sách các phần mở rộng. Những lựa chọn đó khác nhau giữa một Chrome thực sự, một chương trình Go và một đoạn mã Python, và một máy chủ có thể băm chúng thành một định danh gọn gàng mà vẫn tồn tại ngay cả khi IP, tác nhân người dùng và cookie trông hoàn toàn bình thường.

Đó là lý do tại sao một công cụ thu thập dữ liệu có thể quay vòng các proxy dân cư, làm giả tác nhân người dùng Chrome và vẫn bị chặn: quá trình bắt tay TLS 1.3 mà nó gửi chưa bao giờ giống Chrome ngay từ đầu. Hướng dẫn này giải thích dấu vân tay TLS là gì, cách JA3 và JA4 tính toán nó, và tại sao chạy một trình duyệt thực sự là cách bền vững để trình bày một dấu vân tay thuộc về.

---

Dấu vân tay TLS được xây dựng từ đâu

Dấu vân tay TLS là một băm của các trường trong ClientHello, thông điệp đầu tiên mà khách hàng gửi khi mở một kết nối TLS. Các đầu vào là các thuộc tính ổn định của thư viện và cấu hình TLS của khách hàng:

• Phiên bản TLS được cung cấp (ví dụ, TLS 1.2 hoặc 1.3).
• Các bộ mã hóa mà khách hàng hỗ trợ, theo thứ tự mà nó liệt kê.
• Các phần mở rộng mà khách hàng bao gồm (SNI, ALPN, nhóm hỗ trợ, thuật toán chữ ký, và nhiều hơn nữa).
• Các đường cong ellip và định dạng điểm mà nó quảng bá.

Ngăn xếp TLS của một trình duyệt tạo ra một sự kết hợp cụ thể, nhất quán của các giá trị này; một thư viện kịch bản tạo ra một sự kết hợp khác. Bởi vì dấu vân tay được lấy từ lớp vận chuyển, nó không phụ thuộc vào tiêu đề và cookie — thay đổi tác nhân người dùng của bạn không ảnh hưởng gì đến nó.

JA3: dấu vân tay TLS ban đầu, và tại sao nó đã hỏng

JA3 là dấu vân tay TLS đầu tiên được áp dụng rộng rãi, được công bố bởi các kỹ sư tại Salesforce vào năm 2017. Nó nối năm trường ClientHello — phiên bản TLS, bộ mã hóa, phần mở rộng, đường cong ellip, và định dạng điểm đường cong ellip — theo thứ tự chúng xuất hiện, sau đó lấy băm MD5 của chuỗi đó, bỏ qua các giá trị GREASE được dự trữ bởi đặc tả TLS.

Sự phụ thuộc vào thứ tự trở thành điểm yếu của JA3. Vào năm 2023, Chrome đã bắt đầu ngẫu nhiên hóa thứ tự của các phần mở rộng TLS trên mỗi kết nối, vì vậy một cài đặt Chrome duy nhất tạo ra một băm JA3 khác nhau từ yêu cầu này sang yêu cầu khác. Một dấu vân tay thay đổi theo từng kết nối là vô dụng để xác định một khách hàng, vì vậy các nhà cung cấp phát hiện cần một phương pháp không phụ thuộc vào thứ tự.

JA4: thay thế hiện đại, ổn định theo thứ tự

JA4 là dấu vân tay của khách hàng TLS trong JA4+, một bộ các phương pháp nhận dạng mạng được tạo ra bởi John Althouse tại FoxIO. Động thái xác định của nó là sắp xếp các bộ mã hóa và phần mở rộng trước khi băm, điều này khiến dấu vân tay ổn định ngay cả trước sự ngẫu nhiên hóa thứ tự phần mở rộng của Chrome. Nó cũng có thể đọc được bởi con người: dấu vân tay được trình bày trong ba phần theo định dạng a_b_c, vì vậy các nhà phân tích có thể so khớp trên bất kỳ phần nào thay vì một băm mờ đục duy nhất.

Lấy ví dụ dấu vân tay JA4=t13d1516h2_8daaf6152771_02713d6af862:

• Phần a — t13d1516h2 là siêu dữ liệu có thể đọc được. t là phương tiện truyền tải (t cho TLS qua TCP, q cho QUIC, d cho DTLS); 13 là phiên bản TLS (1.3); d có nghĩa là một miền SNI đang có (i sẽ có nghĩa là không có SNI hoặc một IP); 15 là số lượng cipher-suite và 16 là số lượng phần mở rộng, cả hai đều không bao gồm GREASE; và h2 là ký tự đầu tiên và cuối cùng của giá trị ALPN đầu tiên.
• Phần b — 8daaf6152771 là SHA-256 cắt ngắn 12 ký tự của các cipher suite, được chuyển đổi sang hex và sắp xếp.
• Phần c là SHA-256 cắt ngắn 12 ký tự của các phần mở rộng được sắp xếp theo giá trị hex, theo sau là các thuật toán ký hiệu. Các phần mở rộng SNI và ALPN được loại bỏ khỏi tính toán này, vì vậy cùng một khách hàng sẽ giữ nguyên phần c bất kể kết nối đến miền hay IP.

Sắp xếp là điều làm giảm tính ngẫu nhiên đã phá vỡ JA3: bạn có thể sắp xếp lại các phần mở rộng của Chrome theo bất kỳ cách nào, và danh sách đã sắp xếp — do đó JA4 — là giống hệt nhau.

Bộ JA4+ không chỉ là TLS

JA4 nhận diện khách hàng TLS, nhưng nó là một thành viên của một gia đình lớn hơn. Bộ nhận diện JA4+ bao gồm một vài lớp kết nối, bao gồm:

Dấu vân tay	Tên ngắn	Đặc điểm nhận dạng
JA4	JA4	Khách hàng TLS
JA4Server	JA4S	Phản hồi máy chủ TLS
JA4HTTP	JA4H	Khách hàng HTTP
JA4X509	JA4X	Chứng chỉ TLS X.509
JA4SSH	JA4SSH	Lưu lượng SSH
JA4TCP	JA4T	Khách hàng TCP
JA4Latency	JA4L	Độ trễ từ khách hàng đến máy chủ

Phương pháp JA4 TLS-client được phát hành theo giấy phép BSD 3-Clause; phần còn lại của các phương pháp JA4+ theo giấy phép FoxIO 1.1 và đang chờ cấp bằng sáng chế. Đối với một scraper, JA4 (TLS) và JA4H (HTTP) là hai yếu tố mà thường quyết định xem một yêu cầu được xử lý như một trình duyệt hay một bot.

Tại sao dấu vân tay TLS chặn scraper

Dấu vân tay TLS chặn một scraper vì yêu cầu chưa bao giờ trình bày dấu vân tay của trình duyệt ngay từ đầu. Một khách hàng HTTP như requests, httpx, curl hoặc một thư viện được sửa đổi lén lút thương lượng TLS với bộ cipher và tập hợp phần mở rộng của thư viện của nó — một cái mà không có Chrome hoặc Firefox thực sự nào tạo ra. Kết quả JA4 xuất hiện trên một giá trị không phải trình duyệt đã biết, và máy chủ có thể từ chối hoặc thách thức kết nối bất kể các tiêu đề có thuyết phục như thế nào.

Đây là lớp mà việc giả mạo user-agent và xoay vòng proxy không thể chạm tới. Bạn có thể gửi Mozilla/5.0 (… Chrome/126 …) từ một IP dân cư và vẫn bị đánh dấu, vì việc bắt tay TLS bên dưới được tạo ra bởi OpenSSL hoặc Go's crypto/tls, chứ không phải bởi Chrome. Khớp với JA4 của một trình duyệt bằng tay có nghĩa là sao chép đúng thứ tự cipher, tập hợp phần mở rộng và ALPN — và sau đó theo kịp khi trình duyệt thay đổi chúng.

Cách trình bày dấu vân tay TLS xác thực

Cách đáng tin cậy để trình bày JA4 của một trình duyệt là trở thành một trình duyệt thực sự. Trình duyệt thu thập không có rác là Chromium tự phát triển, vì vậy nó thương lượng TLS với bộ stack của Chrome. ClientHello của nó — và do đó JA3 và JA4 của nó — là của một Chrome chính hiệu, đây chính xác là điều mà một máy chủ nhận diện mong đợi từ một khách truy cập bình thường. Đối với việc thu thập dữ liệu cụ thể, nó mang đến:

• Một bộ stack TLS Chromium thực sự — các cipher suite, phần mở rộng và ALPN đến từ Chrome, vì vậy JA4 khớp với một trình duyệt thật thay vì một thư viện kịch bản.
• Một dấu vân tay nhất quán theo phiên qua các lớp TLS và trình duyệt, không có dấu hiệu navigator.webdriver nào để phủ nhận nó.
• Địa chỉ ra ngoài dân cư ở 195 quốc gia, vì vậy danh tiếng IP khớp với dấu vân tay trình duyệt thay vì để lộ địa chỉ trung tâm dữ liệu.

Lấy API key của bạn trên gói miễn phí tại app.scrapeless.com.

Lấy API key của bạn trên gói miễn phí: app.scrapeless.com

Kết luận: dấu vân tay phải thuộc về, không chỉ nhìn đúng

Dấu vân tay TLS đọc client từ quá trình bắt tay của nó, vì vậy câu trả lời bền vững duy nhất là một quá trình bắt tay thật sự thuộc về trình duyệt. JA3 đã băm trường ClientHello thô và bị hỏng khi Chrome ngẫu nhiên hóa thứ tự mở rộng; JA4 sắp xếp các bộ mã hóa và mở rộng và giữ sự ổn định, đó là lý do tại sao hiện nay nó là dấu vân tay mà các công cụ thu thập dữ liệu gặp phải. Một client HTTP đã được sửa đổi có thể giả mạo tiêu đề và thay đổi IP và vẫn thất bại ở cấp độ TLS. Chạy Chromium thực tế - với một ngăn xếp TLS của Chrome, một dấu vân tay nhất quán và lối thoát cư dân - tạo ra một JA4 mà khớp với một khách truy cập thông thường. Phần này tập trung vào cơ chế: để xem quy trình hoạt động của việc định tuyến một đống thu thập dữ liệu qua trình duyệt đó, hãy xem hướng dẫn để vượt qua kiểm tra dấu vân tay TLS; để xem một lớp chống phát hiện liên quan, hãy xem hướng dẫn thu thập dữ liệu sản xuất Scrapling, và so sánh các gói trên trang giá Scrapeless.

---

Sẵn sàng để trình bày một dấu vân tay TLS cấp trình duyệt?

Tham gia cộng đồng của chúng tôi để nhận một gói miễn phí và kết nối với các nhà phát triển làm việc xung quanh việc phát hiện dựa trên dấu vân tay: Discord · Telegram.

Đăng ký tại app.scrapeless.com để có thời gian chạy Trình duyệt Thu thập dữ liệu miễn phí và để Chromium thực tế trình bày dấu vân tay TLS mà các mục tiêu của bạn mong đợi.

---

Câu hỏi thường gặp

H: Sự khác biệt giữa JA3 và JA4 là gì?
JA3 là một băm MD5 của các trường ClientHello theo thứ tự ban đầu của chúng; JA4 sắp xếp các bộ mã hóa và mở rộng trước khi băm và thêm một tiền tố siêu dữ liệu dễ đọc. Sắp xếp giúp JA4 ổn định trước việc ngẫu nhiên hóa thứ tự mở rộng TLS đã làm cho các băm JA3 thay đổi từ kết nối này sang kết nối khác.

H: Tôi có thể thay đổi dấu vân tay TLS của mình bằng cách thay đổi tác nhân người dùng không?
Không. Tác nhân người dùng là một tiêu đề HTTP được gửi sau quá trình bắt tay TLS; dấu vân tay TLS được suy ra từ chính quá trình bắt tay. Chúng là các lớp độc lập, đó là lý do tại sao một tác nhân người dùng giả mạo không làm gì đối với JA3 hoặc JA4 của bạn.

H: Tại sao công cụ thu thập dữ liệu của tôi bị chặn ngay cả với các proxy cư dân?
Một IP cư dân cố định lớp mạng, nhưng nếu client HTTP của bạn thương lượng TLS với một bộ mã hóa và bộ mở rộng không phải là của trình duyệt, JA4 của nó vẫn xác định nó là một kịch bản. Dấu vân tay và IP phải đồng ý.

H: Trình duyệt Thu thập dữ liệu Scrapeless có thay đổi JA4 của tôi thành Chrome giả không?
Nó không giả mạo bất kỳ điều gì — nó là Chromium thực, vì vậy nó thương lượng TLS với ngăn xếp thực tế của Chrome. JA3/JA4 mà nó trình bày là của một Chrome chính hiệu vì quá trình bắt tay thật sự đến từ Chrome.

H: Dấu vân tay TLS có giống với dấu vân tay trình duyệt không?
Không. Dấu vân tay TLS đọc quá trình bắt tay vận tải (các bộ mã hóa, mở rộng, ALPN); dấu vân tay trình duyệt đọc các thuộc tính bên trong trang (canvas, phông chữ, các giá trị navigator). Một phiên làm việc thuyết phục cần cả hai để trông giống như một trình duyệt thực.