لعقود طويلة، تعامل مهندسو الشبكات مع ضغط البيانات والتشفير الرقمي كتقنيتين متكاملتين. فعلى خطوط النقل بعيدة المدى وحزم التبادل الدولي، يمثل استهلاك النطاق الترددي تكلفة تشغيلية مستمرة. وبناءً على ذلك، بدا تقليص حجم الحزم قبل إدخالها إلى خوارزميات التشفير المتناظر فكرة منطقية تحقق فائدة مزدوجة: تقليل استهلاك البيانات وتسريع نقل الحزم عبر الكابلات. قامت بروتوكولات تقليدية مثل OpenVPN بدمج خوارزميات الضغط—وعلى رأسها LZO وDEFLATE—بشكل مباشر داخل مسار معالجة النقل.

استندت هذه الهندسة إلى افتراض نظري بديهي: خوارزميات التشفير المتناظر الحديثة مثل AES-256-GCM وChaCha20-Poly1305 تحول البيانات الصريحة إلى تسلسلات ثنائية عشوائية لا يمكن تمييزها عن الضوضاء. وكان الاعتقاد السائد أن أي طرف يتنصت على الحزم المشفرة عبر الشبكة لن يتمكن من استنتاج أي تفاصيل حول النص الصريح الأصلي.

ولكن في عام 2018، كشف الباحث الأمني أحمد نفيس عن هجوم VORACLE (المسجل برقم CVE-2018-3972 والمقدم في مؤتمري Black Hat USA وDEF CON 26). أثبت الهجوم أن ضغط البيانات قبل تشفيرها ينشئ قناة جانبية (side-channel) خطيرة قائمة على طول الحزم المشفرة. من خلال مراقبة التغيرات الطفيفة في حجم الحزم أثناء مرورها عبر الشبكة، يستطيع المهاجم استعادة البيانات السرية بايت تلو الآخر—بما في ذلك ملفات تعريف الارتباط ورموز مصادقة HTTP—دون الحاجة إلى كسر خوارزميات التشفير نفسها.

+-------------------------------------------------------------------------+
|                  آلية القناة الجانبية لضغط البيانات VORACLE             |
+-------------------------------------------------------------------------+
|                                                                         |
|  يقوم المهاجم بحقن أحرف تخمينية ("Cookie: auth=a...")                    |
|  ضمن نفس تيار البيانات مع رمز الضحية السري ("Cookie: auth=s3cr3t...")    |
|                                                                         |
|            تيار النص الصريح (بيانات الضحية السرية + تخمينات المهاجم)    |
|                                    │                                    |
|                                    ▼                                    |
|                       [ محرك الضغط LZO / DEFLATE ]                      |
|                                    │                                    |
|    - تخمين خاطئ -> لا يوجد تطابق ثنائي -> يظل حجم الحزمة كبيراً         |
|    - تخمين صحيح -> يعمل مؤشر LZ77       -> يتقلص حجم الحزمة فوراً!      |
|                                    │                                    |
|                                    ▼                                    |
|                       [ التشفير المتناظر AES / ChaCha ]                 |
|                                    │                                    |
|                                    ▼                                    |
|    حزمة الشبكة المشفرة (حجم النص المشفر يعكس نسبة الانكماش)             |
|                                    │                                    |
|    مراقبة التغير في طول الحزمة -> استخراج الحرف السري بدقة!             |
+-------------------------------------------------------------------------+

نظرية المعلومات والأساس الرياضي للتسريب

لفهم كيفية نجاح هجوم VORACLE، يجب تحليل الطبيعة الرياضية لخوارزميات الضغط غير المنقوص (lossless compression). تعتمد الخوارزميات القياسية مثل DEFLATE (المعيار RFC 1951) وLZO على ركيزتين: استبدال القاموس ذي النافذة المنزلقة LZ77 وترميز هوفمان.

في خوارزمية LZ77، يقوم المشفر بفحص تيار البايتات الواردة بحثاً عن سلاسل متكررة. عندما تظهر سلسلة بايتات مرة ثانية ضمن نافذة التاريخ (التي تتراوح عادة بين 32 و64 كيلوبايت)، يستبدل المشفر التكرار بمؤشر مرجعي مدمج يحتوي على قيمتين:

  1. المسافة (Distance): كم بايت للخلف ظهرت السلسلة الأصلية.
  2. الطول (Length): عدد البايتات المتتالية المتطابقة.

إذا احتوت الحزمة على نسختين من سلسلة أحرف بطول 16 بايت، يتم استبدال النسخة الثانية بمؤشر لا يتعدى 2 إلى 3 بايت. وبالتالي ينخفض الحجم الإجمالي للبيانات المضغوطة بما يتناسب طردياً مع نسبة التكرار في النص الصريح.

وهنا تبرز المشكلة الأمنية. توفر خوارزميات التشفير المتناظر سرية المحتوى، مما يمنع الخصم من معرفة قيم البتات المشفرة. ومع ذلك، فإن التشفير القياسي لا يوفر سرية طول البيانات.

خوارزميات التشفير الانسيابي (مثل ChaCha20 أو نمط AES-CTR) تولد تيار مفاتيح وتقوم بإجراء عملية XOR متطابقة بنسبة 1 إلى 1 مع النص الصريح. أي أن مدخلاً بطول 412 بايت ينتج عنه نص مشفر بطول 412 بايت بالضبط (بالإضافة إلى وسم التحقق). حتى التشفير الكتلي (AES-CBC) مع التوسيع لمضاعفات 16 بايت، غالباً ما يتجاوز فيه انخفاض حجم الضغط حدود الكتل، مسرباً معلومات الحجم بخطوات قدرها 16 بايت.

عندما يسبق الضغط عملية التشفير، يصبح طول الحزمة المشفرة انعكاساً رياضياً مباشراً لمستوى التكرار الداخلي في النص الصريح.

مراحل تنفيذ هجوم VORACLE عملياً

استهدف هجوم VORACLE بشكل مباشر اتصالات OpenVPN التي تفعل خيارات الضغط (comp-lzo yes أو تعليمة compress). يعتمد الهجوم على إطار الهجوم التكيفي بالنص الصريح المختار (adaptive chosen-plaintext attack):

1. التموضع في مسار الاتصال

يتمركز المهاجم في مسار حركة البيانات بين الضحية والبوابة؛ مثل نقطة اتصال Wi-Fi عامة تم العبث بها، أو موجه شبكة محلي غير مؤمن، أو من خلال مراقبة اتصالات مزود خدمة الإنترنت. نظراً لأن البيانات موجهة داخل نفق VPN المشفر، لا يستطيع المهاجم قراءة الحزم بشكل مباشر.

2. حقن بيانات النص الصريح

يقوم المهاجم بدفع الضحية لفتح صفحة ويب خاضعة لسيطرته، أو يحقن كوداً برمجياً عبر ترافيك HTTP غير مشفر يمر بالجهاز. يرسل هذا الكود طلبات HTTP متكررة عابرة للمصادر (cross-origin) نحو خدمة مستهدفة (كبوابة شركة أو واجهة بريد إلكتروني).

عندما يرسل متصفح الضحية هذه الطلبات، يرفق تلقائياً ملفات تعريف الارتباط السرية الخاصة بالضحية في ترويسات HTTP. وفي نفس الوقت، يتحكم كود المهاجم في معلمات الرابط (URL parameters)، حاقناً أحرفاً تخمينية في نفس تيار الطلب الصادر.

3. استجابة أوراكل الضغط

ينقل نظام تشغيل الضحية حزمة HTTP المجمعة إلى محول الشبكة الافتراضي الخاص بـ VPN. يقوم برنامج النفق بضغط كامل الحمولة قبل تمريرها لوحدة التشفير:

هيكل النص الصريح داخل الحزمة:
[GET /api/user?probe=GUESS_CHAR HTTP/1.1\r\n]  <-- يتحكم به المهاجم
[Cookie: auth_token=7a8b9c0d1e2f3a4b\r\n]     <-- الرمز السري للضحية

إذا طابق الحرف التخميني الذي أرسله المهاجم الحرف الأول من رمز الجلسة السري، تكتشف خوارزمية LZ77 التكرار فوراً. يستبدل المشفر الحرف بمؤشر مرجعي قصير، مما يؤدي إلى انكماش حجم الحزمة المضغوطة بعدة بايتات.

أما إذا كان التخمين غير مطابق، فلا يظهر أي تكرار، ويحافظ تيار البيانات على حجمه الأكبر.

4. استخراج الحروف بالتتابع

يراقب المهاجم طول حزم UDP أو TCP المشفرة الخارجة من جهاز الضحية باتجاه خادم VPN. وبمجرد تسجيل انخفاض في حجم الحزمة عند إرسال حرف معين، يتأكد المهاجم من صحة ذلك الحرف.

ومن خلال تحريك نافذة الاختبار خطوة بخطوة، يستطيع المهاجم استعادة ملف تعريف الارتباط بالكامل أو رمز التحقق في غضون بضعة آلاف من الطلبات الآلية—وغالباً في أقل من دقيقتين.

المسار التاريخي: من CRIME وBREACH إلى VORACLE

لم يكن VORACLE حدثاً منفرداً، بل مثل امتداداً منطقياً لسلسلة استغلال القنوات الجانبية لضغط البيانات عبر طبقات الشبكة المختلفة:

الثغرة سنة الإعلان الطبقة المستهدفة البروتوكول الحل الأمني الأساسي
CRIME (RFC 7540 §10.6) 2012 طبقة النقل / الجلسة الضغط في طبقة TLS تعطيل ضغط TLS بالكامل في المتصفحات وخوادم الويب
TIME 2013 طبقة التطبيقات ضغط استجابات HTTP إضافة حشو عشوائي للردود وتحديد وتيرة الطلبات
BREACH 2013 طبقة التطبيقات محتوى HTTP (gzip/deflate) إخفاء الرموز الديناميكية وفصل مدخلات المستخدم
VORACLE (CVE-2018-3972) 2018 طبقة الشبكة / النفق نفق VPN (OpenVPN LZO) إلغاء ميزة الضغط تماماً من إعدادات أنفاق VPN

عقب نشر ثغرة CRIME بواسطة جوليوس ريتسو وتاي دونغ في عام 2012، اتخذ مجتمع هندسة الإنترنت قراراً حاسماً: حظر معيار RFC 7540 (HTTP/2) استخدام ضغط TLS بشكل قاطع، لأن دمج بيانات موثوقة ومدخلات مستخدم في سياق ضغط موحد يشكل ثغرة هيكلية.

ساد في أوساط صناعة الشبكات اعتقاد خاطئ بأن العمل على طبقة الشبكة (حزم IP) يعزل الأنفاق عن ثغرات طبقة التطبيقات. وقد أثبت هجوم VORACLE خطأ هذا التصور، مؤكداً أن نفس المخاطر تتكرر عند ضغط البيانات داخل النفق.

أسباب امتناع بروتوكول WireGuard عن دعم الضغط

عندما صمم جيسون دوننفيلد بروتوكول WireGuard، كان قرار استبعاد ضغط البيانات خياراً معمارياً ثابتاً غير قابل للنقاش.

تراكمت في بروتوكولات VPN القديمة على مر السنين ميزات معقدة وخوارزميات متباينة وخيارات ضغط متعددة. اتبع WireGuard فلسفة مقابلة ترتكز على: البساطة التشفيرية وتقليص مساحة الهجوم.

يرجع استبعاد الضغط في WireGuard إلى ثلاثة أسباب تقنية:

  1. إلغاء تسريب البيانات عبر طول الحزم: يؤدي غياب الضغط إلى بقاء حجم النص الصريح مطابقاً لإطار الشبكة، مما يحرم المتنصت من استخدام مؤشرات انكماش البيانات لاستخراج النصوص.
  2. أمان الذاكرة والتشغيل الحتمي: تعتمد مكتبات الضغط مثل zlib وLZO على آلات حالة معقدة وحجز ديناميكي للذاكرة، وسجلت تاريخياً ثغرات فيض الذاكرة. يعمل WireGuard داخل مساحة نواة النظام بمساحة ذاكرة ثابتة تماماً دون تخصيص ديناميكي.
  3. تفادي تباين زمن المعالجة: تستهلك خوارزميات الضغط موارد المعالجة بناءً على عشوائية البيانات. فالبيانات المشفرة مسبقاً (كمقاطع فيديو HTTPS والصور المضغوطة) لا تقبل الانكماش، مما يهدر دورات المعالج في محاولات ضغط عقيمة تؤدي لارتفاع زمن الاستجابة وتقلب الأداء تحت الأحمال العالية.

بنية RiceGuard: صفر ضغط وحشو قياسي منتظم

تعتبر منظومات الأمان المعاصرة ضغط حزم VPN خطراً تقنياً غير مبرر. وفي منصة VPNRice، يطبق محرك RiceGuard حظراً تاماً على ضغط البيانات في كافة الخوادم وتطبيقات المستخدم.

+-----------------------------------------------------------------------+
|                    مسار التغليف الآمن في RICEGUARD                    |
+-----------------------------------------------------------------------+
|  [ حزمة IP الأصلية للمستخدم ]                                         |
|         │                                                             |
|         ▼                                                             |
|  [ تعطيل تام للضغط ]         -> إغلاق القناة الجانبية لخوارزمية LZ77   |
|         │                                                             |
|         ▼                                                             |
|  [ حشو قياسي منتظم ]         -> محاذاة الأحجام لمضاعفات محددة ثابته    |
|         │                                                             |
|         ▼                                                             |
|  [ تشفير ChaCha20-Poly1305 ] -> تشفير موثق بزمن معالجة ثابت           |
|         │                                                             |
|         ▼                                                             |
|  [ حزمة UDP الخارجية ]       -> سلوك مروري موحد وثابت على الخط         |
+-----------------------------------------------------------------------+

يعتمد RiceGuard مجموعة إجراءات هندسية دقيقة:

  • المنع الصارم للضغط المسبق: استبعاد كافة مكونات الضغط من مسار الشبكة، حيث تدخل حزم IP إلى وحدة التشفير ببيئتها الأصلية دون معالجة حجمية.
  • الحشو القياسي (Padding): استخدام حقول الحشو المدمجة في إطار الحزم لمساواة الحزم القصيرة وطلبات التحكم عند أطوال معيارية، مما يعطل محاولات تصنيف الأنماط المرورية.
  • الحفاظ على السرعة القصوى: التخلص من أعباء الضغط وفك الضغط يسمح للنفق بنقل البيانات بسرعة الأسلاك الفعلية عبر اتصالات الألياف الضوئية عالية السعة، وتجنب تكدس طوابير الانتظار في نواة النظام.

يمكن للمستخدمين الاطلاع على تطبيقات النظام الآمنة للأجهزة المكتبية والهواتف عبر صفحة تنزيل VPN.

فحص وتأمين بيئات VPN الحالية

إذا كنت تدير خوادم VPN تقليدية أو ذاتية الاستضافة، يوصى بالتدقيق الفوري في ملفات الإعداد لتعطيل خصائص الضغط غير الآمنة.

مراجعة إعدادات OpenVPN

افحص ملفات إعداد الخادم (server.conf) والعميل (client.ovpn) للتأكد من خلوها من التعليمات التالية:

# تعليمات غير آمنة - يجب حذفها أو تعطيلها فوراً:
comp-lzo yes
comp-lzo adaptive
compress lzo
compress deflate

لتأمين نفق OpenVPN ضد مخاطر VORACLE، قم بتعديل التوجيهات إلى الإعدادات الآمنة:

# الإعداد الآمن الموصى به:
# للإصدار OpenVPN 2.4+:
compress migrate
comp-lzo no

# للإصدار OpenVPN 2.5 فما فوق:
# تعطيل الضغط بصورة نهائية:
compress stub-v2

يضمن استخدام الأمر comp-lzo no أو حذف تعليمات الضغط عدم خضوع الحزم لأي تعديل في الحجم قبل وصولها لوحدة التشفير.

قائمة التحقق لمديري النظم

  1. الترقية إلى البروتوكولات الحديثة: الانتقال بالبنية التحتية إلى WireGuard أو RiceGuard التي تخلو هيكلياً من برمجيات الضغط.
  2. فرض معايير HTTPS وHSTS: التأكد من اعتماد تطبيقات الويب الداخلية على بروتوكول TLS 1.3 مع سياسات HSTS الصارمة لمنع محاولات حقن النصوص الصريحة.
  3. فحص الأجهزة الوسيطة: مراجعة أجهزة تحسين شبكات WAN وموجهات SD-WAN للتأكد من عدم قيامها بضغط حزم الترافيك المشفرة دون علم الإدارة.

أثبت تاريخ التشفير الرقمي أن محاولات تحسين الأداء الطفيفة قد تفتح ثغرات أمنية واسعة. إن محاولة توفير بضعة بايتات من خلال ضغط الحزم تؤدي عملياً إلى انهيار حاجز السرية الذي أنشئ النفق من أجله. ويعد الاستغناء التام عن ضغط البيانات في أنفاق VPN الركيزة الأساسية لحماية خصوصية وسرية الاتصالات الرقمية.