Commit 02f0274e8c0596dcf7e2d104250232a42c650b96 moved ALPN processing
into an extension finalization function, as the only documented ordering
requirement from previous commits was that ALPN processing occur after
SNI processing, and SNI processing is performed before the extension
finalization step. However, it is useful for applications'
alpn_select callbacks to run after ciphersuite selection as well -- at
least one application protocol specification (HTTP/2) imposes restrictions
on which ciphersuites are usable with that protocol. Since it is generally
more preferrable to have a successful TLS connection with a default application
protocol than to fail the TLS connection and not be able to have the preferred
application protocol, it is good to give the alpn_select callback information
about the ciphersuite to be used, so that appropriate restrctions can be
enforced in application code.
Accordingly, split the ALPN handling out into a separate tls_handl_alpn()
function akin to tls_handle_status_request(), called from
tls_post_process_client_hello(). This is an alternative to resuscitating
ssl_check_clienthello_tlsext_late(), something of an awkwward name itself.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4070)
Some extensions were being displayed twice, before they were parsed, and
again after they were parsed.
The supported_versions extension was not being fully displayed, as it
was processed differently than other extensions.
Move the debug callback to where the extensions are first collected, to
catch all the extensions as they come in, so they are ordered correctly.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3911)
TLSv1.3 draft-21 requires the ticket nonce to be at least 1 byte in length.
However NSS sends a zero length nonce. This is actually ok because the next
draft will allow zero length nonces anyway, so we should tolerate this.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3957)
In most scenarios the length of the input data is the hashsize, or 0 if
the data is NULL. However with the new ticket_nonce changes the length can
be different.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3852)
It is an API to be used from the early callback that indicates what
extensions were present in the ClientHello, and in what order.
This can be used to eliminate unneeded calls to SSL_early_get0_ext()
(which itself scales linearly in the number of extensions supported
by the library).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2976)
Signed-off-by: Paul Yang <paulyang.inf@gmail.com>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3622)
We are quite inconsistent about which alerts get sent. Specifically, these
alerts should be used (normally) in the following circumstances:
SSL_AD_DECODE_ERROR = The peer sent a syntactically incorrect message
SSL_AD_ILLEGAL_PARAMETER = The peer sent a message which was syntactically
correct, but a parameter given is invalid for the context
SSL_AD_HANDSHAKE_FAILURE = The peer's messages were syntactically and
semantically correct, but the parameters provided were unacceptable to us
(e.g. because we do not support the requested parameters)
SSL_AD_INTERNAL_ERROR = We messed up (e.g. malloc failure)
The standards themselves aren't always consistent but I think the above
represents the best interpretation.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3480)
The current TLSv1.3 spec says:
'If a server is authenticating via a certificate and the client has not
sent a "signature_algorithms" extension, then the server MUST abort the
handshake with a "missing_extension" alert (see Section 8.2).'
If we are resuming then we are not "authenticating via a certificate" but
we were still aborting with the missing_extension alert if sig algs was
missing.
This commit ensures that we only send the alert if we are not resuming.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3478)
We already did this on an ad-hoc per extension basis (for some extensions).
This centralises it and makes sure we do it for all extensions.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3418)
The TLSv1.3 spec says that a server SHOULD send supported_groups in the
EE message if there is a group that it prefers to the one used in the
key_share. Clients MAY act on that. At the moment we don't do anything
with it on the client side, but that may change in the future.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3395)
Previously, init and finalization function for extensions are called
per extension block, rather than per message. This commit changes
that behaviour, and now they are called per message. The parse
function is still called per extension block.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3244)
Ensure that there are ciphersuites enabled for the maximum supported
version we will accept in a ClientHello.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3316)
RFC 7301 mandates that the server SHALL respond with a fatal
"no_application_protocol" alert when there is no overlap between
the client's supplied list and the server's list of supported protocols.
In commit 062178678f5374b09f00d70796f6e692e8775aca we changed from
ignoring non-success returns from the supplied alpn_select_cb() to
treating such non-success returns as indicative of non-overlap and
sending the fatal alert.
In effect, this is using the presence of an alpn_select_cb() as a proxy
to attempt to determine whether the application has configured a list
of supported protocols. However, there may be cases in which an
application's architecture leads it to supply an alpn_select_cb() but
have that callback be configured to take no action on connections that
do not have ALPN configured; returning SSL_TLSEXT_ERR_NOACK from
the callback would be the natural way to do so. Unfortunately, the
aforementioned behavior change also treated SSL_TLSEXT_ERR_NOACK as
indicative of no overlap and terminated the connection; this change
supplies special handling for SSL_TLSEXT_ERR_NOACK returns from the
callback. In effect, it provides a way for a callback to obtain the
behavior that would have occurred if no callback was registered at
all, which was not possible prior to this change.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2570)
The old custom extensions API was not TLSv1.3 aware. Extensions are used
extensively in TLSv1.3 and they can appear in many different types of
messages. Therefore we need a new API to be able to cope with that.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3139)
This move prepares for the later addition of the new custom extensions
API. The context codes have an additional "SSL_" added to their name to
ensure we don't have name clashes with other applications.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3139)
Add functions to add/retrieve the certificate_authorities. The older
client_CA functions mainly just call the new versions now.
Rename fields sice new extension can be generated by client and server.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3015)
Fix some comments too
[skip ci]
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3069)
Commit 6b1bb98fa moved the processing of ClientHello extensions into the
state machine post-processing stage. After processing s->init_num is reset
to 0, so by post-processing we cannot rely on its value. Unfortunately we
were using it to handle the PSK extension. This causes the handshake to
fail.
We were using init_num to figure out the length of ClientHello2 so we can
remove it from the handshake_buffer. The handshake_buffer holds the
transcript of all the messages sent so far. For PSK processing though we
only want to add in a partial ClientHello2. This commit changes things so
we just work out where ClientHello2 starts, working forward from the
beginning of handshake_buffer.
Fixes#2983
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2996)
In OpenSSL 1.1.0 the padding extension MUST be last because it calculates
the length of everything that has been written into the ClientHello to
determine whether it needs to be padded or not. With TLSv1.3 that isn't
possible because the specification requires that the PSK extension is last.
Therefore we need to fix the padding extension to take account of any PSK
extension that will be later added.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2968)
Zero out the length alongside the NULLing of the pointer, to
bring parity between the selected and proposed fields..
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2954)
If early data is sent to a server, but ALPN is not used then memcmp is
called with a NULL pointer which is undefined behaviour.
Fixes#2841
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2845)
We do not allow the generation of TLSv1.3 cookies. But if we receive one
in an HRR we will echo it back in the ClientHello.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2839)
We also skip any early_data that subsequently gets sent. Later commits will
process it if we can.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2737)
Modify the API of tls_collect_extensions() to be able to output the number of
extensions that are known (i.e., the length of its 'res' output). This number
can never be zero on a successful return due to the builtin extensions list,
but use a separate output variable so as to not overload the return value
semantics.
Having this value easily available will give consumers a way to avoid repeating
the calculation.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
In 1.1.0 changing the ciphersuite during a renegotiation can result in
a crash leading to a DoS attack. In master this does not occur with TLS
(instead you get an internal error, which is still wrong but not a security
issue) - but the problem still exists in the DTLS code.
The problem is caused by changing the flag indicating whether to use ETM
or not immediately on negotiation of ETM, rather than at CCS. Therefore,
during a renegotiation, if the ETM state is changing (usually due to a
change of ciphersuite), then an error/crash will occur.
Due to the fact that there are separate CCS messages for read and write
we actually now need two flags to determine whether to use ETM or not.
CVE-2017-3733
Reviewed-by: Richard Levitte <levitte@openssl.org>
