Blog

Release and vulnerability announcements for strongSwan

strongSwan 5.9.10 Released

We are happy to announce the release of strongSwan 5.9.10, which fixes a vulnerability affecting TLS-based EAP methods, adds support for full packet hardware offload with Linux 6.2, properly supports TLS 1.3 in TLS-based EAP methods, can automatically install routes via XFRM interfaces, and comes with several other new features and fixes.

Vulnerability Related to Certificate Verification in TLS-based EAP Methods (CVE-2023-26463)

A vulnerability related to certificate verification in TLS-based EAP methods was fixed. Untrusted certificates were accepted causing an authentication bypass that was followed by an expired pointer dereference due to an incorrect reference count, which resulted in a denial of service but possibly even remote code execution. strongSwan versions 5.9.8 and 5.9.9 may be affected.

More information is provided in a separate blog entry.

Support for Full Packet Hardware Offload

The kernel-netlink plugin gained support for full packet hardware offload for IPsec SAs and policies, which the recent Linux 6.2 kernel introduced. In this mode, not only the crypto is offloaded to the interface but the complete ESP packet handling, including the policy matching (there is some policy matching in software for outbound/forwarded traffic to learn that it has to be offloaded).

Bypass and drop policies may also be offloaded by explicitly configuring an interface and hw_offload=packet. For the IKE ports, the plugin automatically offloads bypass policies to devices that support this type of offloading.

Be aware that offloaded SAs and policies currently disappear in the hardware and kernel if the interface goes down. So installing a drop policy in software or firewall rules that prevent traffic leaks in such a situation might be necessary.

Proper TLS 1.3 Support for TLS-based EAP Methods

The key derivation for TLS-based EAP methods has been change to that specified in draft-ietf-emu-tls-eap-types (currently in the RFC Editor's publication queue) when used with TLS 1.3 (which is optional and currently not the default). And the eap-tls plugin properly supports TLS 1.3 according to RFC 9190, by implementing the "protected success indication". Similarly, the eap-peap plugin correctly initiates Phase 2 with TLS 1.3 also if phase2_piggyback is disabled (default).

Optional Automatic Routes via XFRM Interfaces

Routes via XFRM interfaces can now optionally be installed automatically by enabling the charon.plugins.kernel-netlink.install_routes_xfrmi option. Such routes are only installed if an interface with the ID referenced in if_id_out exists when the corresponding CHILD_SA is installed by the kernel-netlink plugin. If the traffic selectors include the IKE traffic to the peer, special care is required (please refer to the docs for details).

Related to this is a change that makes the NetworkManager backend charon-nm use XFRM interfaces instead of dummy TUN devices to avoid issues with name resolution.

Other Notable Features and Fixes

  • With the new prefer value for the childless setting, initiators will create a childless IKE_SA if the responder supports the extension (RFC 6023). As responder, it has the same effect as allow.
  • The pki --req command can encode extendedKeyUsage (EKU) flags in the PKCS#10 CSR. The pki --issue command adopts EKU flags that are either directly encoded in CSRs or derived from an encoded profile string (msCertificateTypeExtension). With the --flag option, these flags can either be overridden completely, or specific flags can be added and/or removed from the encoded set.
  • When running on a Linux 6.2 kernel, the last use times of CHILD_SAs are determined by querying the IPsec SAs and not the policies (older kernels don't report the last use time per SA).
  • For libcurl with MultiSSL support, the curl plugin provides an option to select a specific SSL/TLS backend.

Download Complete Changelog