بعد ثلاث سنوات من التطوير، تم إصدار النسخة المستقرة الجديدة من خادم وكيل Squid، 5.1، وهي جاهزة للاستخدام في أنظمة الإنتاج (كانت الإصدارات 5.0.x تجريبية).
بعد استقرار فرع 5.x، سيتم من الآن فصاعدًا تطبيق إصلاحات الثغرات الأمنية ومشاكل الاستقرار فقط ، بالإضافة إلى تحسينات طفيفة. أما تطوير الميزات الجديدة فسيكون في فرع 6.0 التجريبي الجديد. وننصح مستخدمي فرع 4.x المستقر السابق بالتخطيط للانتقال إلى فرع 5.x.
Squid 5.1 الميزات الجديدة الرئيسية
في هذا الإصدار الجديد، تم إيقاف التوافق مع تنسيق Berkeley DB بسبب مشاكل الترخيص . لم يتم تحديث فرع Berkeley DB 5.x منذ عدة سنوات، ولا يزال يعاني من ثغرات أمنية لم يتم إصلاحها، كما أن الترقية إلى إصدارات أحدث لا تسمح بتغيير ترخيص AGPLv3، الذي تنطبق متطلباته أيضًا على التطبيقات التي تستخدم Berkeley DB كمكتبة. يُصدر Squid بموجب ترخيص GPLv2، وAGPL غير متوافق مع GPLv2.
بدلاً من استخدام Berkeley DB، انتقل المشروع إلى استخدام نظام إدارة قواعد البيانات TrivialDB، الذي يتميز، على عكس Berkeley DB، بأنه مُحسَّن للوصول المتزامن والمتوازي إلى قاعدة البيانات. لا يزال دعم Berkeley DB قائمًا في الوقت الحالي، ولكن يُنصح الآن باستخدام نوع التخزين "libtdb" بدلاً من "libdb" في معالجات "ext_session_acl" و"ext_time_quota_acl".
بالإضافة إلى ذلك ، تمت إضافة دعم لرأس HTTP CDN-Loop ، المحدد في RFC 8586 ، والذي يسمح باكتشاف الحلقات عند استخدام شبكات توصيل المحتوى (يوفر الرأس الحماية ضد المواقف التي يرجع فيها الطلب ، أثناء إعادة التوجيه بين شبكات CDN لسبب ما ، إلى CDN الأصلي ، وتشكيل حلقة لا نهائية).
علاوة على ذلك، أضافت آلية SSL-Bump، التي تسمح باعتراض محتوى جلسات HTTPS المشفرة، دعمًا لإعادة توجيه طلبات HTTPS المزورة من خلال خوادم وكيلة أخرى محددة في cache_peer باستخدام نفق عادي يعتمد على طريقة HTTP CONNECT (لا يتم دعم الإرسال عبر HTTPS، حيث لا يستطيع Squid حتى الآن إرسال TLS داخل TLS).
عند استلام أول طلب HTTPS مُعترض، يقوم برنامج SSL-Bump بإنشاء اتصال TLS مع الخادم المستهدف والحصول على شهادته. ثم يستخدم برنامج Squid اسم المضيف الخاص بالشهادة الحقيقية المُستلمة من الخادم لإنشاء شهادة مزيفة، يستخدمها لانتحال شخصية الخادم المطلوب عند التفاعل مع العميل ، مع الاستمرار في استخدام اتصال TLS المُنشأ مع الخادم المستهدف لاستلام البيانات.
ومن الجدير بالذكر أيضًا أن تطبيق بروتوكول ICAP (بروتوكول تكييف محتوى الإنترنت)، والذي يستخدم للتكامل مع أنظمة التحقق من المحتوى الخارجية، قد أضاف دعمًا لآلية إرفاق البيانات التي تسمح بإرفاق رؤوس بيانات وصفية إضافية بالاستجابة، ووضعها بعد نص الرسالة.
بدلاً من مراعاة "dns_v4_first»لتحديد ترتيب استخدام عائلة عناوين IPv4 أو IPv6 ، الآن يتم أخذ ترتيب الاستجابة في DNS في الاعتبار- إذا ظهرت استجابة AAAA من DNS أولاً أثناء انتظار حل عنوان IP ، فسيتم استخدام عنوان IPv6 الناتج. لذلك ، يتم الآن إعداد عائلة العنوان المفضل في جدار الحماية أو DNS أو عند بدء التشغيل باستخدام الخيار "–disable-ipv6".
سيؤدي التغيير المقترح إلى تسريع وقت تكوين اتصالات TCP وتقليل تأثير التأخير في حل DNS على الأداء.
عند إعادة توجيه الطلبات، يتم استخدام خوارزمية "Happy Eyeballs"، والتي تستخدم على الفور عنوان IP المستلم، دون انتظار حل جميع عناوين IPv4 و IPv6 الوجهة المتاحة المحتملة.
للاستخدام في التوجيه "external_acl" ، تمت إضافة برنامج التشغيل "ext_kerberos_sid_group_acl" للمصادقة مع مجموعات التحقق في Active Directory باستخدام Kerberos. يتم استخدام الأداة المساعدة ldapsearch التي توفرها حزمة OpenLDAP للاستعلام عن اسم المجموعة.
تمت إضافة توجيهات mark_client_connection و mark_client_pack لربط علامات Netfilter (CONNMARK) بالحزم الفردية أو اتصالات TCP الخاصة بالعميل
وأخيرًا، تجدر الإشارة إلى أنه باتباع خطوات الإصدارات المنشورة من Squid 5.2 و Squid 4.17، تم تصحيح الثغرات الأمنية التالية:
- CVE-2021-28116 - تسرب المعلومات عند معالجة رسائل WCCPv2 المعدة خصيصًا. تسمح الثغرة للمهاجم بإفساد قائمة أجهزة توجيه WCCP المعروفة وإعادة توجيه حركة المرور من العميل الوكيل إلى مضيفه. تظهر المشكلة فقط في التكوينات مع تمكين دعم WCCPv2 وعندما يكون من الممكن انتحال عنوان IP الخاص بالموجه.
- CVE-2021-41611: خطأ عند التحقق من صحة شهادات TLS التي تسمح بالوصول باستخدام شهادات غير موثوق بها.
وأخيرًا، إذا كنت ترغب في معرفة المزيد عن ذلك، يمكنك الاطلاع على التفاصيل عبر الرابط التالي.