The kernel creates such SAs to handle uncompressed small packets. They
are implicitly created and deleted with IPComp SAs. The problem is that
when we delete an IPComp SA only that state is deleted and removed from
the SA lists immediately, the IP-in-IP state is not removed until the IPComp
state is eventually destroyed. This could take a while if there are still
references to it around. So the IP-in-IP states will keep getting reported
by ip xfrm state until that happens (we also can't flush or explicitly delete
such kernel-created states).
In kernels before 4.14 this wasn't really a problem but since
ec30d78c14a8 ("xfrm: add xdst pcpu cache") the kernel seems to keep the
references to the last used SAs around a lot longer.
Also, usually a test scenario following an IPComp scenario will create
and use new SAs and thus the cached SAs will disappear before the kernel
state is checked again. However, if a following scenario uses different
hosts the states might remain, which caused some unrelated scenarios to
fail before adding this fix.
Depending on the plugins that eventually parse the certificate and CRL,
serials with MSB set (i.e. negative numbers that have a zero byte prefixed
when encoded as ASN.1 INTEGER) might have (x509 plugin) or not have
(openssl plugin) a zero byte prefix when returned by get_serial() or
enumerated from the CRL. Strip them before doing the comparison or
revocation checking might fail if not both credentials are parsed by the
same plugin (which should be rare and only happen if parsing of either
cert or CRL fails with one of the plugins and there is a fallback to the
implementation provided by the other plugin).
Fixes#2509.
Otherwise, the remote identity is ignored when matching owner identities
of PSKs and this way matching PSKs that explicitly have %any assigned is
improved.
Fixes#2497.
If users want to associate secrets with any identity, let 'em. This is
also possible with vici and might help if e.g. the remote identity is
actually %any as that would match a PSK with local IP and %any better
than one with local and different remote IP.
Fixes#2497.
This adds several route-based VPN scenarios (using VTI or GRE interfaces).
It also fixes several swanctl --list-sas checks in other scenarios.
Closesstrongswan/strongswan#84.
Use argument evaluation provided by settings_t instead of using strings
to enumerate key/values.
If section names contain dots the latter causes the names to get split
and interpreted as non-existing sections and subsections.
This currently doesn't work for connections and their subsections due to
the recursion.
Xcode 8.3, to which there recently was a switch, spits out a warning for
the potentially unaligned access to ip6_plen in ip-packet.c, which we
explicitly read via untoh16() hence the access to that pointer is not
actually unaligned. It seems the compiler is not able to determine that
there is no unaligned access even though the function is defined in the
header and marked inline.
This allows us to use it without having to initialize libcharon, which
was required for the logging (we probably could have included debug.h
instead of daemon.h to workaround that but this seems more correct).
We could make the same change for charon (actually setting it for charon
in strongswan.conf.testing would work for charon-systemd too), however,
there are dozens of test cases that currently set charondebug in
ipsec.conf.
Make sure, though, that we only remove the file if we actually
created it (e.g. not for --help or --version). And do so before
deinitializing libstrongswan due to leak detective.
Fixes#2460.
This adds support for RSASSA-PSS signatures in IKEv2 digital signature
authentication (RFC 7427), certificates and CRLs etc., and when signing
credentials via pki tool. For interoperability with older versions, the
default is to use classic PKCS#1 signatures. To use PSS padding either enable
rsa_pss via strongswan.conf or explicitly use it either via ike:rsa/pss...
auth token or the --rsa-padding option of the pki tool.
References #2427.
In theory we should treat any parameters and the identifier itself as
restriction to only use the key to create signatures accordingly (e.g.
only use RSA with PSS padding or even use specific hash algorithms).
But that's currently tricky as we'd have to store and pass this information
along with our private keys (i.e. use PKCS#8 to store them and change the
builder calls to pass along the identifier and parameters). That would
require quite some work.
For salt lengths other than 20 this requires 0bd8137e68c2 ("cipher:
Add option to specify salt length for PSS verification."), which was
included in libgcrypt 1.7.0 (for Ubuntu requires 17.04). As that makes
it pretty much useless for us (SHA-1 is a MUST NOT), we require that version
to even provide the feature.
Since not all implementations allow setting a specific salt value when
generating signatures (e.g. OpenSSL doesn't), we are often limited to
only using the test vectors with salt length of 0.
We also exclude test vectors with SHA-1, SHA-224 and SHA-384.
Tobias Brunner