بعد ثلاث سنوات من التطوير تم إطلاق إصدار الإصدار المستقر الجديد من الخادم الوكيل Squid 5.1 وهو جاهز للاستخدام في أنظمة الإنتاج (الإصدارات 5.0.x كانت تجريبية).
بعد جعل فرع 5.x مستقرًا ، من الآن فصاعدًا ، سيتم إجراء إصلاحات فقط لقضايا الثغرات الأمنية والاستقرار، وسيتم أيضًا السماح بالتحسينات الثانوية. سيتم تطوير وظائف جديدة في الفرع التجريبي الجديد 6.0. يتم تشجيع مستخدمي الفرع الثابت 4.x الأقدم على التخطيط للترحيل إلى الفرع 5.x.
Squid 5.1 الميزات الجديدة الرئيسية
في هذا الإصدار الجديد تم إهمال دعم تنسيق Berkeley DB بسبب مشكلات الترخيص. لم تتم إدارة فرع Berkeley DB 5.x لعدة سنوات ولا يزال يعاني من ثغرات أمنية غير مصححة ، ولا تسمح الترقية إلى الإصدارات الأحدث بتغيير ترخيص AGPLv3 ، والذي تنطبق متطلباته أيضًا على التطبيقات التي تستخدم BerkeleyDB في شكل مكتبة. - تم إصدار Squid بموجب ترخيص GPLv2 و AGPL غير متوافق مع GPLv2.
بدلاً من Berkeley DB ، تم ترحيل المشروع لاستخدام TrivialDB DBMS ، والتي ، على عكس 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).
يسمح SSL-Bump ، عند وصول أول طلب HTTPS تم اعتراضه ، بإنشاء اتصال 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 التي تسمح بالوصول باستخدام شهادات غير موثوق بها.
أخيرًا ، إذا كنت تريد معرفة المزيد عنها ، فيمكنك التحقق من التفاصيل في الرابط التالي.