بعد ثلاث سنوات من التطوير ، تم تقديم إصدار ثابت من الخادم الوكيل Squid 5.1 ، وهو جاهز للاستخدام في أنظمة الإنتاج (الإصدارات 5.0.x لها حالة الإصدارات التجريبية). بعد جعل فرع 5.x مستقرًا ، سيعمل الآن فقط على إصلاح الثغرات الأمنية ومشكلات الاستقرار ، كما يُسمح أيضًا بالتحسينات الطفيفة. سيتم تنفيذ تطوير ميزات جديدة في فرع تجريبي جديد 6.0. يُنصح مستخدمو الفرع الثابت 4.x السابق بالتخطيط للترحيل إلى الفرع 5.x.
ابتكارات Squid 5 الرئيسية:
- أدى تنفيذ بروتوكول ICAP (بروتوكول تعديل محتوى الإنترنت) ، المستخدم للتكامل مع أنظمة فحص المحتوى الخارجية ، إلى إضافة دعم لآلية إرفاق البيانات (مقطورة) ، مما يسمح لك بإرفاق رؤوس إضافية مع البيانات الوصفية الموضوعة بعد نص الرسالة إلى (على سبيل المثال ، يمكنك إرسال مجموع اختباري وتفاصيل المشكلات المحددة).
- عند إعادة توجيه الطلبات ، يتم استخدام خوارزمية "Happy Eyeballs" ، والتي تستخدم على الفور عنوان IP المستلم ، دون انتظار حل جميع عناوين IPv4 و IPv6 المستهدفة المحتملة المتاحة. بدلاً من التفكير في إعداد "dns_v4_first" لتحديد الترتيب الذي يتم فيه استخدام مجموعة عناوين IPv4 أو IPv6 ، يتم الآن احترام ترتيب استجابة DNS: إذا وصل رد DNS AAAA أولاً أثناء انتظار حل عنوان IP ، فسيتم سيتم استخدام عنوان IPv6. وبالتالي ، يتم الآن تعيين عائلة العناوين المفضلة على مستوى جدار الحماية أو DNS أو بدء التشغيل باستخدام الخيار "--disable-ipv6". يعمل التغيير المقترح على تسريع وقت إعداد اتصال TCP ويقلل من تأثير أداء زمن انتقال حل DNS.
- للاستخدام في التوجيه "external_acl" ، تمت إضافة معالج "ext_kerberos_sid_group_acl" للمصادقة مع التحقق من المجموعة في Active Directory باستخدام Kerberos. يتم استخدام الأداة المساعدة ldapsearch التي توفرها حزمة OpenLDAP للاستعلام عن اسم المجموعة.
- تم إيقاف دعم تنسيق Berkeley DB بسبب مشكلات الترخيص. لم يتم الحفاظ على فرع Berkeley DB 5.x لعدة سنوات ولا يزال يعاني من ثغرات أمنية لم يتم إصلاحها ، ولا يسمح التبديل إلى الإصدارات الأحدث بتغيير الترخيص إلى AGPLv3 ، والتي تنطبق متطلباتها أيضًا على التطبيقات التي تستخدم BerkeleyDB في شكل مكتبة - تم ترخيص Squid بموجب GPLv2 ، و AGPL غير متوافق مع GPLv2. بدلاً من Berkeley DB ، تم تحويل المشروع إلى استخدام TrivialDB DBMS ، والذي ، على عكس Berkeley DB ، تم تحسينه للوصول المتوازي المتزامن إلى قاعدة البيانات. تم الاحتفاظ بدعم Berkeley DB في الوقت الحالي ، ولكن يوصى الآن باستخدام معالجات "ext_session_acl" و "ext_time_quota_acl" لاستخدام نوع التخزين "libtdb" بدلاً من "libdb".
- دعم إضافي لرأس CDN-Loop HTTP ، المحدد في RFC 8586 ، والذي يسمح لك باكتشاف الحلقات عند استخدام شبكات توصيل المحتوى (يوفر الرأس الحماية ضد المواقف عندما يعود طلب في عملية إعادة التوجيه بين شبكات CDN لسبب ما مرة أخرى إلى CDN الأصلي ، وتشكيل حلقة لا نهائية).
- تمت إضافة دعم إعادة توجيه طلبات HTTPS المخادعة (المعاد تشفيرها) من خلال خوادم بروكسي أخرى محددة في cache_peer باستخدام نفق عادي يعتمد على طريقة HTTP CONNECT إلى آلية SSL-Bump ، مما يسمح بتنظيم اعتراض محتويات جلسات HTTPS المشفرة (الإرسال عبر HTTPS غير مدعوم لأن Squid لا يمكنه اجتياز TLS حتى الآن داخل TLS). يسمح SSL-Bump ، عند استلام أول طلب HTTPS تم اعتراضه ، بإنشاء اتصال TLS مع الخادم الهدف والحصول على شهادته. بعد ذلك ، يستخدم Squid اسم المضيف من الشهادة الحقيقية المستلمة من الخادم وينشئ شهادة وهمية تحاكي بها الخادم المطلوب عند التفاعل مع العميل ، مع الاستمرار في استخدام اتصال TLS الذي تم إنشاؤه مع الخادم الهدف لتلقي البيانات (لذلك أن الاستبدال لا يؤدي إلى تحذيرات الإخراج في المتصفحات من جانب العميل ، فأنت بحاجة إلى إضافة شهادتك المستخدمة لإنشاء شهادات وهمية إلى مخزن الشهادات الجذر).
- تمت إضافة توجيهات 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 ، مما سمح بالوصول باستخدام شهادات غير موثوق بها.
المصدر: opennet.ru