قبل عام، كانت الخطة واضحة: تأخذ عميلًا يستطيع تزوير مصافحة TLS، وتختار ملفًا شخصيًا يناسب Chrome الجديد، وتحصل على JA4 مطابق - ويمرر مضاد الروبوت. في عام 2026، بدأ هذا الوصفة تفشل بسبب سبب ليس له علاقة بـ "تجاوز الحماية" على الإطلاق. انتقلت المتصفحات بشكل جماعي إلى تبادل المفاتيح بعد الكمومية، بينما لم تفعل معظم حزم التصفح ذلك. والآن، فإن عدم وجود مشاركة مفتاح بعد الكمومية هو في حد ذاته علامة على الأتمتة.
دعونا نفصل حسب المعايير: ما الذي تغير بالضبط في المصافحة، أي الحزم انتقلت، وأيها لم تنتقل، ولماذا لم يعد وجود تجزئة JA4 المطابقة شرطًا كافيًا.
ما الذي حدث: أصبح تبادل المفاتيح بعد الكمومية هو القاعدة، وليس الغرابة
تبادل المفاتيح الهجين بعد الكمومية هو مجموعة من المنحنى الإهليلجي الكلاسيكي X25519 وآلية الشبكة ML-KEM (المعيار NIST FIPS 203). تظل الجلسة محمية إذا كان أحد المكونين على الأقل قويًا. المعنى هو الحماية من سيناريو "اعترض الآن، وفكك لاحقًا"، عندما يتم كتابة حركة المرور في الأرشيف على أمل استخدام كمبيوتر كمومي في المستقبل.
التسلسل الزمني للتطبيق في العملاء:
- Chrome 124 (أبريل 2024) - تم تضمين تبادل المفاتيح الهجين بعد الكمومية بشكل افتراضي؛ في تصحيحات curl-impersonate، تم توثيقه كـ "المنحنيات X25519Kyber768/X25519MLKEM، التي تم تقديمها في Chrome 124 و130".
- Firefox 132 (نوفمبر 2024) - تم تضمين الدعم.
- Safari على iOS وmacOS - وصل تبادل المفاتيح بعد الكمومية في أكتوبر 2025.
- OpenSSL 3.5.0 (أبريل 2025) - تم تضمين المجموعات الهجينة X25519MLKEM768 وSecP256r1MLKEM768 وSecP384r1MLKEM1024 في القائمة الافتراضية لمجموعات TLS.
- Go 1.24 (فبراير 2025) - تم تضمين X25519MLKEM768 في crypto/tls بشكل افتراضي، إذا لم يتم تحديد Config.CurvePreferences بشكل صريح.
من جانب البنية التحتية، الصورة أكثر وضوحًا. في أبريل 2026، أظهر Cloudflare Radar حوالي 67% من حركة HTTPS البشرية مع تشفير بعد الكمومية - مقارنة بـ 32% في يناير 2025. جعلت Akamai تبادل المفاتيح بعد الكمومية هو الافتراضي لجميع اتصالات العملاء في 31 يناير 2026، واكتملت التوزيعات عبر الشبكة في مارس. وفقًا للقياسات الصناعية، حوالي 57.4% من جميع المعاملات عبر المتصفح أصبحت جاهزة بالفعل بعد الكمومية، حيث تبلغ نسبة Chrome القادرة على PQ حوالي 93%.
لاحظ عدم التوازن: الدعم من جانب خوادم الأصل ينمو ببطء أكبر (في Cloudflare - حوالي 9%). بمعنى أن كونك بعد كمومي اليوم هو في المقام الأول سمة للعميل. بالضبط ما يهم مضاد الروبوت.
المعيار 1: حجم مشاركة المفتاح وبنية ClientHello
مشاركة المفتاح بعد الكمومية ليست "علامة أخرى في التمديد". إنها كبيرة جسديًا: حوالي 1124 بايت مقابل 36 بايت للـ X25519 الكلاسيكي. العواقب واضحة للعيان على مستوى الحزم.
يخرج ClientHello بمشاركة المفتاح بعد الكمومية عن 1400 بايت ويتوقف عن التناسب في حزمة TCP واحدة. يتم تقسيمه إلى حزمتين أو أكثر. ثم يبدأ الجزء الأكثر إثارة للاهتمام للكشف: نمط التجزئة يختلف بين التنفيذات المختلفة. كيف يقوم المكدس بقطع ClientHello الكبير، وفي أي ترتيب يرسل الشرائح، مع أي توقيتات - هذا سلوك يمكن ملاحظته، والذي لا يتم استنتاجه من تجزئة JA4 والذي لا يعيد إنتاجه تقريبًا أي من مؤلفي أدوات التصفح بشكل واعٍ.
الاستنتاج العملي: أصبح لدى مضاد الروبوت طبقة تعمل أسفل بصمة الإصبع المعتادة. يمكنك جمع قائمة مثالية من التشفيرات والامتدادات، ولكن يمكنك أن تكشف نفسك من خلال كيفية وضع مكدسك للبايتات في المقبس.
المعيار 2: التوافق مع إصدار المتصفح المعلن
الفخ الرئيسي في عام 2026 هو عدم التزامن بين ما تمثله وما يفعله مكدس TLS الخاص بك فعليًا.
تحافظ منصات مضاد الروبوت على قواعد بيانات ClientHello النموذجية. الطلب الذي يعلن Chrome 131 في User-Agent وJA4، ولكنه يأتي بدون مشاركة مفتاح بعد كمومية، لا يتطابق مع أي Chrome 131 معروف صالح. هذه ليست "مريبة" - إنها تركيبة منطقية مستحيلة. لا يمكن أن يرسل Chrome الحقيقي من هذا الإصدار مشاركة مفتاح كلاسيكية مع الإعدادات الافتراضية.
مدى جودة هذا الفصل بواسطة التعلم الآلي - تم حسابه أيضًا. يظهر مصنف CatBoost على ميزات JA4 في الدراسات AUC 0.998 ودقة 0.9863؛ بشكل منفصل، تختلف حركة المرور بعد الكمومية عن الكلاسيكية بدقة حوالي 98%. هذه ليست "قواعد مع تحذيرات كاذبة"، بل هي سمة تقريبًا حتمية.
المعيار 3: جاهزية الحزم المحددة
هنا تمر الخط الفاصل الحقيقي. دعونا نقسمها إلى مجموعات.
ترسل PQ مشاركة المفتاح بشكل افتراضي
- Chrome 124+، Firefox 132+، Safari (iOS/macOS من أكتوبر 2025) - معيار يتم مقارنتك به.
- Go 1.24+ - يتضمن crypto/tls X25519MLKEM768 بنفسه، إذا لم تقم بإعادة تعريف CurvePreferences. نقطة مهمة: هناك بعد كمومي، ولكن JA4 في عميل Go العاري لا يزال ليس متصفحًا. تحصل على بصمة "متوافقة مع PQ، ولكن ليست مشابهة لـ Chrome".
- Node.js 24 - يحمل OpenSSL 3.5 الخاص به، لذا فإن القائمة الافتراضية للمجموعات تتضمن بالفعل الهجين. بالإضافة إلى ذلك، ظهرت ML-KEM في node:crypto عبر 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 نفسه. في الممارسة العملية، هذا يعني: الزاحف Python النموذجي في عام 2026 يرسل مشاركة مفتاح كلاسيكية ويبدو شاذًا على Akamai.
يمكنهم، ولكن فقط إذا تم اختيار الملف الشخصي الصحيح
- curl_cffi / curl-impersonate - دعم المنحنيات بعد الكمومية موجود في الفرع وتم الإعلان عنه بوضوح. لكن قائمة الأهداف تمتد من chrome99 إلى chrome146 (في الفرع - حتى chrome150)، وتعيد الملفات الشخصية القديمة إنتاج المصافحة من زمنها، أي بدون PQ. النسخ واللصق
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 ذلك بشكل حتمي، بينما كان parrot في uTLS يقلب عملة بين AES وChaCha20، وهو ما لا يمكن أن يحدث في Chrome الحقيقي). يجب التحديث إلى الأقل إلى 1.8.2.
المشترك: الأدوات في الغالب لحقت بالركب. المشكلة ليست فيها، بل في أن التكوينات تتقادم أسرع من المتصفحات. الملف الشخصي الذي كان مثاليًا في عام 2024، يعمل اليوم كعلامة.
كيف تتحقق من مكدسك في خمس دقائق
- أرسل طلبًا باستخدام عميلك القتالي إلى
https://tls.peet.ws/api/allأوja4db.com- سيعيدون JA3/JA4 الحية وتحليل ClientHello في JSON. - ابحث في التحليل عن قائمة supported_groups وkey_share. ابحث عن X25519MLKEM768 (أو X25519Kyber768 في الملفات الشخصية القديمة). إذا كان هناك فقط x25519/secp256r1 - فلا يوجد تبادل بعد كمومي.
- قارن ذلك مع إصدار المتصفح الذي تمثله. إذا كنت تعلن Chrome 131+ ولا ترى مجموعات PQ - فإن التركيبة غير صالحة، قم بإصلاح الملف الشخصي.
- انظر إلى حجم ClientHello. أقل من ~1400 بايت مع Chrome الجديد المعلن - نفس العلامة، ولكن من الجانب الآخر.
- قم بتشغيل الاختبار من كل عقدة خروج، وليس فقط من الجهاز العامل: قد تقوم فحص SSL على البوابة المؤسسية أو لدى المزود بإعادة كتابة المصافحة نيابة عنك.
ما الذي تفعله البروكسيات هنا
من المهم عدم خلط طبقتين مستقلتين. مشاركة المفتاح بعد الكمومية تتعلق بـ المصافحة، وسمعة العنوان تتعلق بـ الشبكة. يعتبر مضاد الروبوت كل منهما بشكل منفصل ويجمعهما.
من هنا، هناك نتيجتان عمليتان. الأولى: عنوان IP الساكن المثالي لن ينقذ الطلب الذي على مستوى TLS يدعي أنه Chrome 131 بدون مجموعة PQ - ستخسر حتى قبل أن ينظر الخادم إلى العنوان. الثانية، العكس: المصافحة بعد الكمومية المجمعة بشكل صحيح لن تساعد إذا كانت مئات من جلساتك تأتي من شبكة فرعية لمركز بيانات ذات سمعة سيئة. يجب إصلاح كلا الطبقتين، ويتم إصلاحهما بأدوات مختلفة.
التوزيع العملي للمهام: لأغراض خلف Akamai وCloudflare، حيث يتم حساب كل من المصافحة والشبكة، من المنطقي استخدام بروكسيات سكنية ورفع الهدف impersonate إلى Chrome الجديد في نفس الوقت. بالنسبة للتطبيقات المحمولة والمنصات حيث وزن سمعة IP أعلى من متطلبات TLS، غالبًا ما تفوز بروكسيات محمولة. أما بالنسبة لواجهات برمجة التطبيقات الخاصة، والتصديرات الشريكة، والمراقبة الداخلية، حيث لا يوجد مضاد روبوت، فلا يوجد معنى لدفع المزيد مقابل السكن - يكفي مراكز البيانات.
إذا كنت تتعامل مع بصمة الإصبع من الصفر، ابدأ بالأساس: كيف يعمل JA4 وما يتضمنه. وعندما يتعلق الأمر بمتصفح كامل، تم جمع مقارنة بين تجميعات التخفي ونقاط ضعفها بشكل منفصل - nodriver وCamoufox وPatchright في قياسات 2026.
الاستنتاج
لم يتم تصميم تبادل المفاتيح بعد الكمومية كآلية لمضاد الروبوت. لقد أصبح كذلك بشكل غير مباشر: انتقلت المتصفحات إليه بسرعة وبشكل جماعي، وجعلت البنية التحتية (Akamai - اعتبارًا من 31 يناير 2026) منه الافتراضي، بينما انقسمت حزم التصفح إلى ثلاث مجموعات - تلك التي انتقلت بالفعل، وتلك التي تعتمد على OpenSSL النظامي، وتلك التي يمكنها فقط مع ملف شخصي جديد.
تتحول التحقق إلى سؤال واحد: هل يرسل عميلك X25519MLKEM768 وهل يتوافق ذلك مع إصدار المتصفح الذي تمثله. إذا لم يكن الأمر كذلك - فإن JA4 المطابق لن ينقذك، لأن ما يتم مقارنته ليس التجزئة، بل الشكل الكامل للمصافحة: حجم مشاركة المفتاح، عدد حزم TCP وترتيب إرسالها. الخبر الجيد هو أن هذا يمكن إصلاحه في معظم الحالات من خلال تحديث الملف الشخصي وإصدار المكتبة، وليس بإعادة كتابة الزاحف.