Remove all the functions and dead code that is now no longer required as
a result of the DTLS client move into the new state machine code.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Move all DTLS client side processing into the new state machine code. A
subsequent commit will clean up the old dead code.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
A DTLS client will abort a handshake if the server attempts to renew the
session ticket. This is caused by a state machine discrepancy between DTLS
and TLS discovered during the state machine rewrite work.
The bug can be demonstrated as follows:
Start a DTLS s_server instance:
openssl s_server -dtls
Start a client and obtain a session but no ticket:
openssl s_client -dtls -sess_out session.pem -no_ticket
Now start a client reusing the session, but allow a ticket:
openssl s_client -dtls -sess_in session.pem
The client will abort the handshake.
Reviewed-by: Tim Hudson <tjh@openssl.org>
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>
Continuing on from the previous commit this moves the processing of DTLS
CCS messages out of the record layer and into the state machine.
Reviewed-by: Tim Hudson <tjh@openssl.org>
This flag was not set anywhere within the codebase (only read). It could
only be set by an app reaching directly into s->s3->flags and setting it
directly. However that method became impossible when libssl was opaquified.
Even in 1.0.2/1.0.1 if an app set the flag directly it is only relevant to
ssl3_connect(), which calls SSL_clear() during initialisation that clears
any flag settings. Therefore it could take effect if the app set the flag
after the handshake has started but before it completed. It seems quite
unlikely that any apps really do this (especially as it is completely
undocumented).
The purpose of the flag is suppress flushing of the write bio on the client
side at the end of the handshake after the client has written the Finished
message whilst resuming a session. This enables the client to send
application data as part of the same flight as the Finished message.
This flag also controls the setting of a second flag SSL3_FLAGS_POP_BUFFER.
There is an interesting comment in the code about this second flag in the
implementation of ssl3_write:
/* This is an experimental flag that sends the
* last handshake message in the same packet as the first
* use data - used to see if it helps the TCP protocol during
* session-id reuse */
It seems the experiment did not work because as far as I can tell nothing
is using this code. The above comment has been in the code since SSLeay.
This commit removes support for SSL3_FLAGS_DELAY_CLIENT_FINISHED, as well
as the associated SSL3_FLAGS_POP_BUFFER.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Given the pervasive nature of TLS extensions it is inadvisable to run
OpenSSL without support for them. It also means that maintaining
the OPENSSL_NO_TLSEXT option within the code is very invasive (and probably
not well tested). Therefore it is being removed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Remove RFC2712 Kerberos support from libssl. This code and the associated
standard is no longer considered fit-for-purpose.
Reviewed-by: Rich Salz <rsalz@openssl.org>
After the finale, the "real" final part. :) Do a recursive grep with
"-B1 -w [a-zA-Z0-9_]*_free" to see if any of the preceeding lines are
an "if NULL" check that can be removed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Ensure that all functions have their return values checked where
appropriate. This covers all functions defined and called from within
libssl.
Reviewed-by: Richard Levitte <levitte@openssl.org>
I left many "#if 0" lines, usually because I thought we would
probably want to revisit them later, or because they provided
some useful internal documentation tips.
Reviewed-by: Andy Polyakov <appro@openssl.org>
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>
The client sends a session ID with the session ticket, and uses
the returned ID to detect resumption, so we do not need to peek
at handshake messages: s->hit tells us explicitly if we're resuming.
An equivalent change was independently made in BoringSSL, see commit
407886f589cf2dbaed82db0a44173036c3bc3317.
Reviewed-by: Matt Caswell <matt@openssl.org>
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)
Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.
As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.
Add correct flags for DTLS 1.2, update s_server and s_client to handle
DTLS 1.2 methods.
Currently no support for version negotiation: i.e. if client/server selects
DTLS 1.2 it is that or nothing.
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.
certificate chain instead of an X509 structure.
This makes it easier to enhance code in future and the chain
output functions have access to the CERT_PKEY structure being
used.
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.
This change resolves a number of problems and obviates multiple kludges.
A new feature is that you can now say "AES256" or "AES128" (not just
"AES", which enables both).
In some cases the ciphersuite list generated from a given string is
affected by this change. I hope this is just in those cases where the
previous behaviour did not make sense.
