If an application calls SSL_shutdown after a fatal alert has occured and
then behaves different based on error codes from that function then the
application may be vulnerable to a padding oracle.
CVE-2019-1559
Reviewed-by: Richard Levitte <levitte@openssl.org>
If the private key says it can only support one specific digest, then
don't ask it to perform a different one.
Fixes: #7348
(cherry picked from commit 2d263a4a73f852005b16359873475d48755999ad
and reworked for 1.0.2)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7610)
Since 3884b47b7c we may attempt to buffer a record from the next epoch
that has already been buffered. Prior to that this never occurred.
We simply ignore a failure to buffer a duplicated record.
Fixes#6902
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7415)
We should validate that the various fields we put into the
CertificateRequest are not too long. Otherwise we will construct an
invalid message.
Fixes#6609
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6629)
In DTLS if we have buffered a fragment for a zero length message (e.g.
ServerHelloDone) then, when we unbuffered the fragment, we were attempting
to memcpy the contents of the fragment which is zero length and a NULL
pointer. This is undefined behaviour. We should check first whether we
have a zero length fragment.
Fixes a travis issue.
[extended tests]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6225)
The ciphers field in a session contains the stack of ciphers offered by
the client.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6115)
The function SSL_get_shared_ciphers() is supposed to return ciphers shared
by the client and the server. However it only ever returned the client
ciphers.
Fixes#5317
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6115)
This patch fixes the following warning when OpenSSL is configured with
no-dh and no-ec:
./Configure no-ec no-dh linux-x86_64
...
s3_lib.c: In function 'ssl3_get_req_cert_type':
s3_lib.c:4234:19: warning: variable 'alg_k' set but not used [-Wunused-but-set-variable]
unsigned long alg_k;
CLA: trivial
Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6087)
This patch fixes the following warning when OpenSSL is configured with
no-dh and no-ec:
./Configure no-ec no-dh linux-x86_64
...
s3_lib.c:4231:9: warning: variable 'nostrict' set but not used [-Wunused-but-set-variable]
int nostrict = 1;
^
CLA: trivial
Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6087)
We were sending illegal parameter. This isn't correct. The parameters are
legal, we just don't have an overlap. A more appropriate alert is
handshake failure.
Fixes#2919
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6011)
We cannot provide a certificate status on a resumption so we should
ignore this extension in that case.
Fixes#1662
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5898)
99bb59d at ssl_scan_clienthello_tlsext
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5507)
Before reading first byte as length
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5410)
This could in theory result in an overread - but due to the over allocation
of the underlying buffer does not represent a security issue.
Thanks to Fedor Indutny for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5417)
In TLS we have a check to make sure an incoming reneg ClientHello is
acceptable. The equivalent check is missing in the DTLS code. This means
that if a client does not signal the ability to handle secure reneg in the
initial handshake, then a subsequent reneg handshake should be rejected by
the server. In the DTLS case the reneg was being allowed if the the 2nd
ClientHello had a renegotiation_info extension. This is incorrect.
While incorrect, this does not represent a security issue because if
the renegotiation_info extension is present in the second ClientHello it
also has to be *correct*. Therefore this will only work if both the client
and server believe they are renegotiating, and both know the previous
Finished result. This is not the case in an insecure rengotiation attack.
I have also tidied up the check in the TLS code and given a better check
for determining whether we are renegotiating or not.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5192)
Updated uses of gmtime to now call OPENSSL_gmtime instead.
Used similar preprocessor logic to make sure localtime_r is called instead
of localtime when applicable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3609)
In the case of a protocol version alert being sent by a peer the record
version number may not be what we are expecting. In DTLS records with an
unexpected version number are silently discarded. This probably isn't
appropriate for alerts, so we tolerate a mismatch in the minor version
number.
This resolves an issue reported on openssl-users where an OpenSSL server
chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version
alert with a 1.2 record number. This was silently ignored by the server.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5019)
SSL_trace() has a case which was inadvertently falling through.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4888)
(cherry picked from commit 5bfb357a0d2046fc75daf67a5bc019eb87443729)
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake
then OpenSSL would move into the error state and would immediately fail if
you attempted to continue the handshake. This works as designed for the
explicit handshake functions (SSL_do_handshake(), SSL_accept() and
SSL_connect()), however due to a bug it does not work correctly if
SSL_read() or SSL_write() is called directly. In that scenario, if the
handshake fails then a fatal error will be returned in the initial function
call. If SSL_read()/SSL_write() is subsequently called by the application
for the same SSL object then it will succeed and the data is passed without
being decrypted/encrypted directly from the SSL/TLS record layer.
In order to exploit this issue an attacker would have to trick an
application into behaving incorrectly by issuing an SSL_read()/SSL_write()
after having already received a fatal error.
Thanks to David Benjamin (Google) for reporting this issue and suggesting
this fix.
CVE-2017-3737
Reviewed-by: Rich Salz <rsalz@openssl.org>
It's argued that /WX allows to keep better focus on new code, which
motivates its comeback...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4718)
cb_ticket2() does an exit, and should therefore not need to return anything.
Some compilers don't detect that, or don't care, and warn about a non-void
function without a return statement.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4713)
1ce95f19601bbc6bfd24092c76c8f8105124e857 was incomplete and did not
handle the case when SSL_set_SSL_CTX was called from the cert_cb
callback rather than the SNI callback. The consequence is any server
using OpenSSL 1.0.2 and the cert_cb callback for SNI only ever signs a
weak digest, SHA-1, even when connecting to clients which use secure
ones.
Fix this and add regression tests for both this and the original issue.
Fixes#4554.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4577)
Code was added in commit 62f488d that overwrite the last ex_data valye
using CRYPTO_dup_ex_data() causing a memory leak and potentially
confusing the ex_data dup() callback.
In ssl_session_dup(), new-up the ex_data before calling
CRYPTO_dup_ex_data(); all the other structures that dup ex_data have
the destination ex_data new'd before the dup.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3568)
The check for SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is
inconsistent. Most places check SSL->options, one place is checking
SSL_CTX->options; fix that.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
GH: #3521
Fixes make test when configured with no-comp.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3545)
The function SSL_set_SSL_CTX() can be used to swap the SSL_CTX used for
a connection as part of an SNI callback. One result of this is that the
s->cert structure is replaced. However this structure contains information
about any custom extensions that have been loaded. In particular flags are
set indicating whether a particular extension has been received in the
ClientHello. By replacing the s->cert structure we lose the custom
extension flag values, and it appears as if a client has not sent those
extensions.
SSL_set_SSL_CTX() should copy any flags for custom extensions that appear
in both the old and the new cert structure.
Fixes#2180
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3427)
