อธิบายเรื่อง TLS Fingerprinting และแฮช JA4
ทำไมข้อความ TLS Client Hello จึงเป็นขุมทรัพย์สำหรับการระบุอุปกรณ์ และแฮช JA4 ให้ลายนิ้วมือที่เสถียรซึ่งอยู่รอดผ่านการอัปเดตเบราว์เซอร์ได้อย่างไร
ทุกการเชื่อมต่อ HTTPS เริ่มต้นด้วย TLS handshake และทุก TLS handshake เริ่มต้นด้วยข้อความ Client Hello ข้อความนี้บรรจุข้อมูลมากมายเกี่ยวกับไคลเอนต์ที่กำลังเชื่อมต่อ ทั้ง cipher suite, extension, curve ที่รองรับ, และ signature algorithm ซึ่งแตกต่างกันอย่างมากในแต่ละเบราว์เซอร์ เวอร์ชัน และระบบปฏิบัติการ TLS fingerprinting จับข้อมูลนี้และใช้เป็นสัญญาณระบุตัวตน
ใน Client Hello มีอะไรบ้าง?
เมื่อเบราว์เซอร์เชื่อมต่อไปยังเซิร์ฟเวอร์ HTTPS มันจะส่งข้อความ Client Hello ที่บรรจุ: เวอร์ชัน TLS ที่รองรับ, รายการ cipher suite ที่ยินดีใช้, TLS extension ที่รวมไว้ (เช่น SNI, ALPN, และ key share), elliptic curve ที่รองรับ, signature algorithm ที่ยอมรับ, และวิธี compression ที่เสนอ
เบราว์เซอร์แต่ละตระกูลมีลายนิ้วมือที่โดดเด่นเป็นเอกลักษณ์ Chrome, Firefox, และ Safari ต่างส่งลำดับ cipher suite ที่ต่างกัน ชุด extension ที่ต่างกัน และความชอบ curve ที่ต่างกัน แม้ภายในเบราว์เซอร์ตระกูลเดียวกัน เวอร์ชันที่ต่างกันก็อาจส่งข้อความ Client Hello ที่ต่างกันเล็กน้อยเมื่อมีการเพิ่มหรือเลิกใช้ cipher suite
จาก JA3 สู่ JA4
JA3 เป็นแฮช TLS fingerprinting ดั้งเดิม ที่ Salesforce เปิดตัวในปี 2017 มันเชื่อม TLS version, cipher suite, extension, elliptic curve, และ EC point format เข้าเป็นสตริงแล้วคำนวณแฮช MD5 แม้จะเป็นการบุกเบิก แต่ JA3 ก็มีข้อจำกัด: มันสร้างแฮชก้อนเดียวที่ทึบแสงซึ่งวิเคราะห์ได้ยาก และการเปลี่ยนแปลงเล็กน้อยในฟิลด์ใดก็ตามจะให้แฮชที่ต่างกันโดยสิ้นเชิง
JA4 ที่ FoxIO เปิดตัวในปี 2023 ปรับปรุงจาก JA3 ในหลายด้าน มันสร้างลายนิ้วมือที่มีโครงสร้างประกอบด้วยสามส่วน: ส่วนนำหน้าที่อ่านได้ (เช่น "t13d1715h2" — TLS 1.3, 17 cipher suite, 15 extension, HTTP/2), แฮชแบบเรียงลำดับของ cipher suite, และแฮชแบบเรียงลำดับของ extension โครงสร้างนี้ทำให้ลายนิ้วมือ JA4 วิเคราะห์ได้ในพริบตาขณะที่ยังคงความแม่นยำที่จำเป็นสำหรับการระบุตัวตน
ทำไม TLS Fingerprint จึงสำคัญต่อ Device Intelligence
TLS fingerprint มีคุณค่าเพราะถูกเก็บก่อนที่ JavaScript ใด ๆ จะทำงาน บอตที่ปลอม user agent, ปลอมการเรนเดอร์ canvas, และแพตช์คุณสมบัติ navigator ของมัน ก็ยังส่งข้อความ Client Hello ของแท้จากไลบรารี TLS ที่มันใช้จริง หาก Client Hello บอกว่า "ไลบรารี crypto/tls ของ Go" แต่ user agent บอกว่า "Chrome 124" เราก็รู้ว่ามีบางอย่างถูกปลอมแปลง
การตรวจสอบข้ามนี้ทรงพลังอย่างยิ่งสำหรับการตรวจจับบอต เฟรมเวิร์กอัตโนมัติส่วนใหญ่ — Selenium, Puppeteer, Playwright — ใช้ TLS stack ดั้งเดิมของเบราว์เซอร์ ดังนั้น TLS fingerprint ของพวกมันจึงตรงกับเบราว์เซอร์ที่พวกมันควบคุม แต่ HTTP client ที่กำหนดเอง, สแครปเปอร์ที่ พัฒนาด้วย Go, และสคริปต์ Python ที่ใช้ไลบรารี requests ล้วนมี TLS fingerprint ที่โดดเด่น ซึ่งระบุได้ทันทีว่าเป็นไคลเอนต์ที่ไม่ใช่เบราว์เซอร์
ความเสถียรของ TLS Fingerprint
ข้อกังวลหนึ่งเกี่ยวกับ TLS fingerprinting คือความเสถียรข้ามการอัปเดตเบราว์เซอร์ เมื่อ Chrome เพิ่มหรือลบ cipher suite ตัว TLS fingerprint ก็เปลี่ยน ในทางปฏิบัติสิ่งนี้เกิดขึ้นน้อยกว่าที่คุณอาจคาดคิด รายการ cipher suite ของ Chrome ค่อนข้างเสถียร — การเปลี่ยนแปลงใหญ่เกิดขึ้นปีละครั้งหรือสองครั้ง ไม่ใช่ทุกเวอร์ชัน
รูปแบบที่มีโครงสร้างของ JA4 ช่วยตรงจุดนี้ ส่วนนำหน้าที่อ่านได้ยังคงเสถียรข้ามการเปลี่ยนเวอร์ชันย่อย (จำนวน cipher suite และ extension ไม่ค่อยเปลี่ยน) ดังนั้นแม้เมื่อแฮชรายละเอียดเปลี่ยน ส่วนนำหน้าก็ยังให้ความต่อเนื่อง ในระบบระบุตัวตนหลายชั้นของเรา ข้อมูล TLS fingerprint ถูกจัดไว้ใน Tier 2 — เสถียรพอที่จะมีส่วนช่วยในการระบุตัวตน แต่ผ่านการประมวลผลด้วยการจับคู่ข้ามเซสชันเพื่อรองรับการเลื่อนไหล (drift) ที่คาดว่าจะเกิดขึ้น
การเก็บข้อมูลฝั่งเซิร์ฟเวอร์
ต่างจากสัญญาณฝั่งไคลเอนต์ที่ต้องอาศัยการทำงานของ JavaScript ตัว TLS fingerprint ถูกเก็บฝั่งเซิร์ฟเวอร์ทั้งหมด edge server ของเราตรวจสอบ TLS handshake ดิบและดึง Client Hello ออกมาก่อนที่การเชื่อมต่อจะถูกสร้าง นั่นหมายความว่า TLS fingerprinting ใช้งานได้แม้เมื่อ JavaScript ถูกบล็อก เมื่อเบราว์เซอร์ติดตั้ง extension ด้านความเป็นส่วนตัว หรือเมื่อไคลเอนต์ไม่ใช่เบราว์เซอร์เลย
ธรรมชาติฝั่งเซิร์ฟเวอร์นี้ยังทำให้ TLS fingerprint ต้านทานการปลอมแปลงได้ด้วย แม้ในทางทฤษฎีจะเป็นไปได้ที่จะประดิษฐ์ TLS Client Hello ที่กำหนดเองเพื่อเลียนแบบเบราว์เซอร์เฉพาะ แต่การทำเช่นนั้นต้องอิมพลิเมนต์ TLS ในระดับต่ำ ซึ่งใช้ความพยายามมากกว่าการเปลี่ยนสตริง user agent มาก เครื่องมือปลอมแปลงส่วนใหญ่ไม่พยายามทำ
การผสานเข้ากับการระบุอุปกรณ์
ในเอนจินระบุอุปกรณ์ของเรา TLS fingerprint ทำหน้าที่เป็นทั้งสัญญาณและตัวตรวจสอบ ในฐานะสัญญาณ มันมีส่วนช่วยในลายนิ้วมืออุปกรณ์โดยรวมด้วยน้ำหนักการระบุตัวตนของมันเอง ในฐานะตัวตรวจสอบ มันให้การตรวจสอบข้ามกับตัวตนเบราว์เซอร์ที่อ้าง หากสัญญาณ JavaScript บอกว่า "Chrome บน macOS" แต่ TLS fingerprint บอกว่า "Firefox บน Linux" ความไม่สอดคล้องนี้จะกระตุ้นการตั้งค่าสถานะการแทรกแซง (tampering flag) ในการวิเคราะห์ Smart Signals ของเรา