The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message
exchange in TLSv1.3. Unfortunately experience has shown that this confuses
some applications who mistake it for a TLSv1.2 renegotiation. This means
that KeyUpdate messages are not handled properly.
This commit removes the use of SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake
message exchange. Individual post-handshake messages are still signalled in
the normal way.
This is a potentially breaking change if there are any applications already
written that expect to see these TLSv1.3 events. However, without it,
KeyUpdate is not currently usable for many applications.
Fixes#8069
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8096)
When computing the end-point shared secret, don't take the
terminating NULL character into account.
Please note that this fix breaks interoperability with older
versions of OpenSSL, which are not fixed.
Fixes#7956
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7957)
Fix some issues in tls13_hkdf_expand() which impact the above function
for TLSv1.3. In particular test that we can use the maximum label length
in TLSv1.3.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7755)
SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0.
If it was called on the client side then it was ignored. In 1.1.1 it now
makes sense to have a CA list defined for both client and server (the
client now sends it the the TLSv1.3 certificate_authorities extension).
Unfortunately some applications were using the same SSL_CTX for both
clients and servers and this resulted in some client ClientHellos being
excessively large due to the number of certificate authorities being sent.
This commit seperates out the CA list updated by
SSL(_CTX)?_set_client_CA_list() and the more generic
SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list()
still has no effect on the client side. If both CA lists are set then
SSL(_CTX)?_set_client_CA_list() takes priority.
Fixes#7411
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7503)
If a client sends data to a server and then immediately closes without
waiting to read the NewSessionTickets then the server can receive EPIPE
when trying to write the tickets and never gets the opportunity to read
the data that was sent. Therefore we ignore EPIPE when writing out the
tickets in TLSv1.3
Fixes#6904
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6944)
At certain points in the handshake we could receive either a plaintext or
an encrypted alert from the client. We should tolerate both where
appropriate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
Under certain error conditions a call to SSLfatal could accidently be
missed.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6872)
If we issue new tickets due to post-handshake authentication there is no
reason to remove previous tickets from the cache. The code that did that
only removed the last session anyway - so if more than one ticket got
issued then those other tickets are still valid.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6722)
During anti-replay we cache the ticket anyway, so there is no point in
using a full stateless ticket.
Fixes#6391
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6563)
Implement support for stateful TLSv1.3 tickets, and use them if
SSL_OP_NO_TICKET is set.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6563)
Separate out as a new function the code to write out data which is specific
to a stateless ticket.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6563)
Sessions should be immutable once they are in the cache because they could
be shared with other threads. If you change them then this can cause
corruptions and races
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6561)
We generate the secrets based on the nonce immediately so there is no
need to keep the nonce.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6415)
All tickets on a connection need to have a unique nonce. When this was
originally implemented we only ever sent one ticket on the conneciton so
this didn't matter. We were just using the value 0. Now we can get multiple
tickets to we need to start doing the ticket nonce properly.
Fixes#6387
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6415)
We send a session ticket automatically in TLSv1.3 at the end of the
handshake. This commit provides the ability to set how many tickets should
be sent. By default this is one.
Fixes#4978
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5227)
Don't call the decrypt ticket callback if we've already encountered a
fatal error. Do call it if we have an empty ticket present.
Change the return code to have 5 distinct returns codes and separate it
from the input status value.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6198)
The return value from the ticket_key callback was not properly handled in
TLSv1.3, so that a ticket was *always* renewed even if the callback
requested that it should not be.
Also the ticket decrypt callback was not being called at all in TLSv1.3.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6198)
The first session ticket sent by the server is actually tacked onto the
end of the first handshake from a state machine perspective. However in
reality this is a post-handshake message, and should be preceeded by a
handshake start event from an info callback perspective.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5874)
We have been unable to trace the contributor of that code to gain their
agreement for the licence change so the code has to be removed.
This commit reverts that contribution. The contribution had no functional
impact so the original way of doing things is still valid. However the
surrounding code has changed significantly so that the exact code as it
was orignally cannot be used. This commit uses the original code as a basis,
but rewrites it to use the PACKET API.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5808)
The alpn_selected value in the session should be NULL before we first
populate it if this is a new session. We assert to make sure it is.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5715)
Place the session ticket AES and HMAC keys into secure memory.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2351)
Since the public and private DRBG are per thread we don't need one
per ssl object anymore. It could also try to get entropy from a DRBG
that's really from an other thread because the SSL object moved to an
other thread.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5547)
We should only update the session cache when we issue a NewSessionTicket.
These are issued automatically after processing a client certificate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5644)
Conceptually in TLSv1.3 there can be multiple sessions associated with a
single connection. Each NewSessionTicket issued can be considered a
separate session. We can end up issuing multiple NewSessionTickets on a
single connection at the moment (e.g. in a post-handshake auth scenario).
Each of those issued tickets should have the new_session_cb called, it
should go into the session cache separately and it should have a unique
id associated with it (so that they can be found individually in the
cache).
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5644)
In TLSv1.3 the session is not ready until after the end of the handshake
when we are constructing the NewSessionTicket.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5621)
Adds application data into the encrypted session ticket
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3802)
Add SSL_verify_client_post_handshake() for servers to initiate PHA
Add SSL_force_post_handshake_auth() for clients that don't have certificates
initially configured, but use a certificate callback.
Update SSL_CTX_set_verify()/SSL_set_verify() mode:
* Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
the initial handshake.
* Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
of when the certificate authentication takes place; either initial handshake,
re-negotiation, or post-handshake authentication.
Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options
Add support to s_client:
* Enabled automatically when cert is configured
* Can be forced enabled via -force_pha
Add support to s_server:
* Use 'c' to invoke PHA in s_server
* Remove some dead code
Update documentation
Update unit tests:
* Illegal use of PHA extension
* TLSv1.3 certificate tests
DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
implemented, it's PHA support state machine may need to be different.
Add a TODO and a #error
Update handshake context to deal with PHA.
The handshake context for TLSv1.3 post-handshake auth is up through the
ClientFinish message, plus the CertificateRequest message. Subsequent
Certificate, CertificateVerify, and Finish messages are based on this
handshake context (not the Certificate message per se, but it's included
after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
Request messages are not included in post-handshake authentication.
After the ClientFinished message is processed, save off the digest state
for future post-handshake authentication. When post-handshake auth occurs,
copy over the saved handshake context into the "main" handshake digest.
This effectively discards the any KeyUpdate or NewSessionTicket messages
and any prior post-handshake authentication.
This, of course, assumes that the ID-22 did not mean to include any
previous post-handshake authentication into the new handshake transcript.
This is implied by section 4.4.1 that lists messages only up to the
first ClientFinished.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
If a server receives an unexpected ClientHello then we may or may not
accept it. Make sure all such decisions are made in the state machine
and not in the record layer. This also removes a disparity between the
TLS and the DTLS code. The TLS code was making this decision in the
record layer, while the DTLS code was making it later.
Finally it also solves a problem where a warning alert was being sent
during tls_setup_handshake() and the function was returning a failure
return code. This is problematic because it can be called from a
transition function - which we only allow fatal errors to occur in.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5190)
This just adds the various extension functions. More changes will be
required to actually use them.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4435)
We'd like the first bit of early_data and the ClientHello to go in the
same TCP packet if at all possible to enable things like TCP Fast Open.
Also, if you're only going to send one block of early data then you also
don't need to worry about TCP_NODELAY.
Fixes#4783
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4802)
Variables n, d, p are no longer there.
[skip ci]
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4894)
Flush following the CCS after an HRR. Only flush the HRR if middlebox
compat is turned off.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4701)
The CCS may be sent at different times based on whether or not we
sent an HRR earlier. In order to make that decision this commit
also updates things to make sure we remember whether an HRR was
used or not.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4701)
The new ServerHello format is essentially now the same as the old TLSv1.2
one, but it must additionally include supported_versions. The version
field is fixed at TLSv1.2, and the version negotiation happens solely via
supported_versions.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4701)
Follow up from the conversion to use SSLfatal() in the state machine to
clean things up a bit more.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
Replace tls1_ec_curve_id2nid() with tls_group_id_lookup() which returns
the TLS_GROUP_INFO for the group.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/=4412)
It is otherwise unclear what all the magic numbers mean.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4349)
"Early callback" is a little ambiguous now that early data exists.
Perhaps "ClientHello callback"?
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4349)
This is actually not all warnings, only return values.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4297)
Commit 02f0274e8c 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)
Give each SSL object it's own DRBG, chained to the parent global
DRBG which is used only as a source of randomness into the per-SSL
DRBG. This is used for all session, ticket, and pre-master secret keys.
It is NOT used for ECDH key generation which use only the global
DRBG. (Doing that without changing the API is tricky, if not impossible.)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4050)
This just adds the processing for sending and receiving the newly added
ticket_nonce field. It doesn't actually use it yet.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3852)
This does things as per the recommendation in the TLSv1.3 spec. It also
means that the server will always choose its preferred ciphersuite.
Previously the server would only select ciphersuites compatible with the
session.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3623)
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)
It is illegal in a TLSv1.3 ClientHello to send anything other than the
NULL compression method. We should send an alert if we find anything else
there. Previously we were ignoring this error.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3410)
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)
The function tls_early_post_process_client_hello() was overwriting the
passed "al" parameter even if it was successful. The caller of that
function, tls_post_process_client_hello(), sets "al" to a sensible default
(HANDSHAKE_FAILURE), but this was being overwritten to be INTERNAL_ERROR.
The result is a "no shared cipher" error (and probably other similar errors)
were being reported back to the client with an incorrect INTERNAL_ERROR
alert.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3314)
There was code existing which attempted to handle the case where application
data is received after a reneg handshake has started in SCTP. In normal DTLS
we just fail the connection if this occurs, so there doesn't seem any reason
to try and work around it for SCTP. In practice it didn't work properly
anyway and is probably a bad idea to start with.
Fixes#3251
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3286)
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)
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)
Choose a new ciphersuite for the HRR. Don't just use the one from the
session.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2895)
Draft-19 changes the HRR transcript hash so that the initial ClientHello
is replaced in the transcript with a special synthetic message_hash message
that just contains a hash of ClientHello1 as its message body.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2895)
The end of early data is now indicated by a new handshake message rather
than an alert.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2895)
If the ticket age calcualtions do not check out then we must not accept
early data (it could be a replay).
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2737)
This adds partial support for TLS 1.3 certificate request message.
The request context and extensions are currently ignored on receive
and set to zero length on send.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2728)
Provide a callback interface that gives the application the ability
to adjust the nascent SSL object at the earliest stage of ClientHello
processing, immediately after extensions have been collected but
before they have been processed.
This is akin to BoringSSL's "select_certificate_cb" (though it is not
API compatible), and as the name indicates, one major use is to examine
the supplied server name indication and select what certificate to
present to the client. However, it can also be used to make more
sweeping configuration changes to the SSL object according to the
selected server identity and configuration. That may include adjusting
the permitted TLS versions, swapping out the SSL_CTX object (as is
traditionally done in a tlsext_servername_callback), changing the
server's cipher list, and more.
We also wish to allow an early callback to indicate that it needs to perform
additional work asynchronously and resume processing later. To that effect,
refactor the second half of tls_process_client_hello() into a subroutine to be
called at the post-processing stage (including the early callback itself), to
allow the callback to result in remaining in the same work stage for a later
call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG
in the SSL object to be preserved across such calls, but the storage is
reclaimed after ClientHello processing finishes.
Information about the CliehtHello is available to the callback by means of
accessor functions that can only be used from the early callback. This allows
extensions to make use of the existing internal parsing machinery without
exposing structure internals (e.g., of PACKET), so that applications do not
have to write fragile parsing code.
Applications are encouraged to utilize an early callback and not use
a servername_callback, in order to avoid unexpected behavior that
occurs due to the relative order of processing between things like
session resumption and the historical servername callback.
Also tidy up nearby style by removing unnecessary braces around one-line
conditional bodies.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
Split off the portions that mutate the SSL object into a separate
function that the state machine calls, so that the public API can
be a pure function. (It still needs the SSL parameter in order
to determine what SSL_METHOD's get_cipher_by_char() routine to use,
though.)
Instead of returning the stack of ciphers (functionality that was
not used internally), require using the output parameter, and add
a separate output parameter for the SCSVs contained in the supplied
octets, if desired. This lets us move to the standard return value
convention. Also make both output stacks optional parameters.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
Move ssl_bytes_to_cipher_list() to ssl_lib.c and create a public
wrapper around it. This lets application early callbacks easily get
SSL_CIPHER objects from the raw ciphers bytes without having to
reimplement the parsing code. In particular, they do not need to
know the details of the sslv2 format ClientHello's ciphersuite
specifications.
Document the new public function, including the arguably buggy behavior
of modifying the supplied SSL object. On the face of it, such a function
should be able to be pure, just a direct translation of wire octets to
internal data structures.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
Now that we have made SCSVs into more of a first-class object, provide
a way for the bytes-to-SSL_CIPHER conversion to actually return them.
Add a flag 'all' to ssl_get_cipher_by_char to indicate that we want
all the known ciphers, not just the ones valid for encryption. This will,
in practice, let the caller retrieve the SCSVs.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
Keep track of the length of the pre_proc_exts array.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2279)
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)
Use negotiated signature algorithm and certificate index in
tls_construct_key_exchange instead of recalculating it.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2623)
Now the certificate and signature algorithm is set in one place we
can use it directly insetad of recalculating it. The old functions
ssl_get_server_send_pkey() and ssl_get_server_cert_index() are no
longer required.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2623)
The original intent of SSL_PKEY_RSA_SIGN and SSL_PKEY_RSA_ENC was to
support two different keys for RSA signing and decrypt. However this
was never implemented and we only ever set one key and the other was
always NULL. Replace with single SSL_PKEY_RSA type.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2587)
session_ctx and initial_ctx are aliases of each other, and with the
opaque data structures, there's no need to keep both around. Since
there were more references of session_ctx, replace all instances of
initial_ctx with session_ctx.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2334)
Make sure the session version consistency check is inside
ssl_get_prev_session(). Also fixes a bug where an inconsistent version can
cause a seg fault in TLSv1.3.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2259)
This mops up various edge cases with key_shares and makes sure we still
generate the handshake secret if we haven't been provided with one but we
have a PSK.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2259)
The record layer was making decisions that should really be left to the
state machine around unexpected handshake messages that are received after
the initial handshake (i.e. renegotiation related messages). This commit
removes that code from the record layer and updates the state machine
accordingly. This simplifies the state machine and paves the way for
handling other messages post-handshake such as the NewSessionTicket in
TLSv1.3.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2259)
The pointer that was freed in the SSLv2 section of ssl_bytes_to_cipher_list
may have stepped up from its allocated position. Use a pointer that is
guaranteed to point at the start of the allocated block instead.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2312)
Well, not as much, at least.
Commit 07afdf3c3a changed things so
that for SSLv2 format ClientHellos we store the cipher list in the
TLS format, i.e., with two bytes per cipher, to be consistent with
historical behavior.
However, the space allocated for the array still performed the computation
with three bytes per cipher, a needless over-allocation (though a relatively
small one, all things considered).
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2281)
SSL_get0_raw_cipherlist() was a little too "raw" in the case of an SSLv2
compat ClientHello. In 1.0.2 and below, during version negotiation, if
we received an SSLv2 compat ClientHello but actually wanted to do SSLv3+
then we would construct a "fake" SSLv3+ ClientHello. This "fake" ClientHello
would have its ciphersuite list converted to the SSLv3+ format. It was
this "fake" raw list that got saved away to later be returned by a call to
SSL_get0_raw_cipherlist().
In 1.1.0+ version negotiation works differently and we process an SSLv2
compat ClientHello directly without the need for an intermediary "fake"
ClientHello. This meant that the raw ciphersuite list being saved was in
the SSLv2 format. Any caller of this function would not expect that and
potentially overread the returned buffer by one byte.
Fixes#2189
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2280)
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows:
B<Server mode:> only request a client certificate on the initial TLS/SSL
handshake. Do not ask for a client certificate again in case of a
renegotiation. This flag must be used together with SSL_VERIFY_PEER.
B<Client mode:> ignored
But the implementation actually did nothing. After the server sends its
ServerKeyExchange message, the code was checking s->session->peer to see if
it is NULL. If it was set then it did not ask for another client
certificate. However s->session->peer will only be set in the event of a
resumption, but a ServerKeyExchange message is only sent in the event of a
full handshake (i.e. no resumption).
The documentation suggests that the original intention was for this to
have an effect on renegotiation, and resumption doesn't come into it.
The fix is to properly check for renegotiation, not whether there is already
a client certificate in the session.
As far as I can tell this has been broken for a *long* time.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1982)
Paul Monson
Richard Levitte
Matt Caswell
Michael Tuexen
Mansour Ahmadi
Kurt Roeckx
Rich Salz
Todd Short
Pauli
Paul Yang
Dr. Stephen Henson
David Benjamin
Andy Polyakov
Benjamin Kaduk
Tatsuhiro Tsujikawa
FdaSilvaYY