Sotong 5.1 tiba setelah tiga tahun pembangunan dan ini adalah perkara baru

Selepas tiga tahun pembangunan, versi stabil baharu pelayan proksi Squid, 5.1, telah dikeluarkan dan sedia untuk digunakan dalam sistem pengeluaran (versi 5.0.x adalah beta).

Selepas cabang 5.x mencapai keadaan stabil, mulai sekarang hanya pembetulan untuk kelemahan dan isu kestabilan akan dilaksanakan , berserta pengoptimuman kecil. Pembangunan ciri baharu akan berlaku dalam cabang eksperimen 6.0 yang baharu. Pengguna cabang 4.x yang stabil sebelumnya digalakkan untuk merancang migrasi ke cabang 5.x.

Sotong 5.1 Ciri-ciri Baru Utama

Dalam versi baharu ini, keserasian dengan format Berkeley DB telah ditamatkan kerana isu pelesenan . Cawangan Berkeley DB 5.x tidak diselenggara selama beberapa tahun dan masih mempunyai kelemahan yang belum ditambal, dan peningkatan kepada versi yang lebih baharu tidak membenarkan perubahan lesen AGPLv3, yang keperluannya juga terpakai pada aplikasi yang menggunakan Berkeley DB sebagai pustaka. Squid dikeluarkan di bawah lesen GPLv2, dan AGPL tidak serasi dengan GPLv2.

Daripada Berkeley DB, projek ini telah berhijrah untuk menggunakan TrivialDB DBMS, yang, tidak seperti Berkeley DB, dioptimumkan untuk akses selari serentak ke pangkalan data. Sokongan Berkeley DB dikekalkan buat masa ini, tetapi kini disyorkan untuk menggunakan jenis storan "libtdb" dan bukannya "libdb" dalam pengendali "ext_session_acl" dan "ext_time_quota_acl".

Sebagai tambahan, dukungan ditambahkan untuk header HTTP CDN-Loop, yang ditentukan dalam RFC 8586, yang memungkinkan untuk mengesan gelung ketika menggunakan rangkaian pengiriman konten (header memberikan perlindungan terhadap situasi di mana permintaan, selama pengalihan antara CDN untuk beberapa alasan, mengembalikan ke CDN asal, membentuk gelung tak terhingga).

Tambahan pula, mekanisme SSL-Bump, yang membolehkan pintasan kandungan sesi HTTPS yang disulitkan, telah menambah sokongan untuk mengalihkan permintaan HTTPS palsu melalui pelayan proksi lain yang dinyatakan dalam cache_peer menggunakan terowong biasa berdasarkan kaedah HTTP CONNECT (penghantaran melalui HTTPS tidak disokong, kerana Squid belum dapat menghantar TLS dalam TLS).

SSL-Bump, setelah menerima permintaan HTTPS yang dipintas pertama, akan mewujudkan sambungan TLS dengan pelayan sasaran dan mendapatkan sijilnya. Squid kemudian menggunakan nama hos sijil sebenar yang diterima daripada pelayan untuk mencipta sijil palsu, yang digunakannya untuk menyamar sebagai pelayan yang diminta semasa berinteraksi dengan klien , sambil terus menggunakan sambungan TLS yang telah diwujudkan dengan pelayan sasaran untuk menerima data.

Perlu juga diperhatikan bahawa pelaksanaan ICAP (Protokol Adaptasi Kandungan Internet), yang digunakan untuk penyepaduan dengan sistem pengesahan kandungan luaran, telah menambah sokongan untuk mekanisme lampiran data yang membolehkan pengepala metadata tambahan dilampirkan pada respons, diletakkan selepas isi mesej.

Daripada mengambil kira "dns_v4_first»Untuk menentukan urutan penggunaan keluarga alamat IPv4 atau IPv6, sekarang urutan tindak balas dalam DNS diambil kira- Sekiranya respons AAAA dari DNS muncul terlebih dahulu sementara menunggu alamat IP diselesaikan, alamat IPv6 yang dihasilkan akan digunakan. Oleh itu, tetapan keluarga alamat pilihan sekarang dilakukan di firewall, DNS, atau pada permulaan dengan pilihan "-disable-ipv6".
Perubahan yang dicadangkan akan mempercepat masa untuk mengkonfigurasi sambungan TCP dan mengurangkan kesan prestasi kelewatan dalam resolusi DNS.

Apabila mengalihkan permintaan, algoritma "Happy Eyeballs" digunakan, yang serta-merta menggunakan alamat IP yang diterima, tanpa menunggu semua alamat IPv4 dan IPv6 destinasi yang berpotensi tersedia diselesaikan.

Untuk digunakan dalam arahan "external_acl", pemacu "ext_kerberos_sid_group_acl" telah ditambahkan untuk pengesahan dengan kumpulan pengesahan di Active Directory menggunakan Kerberos. Utiliti ldapsearch yang disediakan oleh pakej OpenLDAP digunakan untuk meminta nama kumpulan.

Menambah arahan mark_client_connection dan mark_client_pack untuk mengikat teg Netfilter (CONNMARK) ke paket individu atau sambungan TCP pelanggan

Akhir sekali, dinyatakan bahawa, mengikut langkah-langkah versi Squid 5.2 dan Squid 4.17 yang diterbitkan, kelemahan berikut telah diperbetulkan:

  • CVE-2021-28116 - Kebocoran maklumat semasa memproses pesanan WCCPv2 yang dibuat khas. Kerentanan membolehkan penyerang merosakkan senarai penghala WCCP yang diketahui dan mengarahkan lalu lintas dari klien proksi ke hosnya. Masalahnya hanya muncul dalam konfigurasi dengan sokongan WCCPv2 yang diaktifkan dan apabila mungkin untuk menipu alamat IP penghala.
  • CVE-2021-41611: ralat semasa mengesahkan sijil TLS yang membenarkan akses menggunakan sijil tidak dipercayai.

Akhir sekali, jika anda ingin mengetahui lebih lanjut mengenainya, anda boleh menyemak butirannya di pautan berikut.


Tambahkan sebagai sumber pilihan dalam Google