Tobias Brunner [Thu, 18 Feb 2021 14:10:42 +0000 (15:10 +0100)]
tls-server: Add flag that makes client authentication optional
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.
Tobias Brunner [Thu, 18 Feb 2021 11:34:29 +0000 (12:34 +0100)]
pt-tls-server: Explicitly request client authentication if necessary
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.
Tobias Brunner [Thu, 18 Feb 2021 11:31:17 +0000 (12:31 +0100)]
tls-server: Use subject DN as peer identity if it was ID_ANY
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.
Fedor Korotkov [Mon, 15 Feb 2021 18:58:55 +0000 (13:58 -0500)]
cirrus: Use FreeBSD 12.2
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
Tobias Brunner [Fri, 15 Jan 2021 15:19:49 +0000 (16:19 +0100)]
ike-sa: Avoid possible integer underflow when scheduling reauth after rekeying
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.
Tobias Brunner [Fri, 15 Jan 2021 15:25:54 +0000 (16:25 +0100)]
ike-rekey: Register new IKE_SA before calling inherit_post()
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.
Tobias Brunner [Fri, 15 Jan 2021 15:09:59 +0000 (16:09 +0100)]
ike-sa-manager: Add a method to register/check out new IKE_SAs
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.
Tobias Brunner [Fri, 15 Jan 2021 15:08:20 +0000 (16:08 +0100)]
ike-sa-manager: Rename checkout_new() to create_new()
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 86993d6b9037 to avoid that SAs created for rekeying don't block other
threads on the manager.
Tobias Brunner [Tue, 17 Mar 2020 08:39:17 +0000 (09:39 +0100)]
ike-sa-manager: Make checkout_by_config() atomic
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.
Tobias Brunner [Fri, 12 Feb 2021 14:14:37 +0000 (15:14 +0100)]
Merge branch 'tls13'
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 121ac4b9e37e 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).
Tobias Brunner [Thu, 11 Feb 2021 16:46:17 +0000 (17:46 +0100)]
tls-crypto: Fallback to any supported ECDH group
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).
Tobias Brunner [Thu, 11 Feb 2021 16:09:04 +0000 (17:09 +0100)]
tls-crypto: Don't filter suites with specific ECDH group if any is available
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.
Tobias Brunner [Fri, 22 Jan 2021 09:06:05 +0000 (10:06 +0100)]
tls-server: Select cipher suite also when handling HelloRetryRequest
This was previously treated like a resumption, which it is clearly not.
Also added a check that verifies that the same cipher suite is selected
during the retry, as per RFC 8446, section 4.1.4.
Shmulik Ladkani [Fri, 15 Jan 2021 13:45:34 +0000 (14:45 +0100)]
tls-server: Optionally omit CAs in CertificateRequest messages
Usually, the DNs of all loaded CA certificates are included in the
CertificateRequest messages sent by the server.
Alas, certain EAP-TLS clients fail to process this message if the
list is too long, returning the fatal TLS alert 'illegal parameter'.
This new option allows configuring whether CAs are included or an
empty list is sent (TLS 1.2), or the certificate_authorities extension
is omitted (TLS 1.3). The list only serves as hint/constraint
for clients during certificate selection, they still have to provide
a certificate but are free to select any one they have available.
Tobias Brunner [Thu, 14 Jan 2021 17:02:00 +0000 (18:02 +0100)]
tls-eap: Conclude EAP method also after processing packets
With TLS 1.3, the server sends its Finished message first, so the
session is complete after processing the client's Finished message,
without having to send anything else (in particular no acknowledgement
as the last message from the client is no fragment).
Tobias Brunner [Thu, 14 Jan 2021 14:45:34 +0000 (15:45 +0100)]
libtls: Only run socket tests with EdDSA keys if they are supported
ECDSA support is currently required to run the tests because ECDSA
cipher suites are not filtered when determining the supported cipher
suites. Also required are ECDH groups.
Tobias Brunner [Thu, 14 Jan 2021 14:11:13 +0000 (15:11 +0100)]
tls-crypto: Only log modified TLS versions if successfully set
If no cipher suites are available, the new versions are the previous
values but reversed (i.e. the versions were not changed but we still
ended up with a log message saying "TLS min/max TLS 1.3/TLS 1.0 ...").
Also switched to using the numeric version names to avoid the repeated
"TLS" prefix.
Pascal Knecht [Fri, 30 Oct 2020 14:15:30 +0000 (15:15 +0100)]
tls-server: Mutual authentication support for TLS 1.3
This commit also addresses the side effect that additional messages have
an influence on the derivation of the application traffic secrets. Therefore,
key derivation is relocated after the server finished message has been sent,
so the additional messages from the client (Certificate, CertificateVerify)
don't affect the key derivation. Only the outbound key is switched there, the
inbound key remains in use until the client's finished message has been
processed.
Pascal Knecht [Wed, 4 Nov 2020 12:07:49 +0000 (13:07 +0100)]
tls-server: Terminate connection if peer certificate is required but not sent
This change mainly affects legacy TLS versions because TLS 1.3
connections are terminated by the server once the peer does not send a
CertificateVerify message next to its empty Certificate message.
Pascal Knecht [Sun, 8 Nov 2020 14:34:39 +0000 (15:34 +0100)]
tls-hkdf: Always use correct base key to derive finished message
The cached traffic secrets change once the application traffic secrets
are derived, but we must always use the correct base key to derive the
finished message, which are the handshake traffic secrets (RFC 8446,
section 4.4).
Pascal Knecht [Mon, 12 Oct 2020 16:58:53 +0000 (18:58 +0200)]
tls-server: Consider supported signature algorithms when selecting key/certificate
This won't work if the client doesn't send a `signature_algorithms`
extension. But since the default is SHA1/RSA, most will send it to at
least announce stronger hash algorithms if not ECDSA.
Pascal Knecht [Tue, 13 Oct 2020 11:54:38 +0000 (13:54 +0200)]
tls-crypto: Distinguish between signing and verifying signature schemes
strongSwan supports RSA_PSS_RSAE schemes for signing but does not
differentiate between rsaEncryption and rsassaPss encoding. Thus
RSA_PSS_PSS schemes are only used for verifying signatures.
Pascal Knecht [Fri, 2 Oct 2020 16:11:45 +0000 (18:11 +0200)]
tls-server: Support multiple client key shares
A client can send one or multiple key shares from which the server picks
one it supports (checked in its preferred order). A retry is requested if
none of the key shares are supported.
Adds support to request and handle retries with a different DH group.
Only the first key share extension sent by the client is currently
considered, so this might result in protocol errors if the server requests
a group for which the client already sent a key share.
tls-crypto: Fix invalid signature algorithm list building
List building also added an additional length field which is required by
client-side TLS extensions but not for server-side certificate request
extension. Now the method only returns a list of supported signature
algorithms and the implementation is responsible to add additional
length fields.
Fixes: 07f826af673d ("Fixed encoding of TLS extensions (elliptic_curves and signature_algorithms)")
Tobias Brunner [Thu, 19 Nov 2020 13:40:30 +0000 (14:40 +0100)]
tls-server: Determine supported/configured suites and versions early
If we don't do this, we might negotiate a TLS version for which we don't
have any suites configured, so that the cipher suite negotiation
subsequently fails.
tls-crypto: Check if TLS versions and cipher suites match
Only suggest TLS versions of supported cipher suites. For instance, do not
suggest TLS 1.3 if none of its cipher suites (requiring GCM/CCM or
ChaPoly) are available.
tls-peer: Return INVALID_STATE after changing TLS 1.3 keys
Even though we return from build(), we are not actually sending a response,
so we can't return NEED_MORE (would send an invalid ClientHello message) and
if we return SUCCESS, the EAP layer treats this as failure (there is a comment
in eap_authenticator_t about client methods never returning SUCCESS from
process()). Instead we return INVALID_STATE, which allows tls_t.build() to
exit from the build() loop immediately and send the already generated Finished
message.
We generate material for both MSK and EMSK even though we only need the
former. Because HKDF-Expand-Label(), on which the export functionality
is based, encodes the requested key length, we have to allocate the same
number of bytes as e.g. FreeRADIUS does (i.e. if we only request 64
bytes, those won't be the same as the first 64 bytes after requesting
128 bytes).
Unfortunately, key derivation for TLS-based methods is currently not
standardized for TLS 1.3. There is a draft [1], which defines a scheme
that's different from previous versions (instead of individual label
strings it uses a single one and passes the EAP type/code as context
value to TLS-Export()). The current code is compatible to FreeRADIUS
3.0.x, which doesn't implement it according to that draft yet (there are
unreleased changes for EAP-TLS, not for the other methods, but these only
switch the label, no context value is passed). In a separate draft
for EAP-TLS [2] there is an altogether different scheme defined in the
latest version (label combined with EAP method, no context and separate
derivation for MSK and EMSK).
So this is a mess and we will have to change this later with the inevitable
compatibility issues (we should definitely disable TLS 1.3 by default).
Tobias Brunner [Fri, 28 Aug 2020 06:59:37 +0000 (08:59 +0200)]
tls-crypto: Add support for RSA-PSS signatures
PKCS#1 v1.5 signatures are not defined for use with TLS 1.3 (they can
only appear in certificates, we now send a signature_algorithms_cert
extension to indicate support for them). So for RSA certificates, we
must support RSA-PSS signatures.
There are two sets of schemes, that are differentiated by the type of
RSA key used for the signature, one is for classic RSA keys (rsaEncryption
OID), which can also be used with PKCS#1 when using TLS 1.2, the other
is for RSA-PSS keys (RSASSA-PSS OID), which are not yet commonly
used (and can't be generated by our pki tool). According to the RFC,
PSS must also be supported for TLS 1.2 if the schemes are included in
the signature_algorithms extension (e.g. OpenSSL does not use PKCS#1 v1.5
anymore if PSS is proposed).
This changes how these schemes are stored and enumerated (they are not
treated as combination of hash algo and key type anymore).