الخلاصة

  • لم يبدأ IMAP COMPRESS إلا بعد OK موسوم: ضغط الخادم ما بعد CRLF الذي أنهى الرد، وبدأ العميل بضغط أول أمر لاحق.
  • الذاكرة التي اختصرت الأوامر والرؤوس والنص جعلت كل بايت لاحق يعتمد على حالة خفية. أوضحت الإرشادات الأمنية اللاحقة أن الطول المشفر قد يحمل دلالة، من دون أن تثبت هجوما خاصا على IMAP COMPRESS.

انتهى الرد بقراءة وواصل التدفق بقراءة أخرى

كان IMAP ينظم الحوار مسبقا بأوامر موسومة وبيانات غير موسومة ونتيجة نهائية تعيد وسم العميل. لم يضف RFC 4978 نوعا جديدا من الردود. أعلن الخادم COMPRESS=DEFLATE، وطلب العميل COMPRESS DEFLATE، وحملت النتائج المألوفة OK أو NO أو BAD القرار.

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

وهكذا امتلك موضع بايت واحد سلطة التحول. لو سبق العميل الحد فسيسلم نصا واضحا إلى مفكك الضغط. ولو تأخر الخادم ردا واحدا فسيقرأ العميل بتات DEFLATE كأنها نحو IMAP. قد يوصل TCP كل شيء صحيحا ومرتبا، ومع ذلك تنهار الجلسة لأن الطرفين اختلفا في معنى البايتات.

القدرة منحت إذنا لا وعدا بالكفاءة

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

حافظت قواعد الرفض على هذا المعنى الضيق. إذا كان الأسلوب نفسه نشطا في طبقة أخرى أمكن للخادم أن يجيب NO مع COMPRESSIONACTIVE. وكانت محاولة تشغيل الامتداد مرتين غير صالحة. وجود سطحين للتفاوض لم يمنح حق تكديس حالتين متماثلتين.

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

ترتيب الطبقات لم يتبع ترتيب الطلبات

كان ممكنا أن تكتسب الجلسة طبقة أمان SASL أو TLS أيضا. ثبت RFC 4978 ترتيب الإرسال: الضغط أولا، ثم توقيع SASL أو تشفيره إن وجد، ثم حماية TLS. وعكس المستقبل هذه العمليات.

بقي هذا الترتيب ثابتا حتى إن طلب العميل الوظائف بتسلسل زمني آخر. تاريخ التفاوض وترتيب تحويل البيانات حقيقتان مختلفتان. لذلك كان COMPRESS جزءا واعيا بحالة IMAP، لا أنبوبا شفافا يوضع تحته.

يحافظ قلب IMAP4rev2 الحالي على الانضباط العام نفسه عند انتقالات الحماية: نهاية رد النجاح تحدد بداية الطبقة الجديدة. تستطيع وصلة طويلة تغيير تمثيلها أو حمايتها فقط عندما يعتمد الطرفان حدا واحدا.

التكرار جعل الذاكرة ثمينة

ناسب IMAP الضغط. كرر العميل عددا قليلا من الأفعال. وكرر الخادم أشكال الرد وأسماء رؤوس البريد. وأعادت رسائل النقاش اقتباس عبارات سابقة. استطاع تاريخ متنام أن يستبدل السلاسل المكررة بإشارات أقصر.

لكن المرفق غيّر طبيعة المادة. قد لا يصغر أرشيف مضغوط أو ملف JPEG، وقد يطرد أنماط IMAP المفيدة من القاموس ويستهلك المعالج في تعلم مادة لن تعود. ناقشت الوثيقة إجراء مسح كامل حول الكتل الكبيرة وخفض الجهد مع الصيغ التي تبدو غير قابلة للضغط. كانت تلك قرارات محلية وليست أوامر IMAP جديدة.

جاءت الميزة من قرب الضاغط من التطبيق. عرف IMAP هل البايتات التالية نحو أم رؤوس أم نص أم كتلة literal. حسن ذلك التوفير، وجعل التطبيق مسؤولا عن السياق الذي احتفظ به.

التشفير لم يمح الطول

في 2007 أحال قسم الأمان في RFC 4978 بجملة واحدة إلى اعتبارات ضغط TLS في ذلك الوقت. غيرت الهجمات المدروسة لاحقا التقييم. بين CRIME وأعمال قريبة منه أن المحتوى قد يكون مشفرا بينما يظل طوله قابلا للرصد. إذا دخل سر ونص يستطيع المهاجم التأثير فيه في التاريخ نفسه، فقد تكشف محاولات متعددة متى اقترب التخمين من السر.

تخص الأمثلة التي لخصها IETF ضغط TLS والويب. لا تثبت استغلال IMAP COMPRESS ولا هشاشة كل سياق IMAP. لكنها تكفي لنقض فكرة أن الضغط قبل التشفير يحسم السرية وحده.

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

الحالة الخفية احتاجت إلى مالك

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

ليست العبرة حظرا غامضا للضغط. يجب تسمية السياق، ومعرفة من يؤثر في مدخلاته، ومن يرى حجم مخرجاته، ومدة بقاء التاريخ، وحدود موارد الفك، وطريق الإيقاف الآمن. التحسين الذي يتذكر هو آلة حالات بالفعل.

المصادر والحدود

يعرّف RFC 1951 صيغة DEFLATE. وتأتي قدرة IMAP وحد التحول وترتيب الطبقات واقتراحات الضبط من RFC 4978. يلخص RFC 7457 فئة الهجمات، ويحدد RFC 9051 قلب IMAP الحالي، ويقدم RFC 9325 إرشادات TLS الحالية، ولا تزال القدرة في سجل IANA لـ IMAP. لا تقيس هذه المصادر الاستخدام الحالي ولا تسجل اختراقا محددا عبر IMAP COMPRESS.