RAND_pseudo_bytes() allows random data to be returned even in low entropy
conditions. Sometimes this is ok. Many times it is not. For the avoidance
of any doubt, replace existing usage of RAND_pseudo_bytes() with
RAND_bytes().
Reviewed-by: Rich Salz <rsalz@openssl.org>
If a DTLS client that does not support secure renegotiation connects to an
OpenSSL DTLS server then, by default, renegotiation is disabled. If a
server application attempts to initiate a renegotiation then OpenSSL is
supposed to prevent this. However due to a discrepancy between the TLS and
DTLS code, the server sends a HelloRequest anyway in DTLS.
This is not a security concern because the handshake will still fail later
in the process when the client responds with a ClientHello.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit d40ec4ab8e)
There are some missing return value checks in the SCTP code. In master this
was causing a compilation failure when config'd with
"--strict-warnings sctp".
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit d8e8590ed9)
Currently we set change_cipher_spec_ok to 1 before calling
ssl3_get_cert_verify(). This is because this message is optional and if it
is not sent then the next thing we would expect to get is the CCS. However,
although it is optional, we do actually know whether we should be receiving
one in advance. If we have received a client cert then we should expect
a CertificateVerify message. By the time we get to this point we will
already have bombed out if we didn't get a Certificate when we should have
done, so it is safe just to check whether |peer| is NULL or not. If it is
we won't get a CertificateVerify, otherwise we will. Therefore we should
change the logic so that we only attempt to get the CertificateVerify if
we are expecting one, and not allow a CCS in this scenario.
Whilst this is good practice for TLS it is even more important for DTLS.
In DTLS messages can be lost. Therefore we may be in a situation where a
CertificateVerify message does not arrive even though one was sent. In that
case the next message the server will receive will be the CCS. This could
also happen if messages get re-ordered in-flight. In DTLS if
|change_cipher_spec_ok| is not set and a CCS is received it is ignored.
However if |change_cipher_spec_ok| *is* set then a CCS arrival will
immediately move the server into the next epoch. Any messages arriving for
the previous epoch will be ignored. This means that, in this scenario, the
handshake can never complete. The client will attempt to retransmit
missing messages, but the server will ignore them because they are the wrong
epoch. The server meanwhile will still be waiting for the CertificateVerify
which is never going to arrive.
RT#2958
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit a0bd649336)
Ensure all fatal errors transition into the new error state for DTLS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit cefc93910c)
Conflicts:
ssl/d1_srvr.c
Conflicts:
ssl/d1_srvr.c
The certificate already contains the DH parameters in that case.
ssl3_send_server_key_exchange() would fail in that case anyway.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 93f1c13619)
OpenSSL clients would tolerate temporary RSA keys in non-export
ciphersuites. It also had an option SSL_OP_EPHEMERAL_RSA which
enabled this server side. Remove both options as they are a
protocol violation.
Thanks to Karthikeyan Bhargavan for reporting this issue.
(CVE-2015-0204)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 4b4c1fcc88)
Conflicts:
doc/ssl/SSL_CTX_set_options.pod
once the ChangeCipherSpec message is received. Previously, the server would
set the flag once at SSL3_ST_SR_CERT_VRFY and again at SSL3_ST_SR_FINISHED.
This would allow a second CCS to arrive and would corrupt the server state.
(Because the first CCS would latch the correct keys and subsequent CCS
messages would have to be encrypted, a MitM attacker cannot exploit this,
though.)
Thanks to Joeri de Ruiter for reporting this issue.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e94a6c0ede)
Conflicts:
CHANGES
ssl/s3_srvr.c
PR: 2808
With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and
FORWARD-TSN chunks. The key for this extension is derived from the
master secret and changed with the next ChangeCipherSpec, whenever a new
key has been negotiated. The following Finished then already uses the
new key. Unfortunately, the ChangeCipherSpec and Finished are part of
the same flight as the ClientKeyExchange, which is necessary for the
computation of the new secret. Hence, these messages are sent
immediately following each other, leaving the server very little time to
compute the new secret and pass it to SCTP before the finished arrives.
So the Finished is likely to be discarded by SCTP and a retransmission
becomes necessary. To prevent this issue, the Finished of the client is
still sent with the old key.
(cherry picked from commit 9fb523adce)
(cherry picked from commit b9ef52b078)
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
(cherry picked from commit b62f4daac0)
Submitted by: steve@openssl.org
More robust fix and workaround for PR#1949. Don't try to work out if there
is any write pending data as this can be unreliable: always flush.
Submitted by: steve@openssl.org
Fix DTLS connection so new_session is reset if we read second client hello:
new_session is used to detect renegotiation.
