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).
Tobias Brunner [Fri, 28 Aug 2020 09:56:36 +0000 (11:56 +0200)]
tls-socket: Change how EOF of the underlying socket is handled
With the previous code, there was an issue when replying to TLS 1.3
post-handshake messages. In this case, SUCCESS is eventually returned
from build(), however, no actual data has been received so in_done is 0.
This was interpreted as EOF, plain_eof was set to TRUE and no further data
was read from the socket afterwards.
Returning SUCCESS from build() if the exchange is initiated by
write_(), as is the case with the finished reply, never was a problem
because there the return value of 0 is not interpreted as EOF.
Tobias Brunner [Wed, 26 Aug 2020 15:42:21 +0000 (17:42 +0200)]
tls-socket: Don't fail reading if sending data failed
If data is processed that eventually includes a TLS close notify, build()
will fail after a close notify has been sent in turn. However, propagating
that error immediately when reading prevented ever returning the data
already processed before the close notify was received.
Tobias Brunner [Tue, 25 Aug 2020 14:18:27 +0000 (16:18 +0200)]
tls-peer: Refactor writing of extensions and use less hard-coded DH group
Note that this breaks connecting to many TLS 1.3 servers until we support
HelloRetryRequest as we now send a key_share for ECP_256 while still
proposing other groups, so many servers request to use CURVE_25519.
Tobias Brunner [Wed, 26 Aug 2020 13:23:53 +0000 (15:23 +0200)]
tls-peer: Support x25519/448 for TLS 1.2
These DH groups don't use the point format prefix (RFC 8422 deprecated
any other format anyway). Since they are enumerated now, they can also
be used by servers for TLS 1.2.
Tobias Brunner [Tue, 25 Aug 2020 11:54:08 +0000 (13:54 +0200)]
tls-crypto: Filter TLS cipher suites by min/max version
There is no point proposing legacy (or future) cipher suites depending on
the proposed TLS versions. It was actually possible to negotiate and use
cipher suites only defined for TLS 1.2 with earlier TLS versions.
bytinbit [Thu, 21 May 2020 07:37:38 +0000 (09:37 +0200)]
libtls: Implement TLS 1.3 handshake on client-side
The code is a minimal handshake with the HelloRetryRequest message
implementation missing.
Can be tested with an OpenSSL server running TLS 1.3. The server must
be at least version 1.1.1 (September 2018).
The key material, in particular the nonce/IV, is derived differently and
the IV is also generated in a different way. Additionally, the actual
content type is encrypted and there may be optional padding to mask the
actual size of the encrypted data.
Tobias Brunner [Thu, 11 Feb 2021 09:20:43 +0000 (10:20 +0100)]
appveyor: Set timezone on the build system
For some reason, setting the time zone via TZ to `GST-1GDT` in the utils test
doesn't work anymore (the DST zone is not considered, it's as if only `GST-1`
was configured).
Tobias Brunner [Wed, 10 Feb 2021 16:55:06 +0000 (17:55 +0100)]
openssl: Allocate our own buffer for i2d_* wrapper macro
If we pass a pointer to NULL, the memory allocated by OpenSSL has to be
freed with OPENSSL_free(). Otherwise, this can lead to random
crashes/freezes for Windows builds as seen on AppVeyor. To not
complicate things for callers of this macro, we allocate our own memory,
which we already do for other i2d_* calls.
Tobias Brunner [Fri, 18 Dec 2020 13:17:37 +0000 (14:17 +0100)]
openssl: Reset HMAC key if chunk_empty is passed
If no valid key is configured (e.g. because it's inadvertently uninitialized),
we should not just reuse the previous key.
The `key_set` flag is not necessary anymore because a non-NULL key is set
during initialization since 6b347d5232c7 ("openssl: Ensure underlying hash
algorithm is available during HMAC init").
Tobias Brunner [Tue, 24 Nov 2020 15:50:55 +0000 (16:50 +0100)]
android: Explicitly apply DNS servers to the TUN device
If the peer deletes the CHILD_SA, we recreate it due to the close
action. However, if we create a new TUN device, we do so with a new
VpnService.Builder object and on that the DNS servers were never applied.
The latter happened only on the fly in the attribute handler when an
IKE_SA was established. Now we do this explicitly when creating the TUN
device, like the virtual IPs and routes. While we could avoid the
recreation of the TUN device if the CHILD_SA is recreated, there is the
theoretical possibility that the remote traffic selectors change. This
way we also avoid adding stuff to the builder in different places.
Tobias Brunner [Wed, 27 Jan 2021 13:51:56 +0000 (14:51 +0100)]
swanctl: Don't print status message if nothing was loaded to stderr
This is not an error (as reflected by the returned status code) so we
should not print to stderr as output there might still be considered an
error (or at least an audit-worthy event) by some scripts.
Thomas Egerer [Thu, 28 Jan 2021 17:49:08 +0000 (17:49 +0000)]
plugin-loader: Add optional filter for plugin features
In some cases, the algorithms that have been compiled into a plugin have
to be disabled at runtime. Based on the array returned by the get_features()
function the optionally provided function can strip algorithms or even
callbacks or registrations from a plugin, giving us a handy and powerful way
for runtime feature configuration aside from the plugin list.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>