forked from pool/strongswan
8cfc35877a
- Updated to strongSwan 5.3.5 providing the following changes: *Fixed a DoS vulnerability in the gmp plugin that was caused by insufficient input validation when verifying RSA signatures. More specifically, mpz_powm_sec() has two requirements regarding the passed exponent and modulus that the plugin did not enforce, if these are not met the calculation will result in a floating point exception that crashes the whole process. This vulnerability has been registered as CVE-2017-9022. Please refer to our blog for details. *Fixed a DoS vulnerability in the x509 plugin that was caused because the ASN.1 parser didn't handle ASN.1 CHOICE types properly, which could result in an infinite loop when parsing X.509 extensions that use such types. This vulnerability has been registered as CVE-2017-9023. Please refer to our blog for details. *The behavior during IKEv2 CHILD_SA rekeying has been changed in order to avoid traffic loss. When responding to a CREATE_CHILD_SA request to rekey a CHILD_SA the responder already has everything available to install and use the new CHILD_SA. However, this could lead to lost traffic as the initiator won't be able to process inbound packets until it processed the CREATE_CHILD_SA response and updated the inbound SA. To avoid this the responder now only installs the new inbound SA and delays installing the outbound SA until it receives the DELETE for the replaced CHILD_SA. *The messages transporting these DELETEs could reach the peer before packets sent with the deleted outbound SAs reach it. To reduce the chance of traffic loss due to this the inbound SA of the replaced CHILD_SA is not removed for a configurable amount of seconds (charon.delete_rekeyed_delay) after the DELETE has been processed. *The code base has been ported to Apple's ARM64 iOS platform, which required several changes regarding the use of variadic functions. This was necessary because the calling conventions for variadic and regular functions are different there. This means that assigning a non-variadic function to a variadic function pointer, as we did with our enumerator_t::enumerate() implementations and several callbacks, will result in crashes as the called function accesses the arguments differently than the OBS-URL: https://build.opensuse.org/request/show/513652 OBS-URL: https://build.opensuse.org/package/show/network:vpn/strongswan?expand=0&rev=99 |
||
---|---|---|
.gitattributes | ||
.gitignore | ||
0005-ikev1-Don-t-retransmit-Aggressive-Mode-response.patch | ||
0006-Fix-RSA-signature-verification-for-m.patch | ||
fips-enforce.conf | ||
fipscheck.sh.in | ||
README.SUSE | ||
strongswan_fipscheck.patch | ||
strongswan_fipsfilter.patch | ||
strongswan_ipsec_service.patch | ||
strongswan_modprobe_syslog.patch | ||
strongswan-5.5.3-rpmlintrc | ||
strongswan-5.5.3.tar.bz2 | ||
strongswan-5.5.3.tar.bz2.sig | ||
strongswan.changes | ||
strongswan.init.in | ||
strongswan.keyring | ||
strongswan.spec |
Dear Customer, please note, that the strongswan release 4.5 changes the keyexchange mode to IKEv2 as default -- from strongswan-4.5.0/NEWS: "[...] IMPORTANT: the default keyexchange mode 'ike' is changing with release 4.5 from 'ikev1' to 'ikev2', thus commemorating the five year anniversary of the IKEv2 RFC 4306 and its mature successor RFC 5996. The time has definitively come for IKEv1 to go into retirement and to cede its place to the much more robust, powerful and versatile IKEv2 protocol! [...]" This requires adoption of either the "conn %default" or all other IKEv1 "conn" sections in the /etc/ipsec.conf to use explicit: keyexchange=ikev1 The charon daemon in strongswan 5.x versions supports IKEv1 and IKEv2, thus a separate pluto IKEv1 daemon is not needed / not shipped any more. The strongswan package does not provide any files except of this README, but triggers the installation of the charon daemon and the "traditional" strongswan-ipsec package providing the "ipsec" script and service. The ipsec.service is an alias link to the "strongswan.service" systemd service unit and created by "systemctl enable strongswan.service". There is a new strongswan-nm package with a NetworkManager specific charon-nm binary controlling the charon daemon through D-Bus and designed to work using the NetworkManager-strongswan graphical user interface. It does not depend on the traditional starter scripts, but on the IKEv2 charon daemon and plugins only. The stongswan-hmac package provides the fips hmac hash files, a _fipscheck script and a /etc/strongswan.d/charon/zzz_fips-enforce.conf config file, which disables all non-openssl algorithm implementations. When fips operation mode is enabled in the kernel using the fips=1 boot parameter, the strongswan fips checks are executed in front of any start action of the "ipsec" script provided by the "strongswan-ipsec" package and a verification problem causes a failure as required by fips-140-2. Further, it is not required to enable the fips_mode in the openssl plugin (/etc/strongswan.d/charon/openssl.conf); the kernel entablement enables it automatically as needed. The "ipsec _fipscheck" command allows to execute the fips checks manually without a check if fips is enabled (/proc/sys/crypto/fips_enabled is 1), e.g. for testing purposes. Have a lot of fun...