Don't send a warning alert in TLSv1.3

TLSv1.3 ignores the alert level, so we should suppress sending of
warning only alerts.

Fixes #6211

Reviewed-by: Andy Polyakov <app

Don't send a warning alert in TLSv1.3

TLSv1.3 ignores the alert level, so we should suppress sending of
warning only alerts.

Fixes #6211

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6370)

show more ...

Fix TLSv1.3 ticket nonces

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

Fix TLSv1.3 ticket nonces

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)

show more ...

EVP_MD_size() can return an error

Fix some instances where we weren't checking the error return.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/opens

EVP_MD_size() can return an error

Fix some instances where we weren't checking the error return.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6373)

show more ...

Rename EVP_PKEY_new_private_key()/EVP_PKEY_new_public_key()

Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per
feedback.

Reviewed-by: Richard Levitte <lev

Rename EVP_PKEY_new_private_key()/EVP_PKEY_new_public_key()

Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per
feedback.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

show more ...

Add support for setting raw private HMAC keys

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

Only allow supported_versions in a TLSv1.3 ServerHello

As per the latest text in TLSv1.3 draft-26

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/

Only allow supported_versions in a TLSv1.3 ServerHello

As per the latest text in TLSv1.3 draft-26

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5604)

show more ...

Reuse extension_is_relevant() in should_add_extension()

At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtens

Reuse extension_is_relevant() in should_add_extension()

At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtensions,
etc., and sometimes only for a specific protocol or protocol range;
we want to enforce that we only parse or generate extensions in the
context(s) for which they are defined. There is some subtlety here,
in that the protocol version in use is not known when generating the
ClientHello (but it is known when the ClientHello extensions are
being parsed!), so the SSL_IS_TLS13() macro must be used with caution.
Nonetheless, by making assertions about whether we are acting in a
server role and whether the current context is (not) a ClientHello,
we can consolidate almost all of the logic for determining whether
an extension is permitted in a given protocol message, whether we
are generating or parsing that message.

The only logic that remains separate relates to generating the ClientHello,
as it depends on an external factor (the maximum permitted TLS version) that
is not defined in the parsing context.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2945)

show more ...

Tolerate TLSv1.3 PSKs that are a different size to the hash size

We also default to SHA256 as per the spec if we do not have an explicit
digest defined.

Reviewed-by: Rich Salz <

Tolerate TLSv1.3 PSKs that are a different size to the hash size

We also default to SHA256 as per the spec if we do not have an explicit
digest defined.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5554)

show more ...

Fix status_request and SCT extensions

They are valid for use in a CertificateRequest message, but we did not
allow it. If a server sent such a message using either of those two
exten

Fix status_request and SCT extensions

They are valid for use in a CertificateRequest message, but we did not
allow it. If a server sent such a message using either of those two
extensions then the handshake would abort.

This corrects that error, but does not add support for actually processing
the extensions. They are simply ignored, and a TODO is inserted to add
support at a later time.

This was found during interoperability testing with btls:
https://gitlab.com/ilari_l/btls

Prompted by these errors I reviewed the complete list of extensions and
compared them with the latest table in draft-24 to confirm there were no
other errors of a similar type. I did not find any.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5490)

show more ...

If s->ctx is NULL then this is an internal error

Coverity was complaining because we checked if s->ctx is NULL and then
later on in the function deref s->ctx anyway. In reality if s->ctx

If s->ctx is NULL then this is an internal error

Coverity was complaining because we checked if s->ctx is NULL and then
later on in the function deref s->ctx anyway. In reality if s->ctx is
NULL then this is an internal error.

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5334)

show more ...

Ignore an s_client psk in TLSv1.3 if not TLSv1.3 suitable

The s_client psk_use_session_cb callback has a comment stating that we
should ignore a key that isn't suitable for TLSv1.3. Howe

Ignore an s_client psk in TLSv1.3 if not TLSv1.3 suitable

The s_client psk_use_session_cb callback has a comment stating that we
should ignore a key that isn't suitable for TLSv1.3. However we were
actually causing the connection to fail. Changing the return value fixes
the issue.

Also related to this is that the early_data extension was not marked as
TLSv1.3 only which it should be.

Fixes #5202

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5205)

show more ...

Fix some minor code nits

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)

Add TLSv1.3 post-handshake authentication (PHA)

Add SSL_verify_client_post_handshake() for servers to initiate PHA

Add SSL_force_post_handshake_auth() for clients that don't have ce

Add TLSv1.3 post-handshake authentication (PHA)

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)

show more ...

Add support for the TLS 1.3 signature_algorithms_cert extension

The new extension is like signature_algorithms, but only for the
signature *on* the certificate we will present to the pee

Add support for the TLS 1.3 signature_algorithms_cert extension

The new extension is like signature_algorithms, but only for the
signature *on* the certificate we will present to the peer (the
old signature_algorithms extension is still used for signatures that
we *generate*, i.e., those over TLS data structures).

We do not need to generate this extension, since we are the same
implementation as our X.509 stack and can handle the same types
of signatures, but we need to be prepared to receive it, and use the received
information when selecting what certificate to present.

There is a lot of interplay between signature_algorithms_cert and
signature_algorithms, since both affect what certificate we can
use, and thus the resulting signature algorithm used for TLS messages.
So, apply signature_algorithms_cert (if present) as a filter on what
certificates we can consider when choosing a certificate+sigalg
pair.

As part of this addition, we also remove the fallback code that let
keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the
new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled
the key type into what is covered by the signature algorithm, so
we should not apply this sort of compatibility workaround.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)

show more ...

Updates following review of SSL_stateless() code

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4435)

Fix logic around when to send an HRR based on cookies

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4435)

Add support for sending TLSv1.3 cookies

This just adds the various extension functions. More changes will be
required to actually use them.

Reviewed-by: Ben Kaduk <kaduk@mit.edu

Add support for sending TLSv1.3 cookies

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)

show more ...

Update copyright years on all files merged since Jan 1st 2018

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5038)

Permit the "supported_groups" extension in ServerHellos

Although this is forbidden by all three(!) relevant specifications,
there seem to be multiple server implementations in the wild t

Permit the "supported_groups" extension in ServerHellos

Although this is forbidden by all three(!) relevant specifications,
there seem to be multiple server implementations in the wild that
send it. Since we didn't check for unexpected extensions in any
given message type until TLS 1.3 support was added, our previous
behavior was to silently accept these extensions and pass them over
to the custom extension callback (if any). In order to avoid
regression of functionality, relax the check for "extension in
unexpected context" for this specific case, but leave the protocol
enforcment mechanism unchanged for other extensions and in other
extension contexts.

Leave a detailed comment to indicate what is going on.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4463)

show more ...

Remove spaces at end of line in ssl/statem

Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
GH: #4934

Make sure supported_versions appears in an HRR too

Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4701)

Update state machine to send CCS based on whether we did an HRR

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

Update state machine to send CCS based on whether we did an HRR

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)

show more ...

Update ServerHello to new draft-22 format

The new ServerHello format is essentially now the same as the old TLSv1.2
one, but it must additionally include supported_versions. The version

Update ServerHello to new draft-22 format

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)

show more ...

Add some more cleanups

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

Add some more cleanups

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)

show more ...

Fix up a few places in the state machine that got missed with SSLfatal()

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)