Version 5.5.1
The newhope plugin implements the post-quantum NewHope key exchange algorithm
proposed in their 2015 paper by Erdem Alkim, Léo Ducas, Thomas Pöppelmann and
Peter Schwabe.
The libstrongswan crypto factory now offers the registration of Extended
Output Functions (XOFs). Currently supported XOFs are SHAKE128 and SHAKE256
implemented by the sha3 plugin, ChaCHa20 implemented by the chapoly plugin
and the more traditional MGF1 Mask Generation Functions based on the SHA-1,
SHA-256 and SHA-512 hash algorithms implemented by the new mgf1 plugin.
By default, the "outbound" FWD policies, introduced with 5.5.0, are not installed anymore.
They may be enabled via the policies_fwd_out setting in swanctl.conf/vici for a specific
CHILD_SA if its traffic would otherwise get blocked by a drop policy.
A bug in regards to updating reqids in the kernel-netlink plugin, that was particularly a problem
with duplicate "outbound" FWD policies, has also been fixed (175d78df60).
XFRM policy hashing thresholds may be configured via strongswan.conf. This can significantly
improve the performance on hosts where the number of flows exceeds the flow cache size of the
Linux kernel. Policies covering more than a single address don't get hash-indexed by default,
which results in wasting most of the cycles in xfrm_policy_lookup_bytype() and the called
xfrm_policy_match(). Since Linux 3.18 the kernel can hash the first n-bit of a policy subnet to
perform indexed lookups. With correctly chosen thresholds this can completely eliminate the
performance impact of policy lookups.
Note: Due to a bug in Linux 3.19 through 4.7, the kernel crashes with a NULL pointer dereference
if a socket policy (used by strongSwan to exempt IKE traffic from IPsec tunnels) is installed while
hash thresholds are changed. See ac9759a532 for details and a workaround.
The NetworkManager integration has been updated to support NM 1.2.
The directory from which CA certificates are loaded if no certificate is configured in the GUI can
now be configured via strongswan.conf using the new charon-nm.ca_dir setting.
IKE fragmentation is now enabled by default with the default fragment size set to 1280 bytes
for both IP address families.
A DELETE is sent when a rekeyed IKEv1 SA is deleted. This fixes issues with peers that continue
to send DPDs on the old SA and then delete all SAs if no response is received (see #2090).
Also, when terminating IKEv1 SAs, DELETEs for all CHILD_SAs are now sent before sending one for
the IKE_SA and destroying it.
The pki tool, with help of the pkcs1 or openssl plugins, can parse private keys in any of the
supported formats without having to know the exact type. So instead of having to specify rsa or
ecdsa explicitly the keyword priv may be used to indicate a private key of any type.
Similarly, swanctl can load any type of private key from the swanctl/private directory.
The pki tool can handle RSASSA-PKCS1v1.5-with-SHA-3 signatures using the
sha3 and gmp plugins.
The VICI flush-certs command flushes certificates from the volatile certificate cache.
Optionally the type of the certificates to be flushed (e.g. type = x509_crl) can be specified.
When setting charon.cache_crls = yes in strongswan.conf the vici plugin saves regular,
base and delta CRLs to disk.
Fetched CRLs are now also cached if the checked certificate has been revoked.
The serial number for delta CRLs generated by pki --signcrl is now based on
the given base CRL again (was broken since 4.6.3).
Delta CRLs are now properly cached in-memory (and on disk) together with their base. Before this
the presence of a delta CRL might have required that the base be refetched every time.
When verifying trust chains with pki --verify local CRLs may now be specified with the
new --crl argument.
IKE and ESP/AH proposals configured as strings in ipsec.conf and swanctl.conf (or VICI) are now
checked to avoid invalid proposals. For instance, the presence of DH, PRF and encryption algorithms
for IKE proposal are now enforced and AEAD and regular encryption algorithms are not allowed in
the same proposal anymore. Also fixed is the mapping of the aes*gmac keywords to an integrity
algorithm in AH proposals.
Unmarked packets may now be matched by setting 0/0xffffffff as XFRM mark (33d3ffde25).
The maximum registered log level is now determined correctly if loggers implementing only
log or vlog are mixed (dac15e03c8).
In addition to the existing ike_keys and child_keys hooks on listener_t two new hooks
allow listeners to receive the derived IKE and CHILD_SA keys (ike|child_derived_keys).
The check for libatomic has been improved (6e19a1f5f2).
The use of AES-GCM with BoringSSL has been fixed (c72c6e9225).
libtpmtss: In the TSS2 API the function TeardownSocketTcti() was replaced by
tss2_tcti_finalize().
The results of leak-detective are now evaluated in our testing environment, which
lead to the fixing of several memory leaks.
No key and self-signed certificate is generated by starter anymore if ipsec.secrets does not exist.
The long unmaintained Maemo plugin and frontend have been removed.

CVE-2017-9022
RSA public keys passed to the gmp plugin aren't validated sufficiently
before attempting signature verification, so that invalid input might
lead to a floating point exception and crash of the process.
A certificate with an appropriately prepared public key sent by a peer
could be used for a denial-of-service attack.
CVE-2017-9023
ASN.1 CHOICE types are not correctly handled by the ASN.1 parser when
parsing X.509 certificates with extensions that use such types. This could
lead to infinite looping of the thread parsing a specifically crafted
certificate.

This update for strongswan fixes the following issues:
- CVE-2017-9022: Insufficient Input Validation in gmp Plugin leads to
Denial of service (bsc#1039514)
- CVE-2017-9023: Incorrect x509 ASN.1 parser error handling could lead to
Denial of service (bsc#1039515)
StrongSwan shold be updated to 5.5.3

A denial of service vulnerability was identified in strongSwan, an IKE/IPsec suite, using Google's OSS-Fuzz fuzzing project.
The gmp plugin in strongSwan had insufficient input validation when verifying RSA signatures. This coding error could lead to a null pointer dereference, leading to process crash.
https://www.debian.org/security/2017/dsa-3962

Built and published release 5.6.0 for Rosa 2016.1.
It solves also CVE-2017-11185.
BTW, the sw has a bazillion configure options: since you are evidently using strongswan (or at least care about it), what do you think it would be good to enable?
Perhaps we could improve our package...

Well, I use the software for communication to and from my home network.
My ipsec.conf file is the only thing that really varies and it is configured to communicate with my system PKI.
What does need to happen is strongswan support needs to be integrated into network manager.