Some clients like iOS/Mac OS X don't do a mode config exchange on the
new SA during re-authentication. If we don't adopt the previous virtual
IP Quick Mode rekeying will later fail.
If a client does do Mode Config we directly reassign the VIPs we migrated
from the old SA, without querying the attributes framework.
Fixes#807, #810.
TKM can't verify such signatures so we'd fail in the authorize hook.
Skipping the algorithm identifier doesn't help if the peer uses
anything other than SHA-1, so config changes would be required.
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
Especially callback jobs might refer to memory that gets invalid after
the plugins got unlaoded, so make sure we destroy these jobs before.
References #840.
Since we can't get rid of all unmet dependencies (at least not in every
possible plugin configuration) the message is more confusing than
helpful. In particular because a detailed warning about plugin features
that failed to load due to unmet dependencies is only logged on level 2.
In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.
Fixes#849.
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
The payload we sent before is not compliant with RFC 2407 and thus some
peers might abort negotiation (e.g. with an INVALID-PROTOCOL-ID error).
Fixes#819.
Some CAs don't use SHA-1 hashes of the public key as subjectKeyIdentifier and
authorityKeyIdentifier. If that's the case we can't force the
calculation of the hash to compare that to authorityKeyIdentifier in the CRL,
instead we use the subjectKeyIdentifier stored in the issuer certificate, if
available. Otherwise, we fall back to the SHA-1 hash (or comparing the
DNs) as before.
If many requests are sent to the kernel the events generated by these
requests may fill the receive buffer before the daemon is able to read
these messages.
Fixes#783.
This adds support for RFC 7427 signature authentication in IKEv2,
enabling the use of stronger signature schemes (e.g. RSA with SHA-2)
for IKE authentication.
Public key constraints defined in `rightauth` are now also checked
against IKEv2 signature schemes (may be disabled via strongswan.conf).
Fixes#863.
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
This enables late connection switching based on the signature scheme used
for IKEv2 and allows to enforce stronger signature schemes.
This may break existing connections with peers that don't support RFC 7427
if signature schemes are currently used in `rightauth` for certificate chain
validation and if the configured schemes are stronger than the default used
for IKE (e.g. SHA-1 for RSA).
We use the new signature authentication instead for this. This is not
backward compatible but we only released one version with BLISS support,
and the key format will change anyway with the next release.
There is a similar function to map key_type_t and hasher_t to an OID,
but this maps schemes directly (and to use the other function we'd
have to have a function to map schemes to hash algorithms first).
The previous code allowed an attacker to slip in an IKE_SA_INIT with
both SPIs and MID 1 set when an IKE_AUTH would be expected instead.
References #816.
It is mandated by the RFCs and it is expected by the task managers.
Initial messages with invalid MID will be treated like regular messages,
so no IKE_SA will be created for them. Instead, if the responder SPI is 0
no SA will be found and the message is rejected with ALERT_INVALID_IKE_SPI.
If an SPI is set and we do find an SA, then we either ignore the message
because the MID is unexpected, or because we don't allow initial messages
on established connections.
There is one exception, though, if an attacker can slip in an IKE_SA_INIT
with both SPIs set before the client's IKE_AUTH is handled by the server,
it does get processed (see next commit).
References #816.
This reverts 8f727d8007 ("Clean up IKE_SA state if IKE_SA_INIT request
does not have message ID 0") because it allowed to close any IKE_SA by
sending an IKE_SA_INIT with an unexpected MID and both SPIs set to those
of that SA.
The next commit will prevent SAs from getting created for IKE_SA_INIT messages
with invalid MID.
Fixes#816.
While these files are generated they don't really change and are not
architecture dependant. The previous solution prevented cross-compilation
from the repository as `bliss_huffman` was built for the target system but
was then executed on the build host to create the source files, which
naturally was bound to fail.
The `recreate-bliss-huffman` make target can be used inside the bliss
directory to update the source files if needed.
Fixes#812.
If the MySQL client library is linked against OpenSSL the mysql plugin
will cause a segmentation fault when it is unloaded after the openssl
plugin has already been deinitialized. This is very similar to the issues
with curl (see 44b6a34d43).
Fixes#814.
Coverity is still not happy when the result of an integer division is
assigned to a double (without e.g. casting the result to an int first to
indicate the intent). The shift should avoid this issue.
Before this fix it was possible to crash charon with an IKE_SA_INIT
message containing a KE payload with DH group MODP_CUSTOM(1025).
Defining MODP_CUSTOM outside of the two byte IKE DH identifier range
prevents it from getting negotiated.
Fixes CVE-2014-9221.
The FreeBSD and Mac OS X kernels interpret sadb_sa_replay as the size of the
replay window in bytes. Linux on the other hand does the same for PF_KEY it
does for XFRM so sadb_sa_replay denotes the number of packets/bits in the
window. Similarly, the window size on Linux is limited to 32 by the four
byte default bitmap used for IPsec SAs (may only be changed with
XFRMA_REPLAY_ESN_VAL), which is not the case on the other platforms.
Since 42e0a317c6 ("ike: Only parse payloads valid for the current IKE
version") payload types are checked before creating objects. This check
failed for internally used payload types (e.g. proposal substructures),
which have a type >= 256, i.e. outside the IKE payload type range.
This requires moving test files so that the Makefile for the tests can be
included after building libstrongswan, which requires the plugin when
building monolithically. Due to this a static helper library is required
as directly referring to object files (or source files) is not possible.
It's also necessary to avoid any link-time dependency on libstrongswan in
bliss_huffman, to avoid circular dependencies (bliss_huffman -> libstrongswan
-> bliss -> bliss_huffman).
Theoretically, n could be zero and these variables are then used
uninitialized. Older GCC versions warn about this and on Travis where we
compile with -Werror this causes the tests to fail.
The transform identifier used in AH transforms is not the same as the
authentication algorithm identifier used in the transform attributes in
AH (and ESP) transforms.
Tobias Brunner