Wireshark doesn't really support it, but this way it at least decodes
the ESP packets correctly and the encryption keys are saved and the
packets can be decrypted. The full-length versions of SHA-384 and
SHA-512 are not supported by Wireshark as 256-bit is the longest ICV
it is able to decode currently.
This allows clients to send an empty certificate payload if the server
sent a certificate request. If an identity was set previously, it will
be reset so get_peer_id() may be used to check if the client was
authenticated.
The PT_TLS_AUTH_TLS_OR_SASL case currently can't be implemented properly
as TLS authentication will be enforced if a client identity is configured
on the TLS server socket.
To request client authentication if we don't know the client's identity,
it's possible to use ID_ANY. However, if we don't change the identity
get_peer_id() would still report ID_ANY after the authentication.
As client with older TLS versions, we have to ack the receipt of the server's
Finished message instead.
Fixes: 083f38259c ("tls-eap: Conclude EAP method also after processing packets")
The job is queued properly, yet the timing information is wrong.
Signed-off-by: Stefan Berghofer <stefan.berghofer@secunet.com>
Fixes: ee61471113 ("implemented RFC4478 (repeated authentication)...")
This seems to fix the build with Autotools that recently started to fail
with:
autom4te-2.69: need GNU m4 1.4 or later: /usr/local/bin/gm4
aclocal: error: /usr/local/bin/autom4te-2.69 failed with exit status: 1
autoreconf-2.69: aclocal failed with exit status: 1
Closesstrongswan/strongswan#197.
If the reauthentication is scheduled while rekeying, the difference
might be negative, however, schedule_job() takes an unsigned int,
so the reauth would get scheduled very far in the future.
If rekeying and reauthetication coincided, the reauth job could get
scheduled to run immediately i.e. before checkin() was called. So the
new IKE_SA would not get reauthenticated, however, the further delayed
delete job would later find the new IKE_SA and delete it.
This way, jobs for new IKE_SAs (created via create_new()) may be
scheduled/queued before checkin() is called. If they run before
that happens, they will now correctly block in checkout() instead of
doing nothing because the IKE_SA was not found.
We don't actually check that SA out (i.e. it's not registered with the
manager). That was originally different but had to be changed with
86993d6b90 to avoid that SAs created for rekeying don't block other
threads on the manager.
These changes should ensure that concurrent calls to checkout_by_config()
result in a single IKE_SA. For instance, when acquires for different
children of the same connection are triggered concurrently.
There are two major changes to the interface:
1) The peer config object is now always set on the returned IKE_SA.
That was previously only the case if an existing IKE_SA was
returned.
2) The IKE_SA is now always registered with the manager and properly
checked out, which also was only the case for existing IKE_SAs
before.
This adds support for TLS 1.3 to libtls and adds several new features to
existing TLS versions (e.g. support for x25519/x448, EdDSA or RSA-PSS).
Unfortunately, TLS 1.3 is not really usable for TLS-based EAP methods in
practice because, in particular, key derivation is not yet standardized.
While it works between two strongSwan instances and even FreeRADIUS 3.0.21,
there will be compatibility issues in the future when implementations move
to a standardized scheme. There are currently two Internet-Drafts in
development to specify that (see 121ac4b9e3 for details). Until they are
more stable, the default maximum version is set to 1.2.
The default minimum version has also been increased to 1.2 and several
older/weaker cipher suites have been removed (e.g. with 3DES and MD5).
If the default group listed in the cipher suite is not supported, we try
to use any other supported group (the groups are negotiated separately
so we are not locked in to a specific group).
Since DH groups (or with TLS < 1.3 curves) are negotiated separately,
it doesn't matter which one is listed in the cipher suite as any one could
be used.
Andreas Steffen