We can end up with a NULL SSL_METHOD function if a method has been
disabled. If that happens then we shouldn't call vent->smeth().
Reviewed-by: Rich Salz <rsalz@openssl.org>
Nothing is using this yet, it just adds the underlying functions necesary
for generating the TLS1.3 secrets.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Normally WPACKETs will use a BUF_MEM which can grow as required. Sometimes
though that may be overkill for what is needed - a static buffer may be
sufficient. This adds that capability.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There were a few places where they could be declared const so this commit
does that.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The name and type of the argument to ssl_check_for_safari() has changed.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The size if fixed by the protocol and won't change even if
sizeof(clienthello.random) does.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Add a blank line, take one away - due to feedback received during review.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
We should be freeing up the raw extension data after we've finished with it.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
In the case of an SSLv2 compat ClientHello we weren't setting up the
compression methods correctly, which could lead to uninit reads or crashes.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
This partially reverts commit c636c1c47. It also tweaks the documentation
and comments in this area. On the client side the documented interface for
SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag
SSL_VERIFY_PEER causes verfication of the server certificate to take place.
Previously what was implemented was that if *any* flag was set then
verification would take place. The above commit improved the semantics to
be as per the documented interface.
However, we have had a report of at least one application where an
application was incorrectly using the interface and used *only*
SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to
the above commit this still caused verification of the server certificate
to take place. After this commit the application silently failed to verify
the server certificate.
Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate
if invalid flags were being used. However these are void functions!
The simplest short term solution is to revert to the previous behaviour
which at least means we "fail closed" rather than "fail open".
Thanks to Cory Benfield for reporting this issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We read it later in grow_init_buf(). If CCS is the first thing received in
a flight, then it will use the init_msg from the last flight we received. If
the init_buf has been grown in the meantime then it will point to some
arbitrary other memory location. This is likely to result in grow_init_buf()
attempting to grow to some excessively large amount which is likely to
fail. In practice this should never happen because the only time we receive
a CCS as the first thing in a flight is in an abbreviated handshake. None
of the preceding messages from the server flight would be large enough to
trigger this.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Travis is reporting one file at a time shadowed variable warnings where
"read" has been used. This attempts to go through all of libssl and replace
"read" with "readbytes" to fix all the problems in one go.
Reviewed-by: Rich Salz <rsalz@openssl.org>
We also modify the SSL_get_error() function to handle the fact that with
SSL_write_ex() the error return is 0 not -1, and fix some bugs in the
SSL BIO reading.
Reviewed-by: Rich Salz <rsalz@openssl.org>
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but
TLS 1.2 says you MUST send an unexpected message alert. We swap to the
TLS 1.2 behaviour for all protocol versions to prevent issues where no
progress is being made and the peer continually sends unrecognised record
types, using up resources processing them.
Issue reported by 郭志攀
Reviewed-by: Tim Hudson <tjh@openssl.org>
The function ssl3_read_n() takes a parameter |clearold| which, if set,
causes any old data in the read buffer to be forgotten, and any unread data
to be moved to the start of the buffer. This is supposed to happen when we
first read the record header.
However, the data move was only taking place if there was not already
sufficient data in the buffer to satisfy the request. If read_ahead is set
then the record header could be in the buffer already from when we read the
preceding record. So with read_ahead we can get into a situation where even
though |clearold| is set, the data does not get moved to the start of the
read buffer when we read the record header. This means there is insufficient
room in the read buffer to consume the rest of the record body, resulting in
an internal error.
This commit moves the |clearold| processing to earlier in ssl3_read_n()
to ensure that it always takes place.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We add ssl_cipher_get_overhead() as an internal function, to avoid
having too much ciphersuite-specific knowledge in DTLS_get_data_mtu()
itself. It's going to need adjustment for TLSv1.3... but then again, so
is fairly much *all* of the SSL_CIPHER handling. This bit is in the noise.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
When matching a ciphersuite if we are given an id, make sure we use it
otherwise we will match another ciphersuite which is identical except for
the TLS version.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Includes addition of the various options to s_server/s_client. Also adds
one of the new TLS1.3 ciphersuites.
This isn't "real" TLS1.3!! It's identical to TLS1.2 apart from the protocol
and the ciphersuite...and the ciphersuite is just a renamed TLS1.2 one (not
a "real" TLS1.3 ciphersuite).
Reviewed-by: Rich Salz <rsalz@openssl.org>
For convenience, combine getting a new ref for the new SSL_CTX
with assigning the store and freeing the old one.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1755)
A zero return from BIO_read()/BIO_write() could mean that an IO operation
is retryable. A zero return from SSL_read()/SSL_write() means that the
connection has been closed down (either cleanly or not). Therefore we
should not propagate a zero return value from BIO_read()/BIO_write() back
up the stack to SSL_read()/SSL_write(). This could result in a retryable
failure being treated as fatal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
OpenSSL 1.1.0 will negotiate EtM on DTLS but will then not actually *do* it.
If we use DTLSv1.2 that will hopefully be harmless since we'll tend to use
an AEAD ciphersuite anyway. But if we're using DTLSv1, then we certainly
will end up using CBC, so EtM is relevant — and we fail to interoperate with
anything that implements EtM correctly.
Fixing it in HEAD and 1.1.0c will mean that 1.1.0[ab] are incompatible with
1.1.0c+... for the limited case of non-AEAD ciphers, where they're *already*
incompatible with other implementations due to this bug anyway. That seems
reasonable enough, so let's do it. The only alternative is just to turn it
off for ever... which *still* leaves 1.0.0[ab] failing to communicate with
non-OpenSSL implementations anyway.
Tested against itself as well as against GnuTLS both with and without EtM.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
The prevailing style seems to not have trailing whitespace, but a few
lines do. This is mostly in the perlasm files, but a few C files got
them after the reformat. This is the result of:
find . -name '*.pl' | xargs sed -E -i '' -e 's/( |'$'\t'')*$//'
find . -name '*.c' | xargs sed -E -i '' -e 's/( |'$'\t'')*$//'
find . -name '*.h' | xargs sed -E -i '' -e 's/( |'$'\t'')*$//'
Then bn_prime.h was excluded since this is a generated file.
Note mkerr.pl has some changes in a heredoc for some help output, but
other lines there lack trailing whitespace too.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
We now set the handshake header, and close the packet directly in the
write_state_machine. This is now possible because it is common for all
messages.
Reviewed-by: Rich Salz <rsalz@openssl.org>
tls_construct_finished() used to have different arguments to all of the
other construction functions. It doesn't anymore, so there is no neeed to
treat it as a special case.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Ensure all message types work the same way including CCS so that the state
machine doesn't need to know about special cases. Put all the special logic
into ssl_set_handshake_header() and ssl_close_construct_packet().
Reviewed-by: Rich Salz <rsalz@openssl.org>
Instead of initialising, finishing and cleaning up the WPACKET in every
message construction function, we should do it once in
write_state_machine().
Reviewed-by: Rich Salz <rsalz@openssl.org>
ssl_set_handshake_header2() was only ever a temporary name while we had
to have ssl_set_handshake_header() for code that hadn't been converted to
WPACKET yet. No code remains that needed that so we can rename it.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Remove the old ssl_set_handshake_header() implementations. Later we will
rename ssl_set_handshake_header2() to ssl_set_handshake_header().
Reviewed-by: Rich Salz <rsalz@openssl.org>
In plain PSK we don't need to do anymore construction after the preamble.
We weren't detecting this case and treating it as an unknown cipher.
Reviewed-by: Rich Salz <rsalz@openssl.org>
WPACKET_allocate_bytes() requires you to know the size of the data you
are allocating for, before you create it. Sometimes this isn't the case,
for example we know the maximum size that a signature will be before we
create it, but not the actual size. WPACKET_reserve_bytes() enables us to
reserve bytes in the WPACKET, but not count them as written yet. We then
subsequently need to acall WPACKET_allocate_bytes to actually count them as
written.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This was a temporary function needed during the conversion to WPACKET. All
callers have now been converted to the new way of doing this so this
function is no longer required.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Some functions were being called from both code that used WPACKETs and code
that did not. Now that more code has been converted to use WPACKETs some of
that duplication can be removed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If we have a handshake fragment waiting then dtls1_read_bytes() was not
correctly setting the value of recvd_type, leading to an uninit read.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The buffer to receive messages is initialised to 16k. If a message is
received that is larger than that then the buffer is "realloc'd". This can
cause the location of the underlying buffer to change. Anything that is
referring to the old location will be referring to free'd data. In the
recent commit c1ef7c97 (master) and 4b390b6c (1.1.0) the point in the code
where the message buffer is grown was changed. However s->init_msg was not
updated to point at the new location.
CVE-2016-6309
Reviewed-by: Emilia Käsper <emilia@openssl.org>
If we request more bytes to be allocated than double what we have already
written, then we grow the buffer by the wrong amount.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
We actually construct a HelloVerifyRequest in two places with common code
pulled into a single function. This one commit handles both places.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If the underlying BUF_MEM gets realloc'd then the pointer returned could
become invalid. Therefore we should always ensure that the allocated
memory is filled in prior to any more WPACKET_* calls.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Russian GOST ciphersuites are vulnerable to the KCI attack because they use
long-term keys to establish the connection when ssl client authorization is
on. This change brings the GOST implementation into line with the latest
specs in order to avoid the attack. It should not break backwards
compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
If while calling SSL_peek() we read an empty record then we go into an
infinite loop, continually trying to read data from the empty record and
never making any progress. This could be exploited by a malicious peer in
a Denial Of Service attack.
CVE-2016-6305
GitHub Issue #1563
Reviewed-by: Rich Salz <rsalz@openssl.org>
If a server sent multiple NPN extensions in a single ClientHello then a
mem leak can occur. This will only happen where the client has requested
NPN in the first place. It does not occur during renegotiation. Therefore
the maximum that could be leaked in a single connection with a malicious
server is 64k (the maximum size of the ServerHello extensions section). As
this is client side, only occurs if NPN has been requested and does not
occur during renegotiation this is unlikely to be exploitable.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
A malicious client can send an excessively large OCSP Status Request
extension. If that client continually requests renegotiation,
sending a large OCSP Status Request extension each time, then there will
be unbounded memory growth on the server. This will eventually lead to a
Denial Of Service attack through memory exhaustion. Servers with a
default configuration are vulnerable even if they do not support OCSP.
Builds using the "no-ocsp" build time option are not affected.
I have also checked other extensions to see if they suffer from a similar
problem but I could not find any other issues.
CVE-2016-6304
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This issue is very similar to CVE-2016-6307 described in the previous
commit. The underlying defect is different but the security analysis and
impacts are the same except that it impacts DTLS.
A DTLS message includes 3 bytes for its length in the header for the
message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect TLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-6308
Reviewed-by: Richard Levitte <levitte@openssl.org>
A TLS message includes 3 bytes for its length in the header for the message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:
1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
or
2) The application is working in a constrained environment where there
is very little free memory
or
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.
Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.
This issue does not affect DTLS users.
Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
CVE-2016-6307
Reviewed-by: Richard Levitte <levitte@openssl.org>
Certain warning alerts are ignored if they are received. This can mean that
no progress will be made if one peer continually sends those warning alerts.
Implement a count so that we abort the connection if we receive too many.
Issue reported by Shi Lei.
Reviewed-by: Rich Salz <rsalz@openssl.org>
All the other functions that take an argument for the number of bytes
use convenience macros for this purpose. We should do the same with
WPACKET_put_bytes().
Reviewed-by: Rich Salz <rsalz@openssl.org>
Makes the logic a little bit clearer.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1571)
This reverts commit 77a6be4dfc.
There were some unexpected side effects to this commit, e.g. in SSLv3 a
warning alert gets sent "no_certificate" if a client does not send a
Certificate during Client Auth. With the above commit this causes the
connection to abort, which is incorrect. There may be some other edge cases
like this so we need to have a rethink on this.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Updated the construction code to use the new function. Also added some
convenience macros for WPACKET_sub_memcpy().
Reviewed-by: Rich Salz <rsalz@openssl.org>
A peer continually sending unrecognised warning alerts could mean that we
make no progress on a connection. We should abort rather than continuing if
we receive an unrecognised warning alert.
Thanks to Shi Lei for reporting this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This is an internal API. Some of the tests were for programmer erorr and
"should not happen" situations, so a soft assert is reasonable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
A few style tweaks here and there. The main change is that curr and
packet_len are now offsets into the buffer to account for the fact that
the pointers can change if the buffer grows. Also dropped support for the
WPACKET_set_packet_len() function. I thought that was going to be needed
but so far it hasn't been. It doesn't really work any more due to the
offsets change.
Reviewed-by: Rich Salz <rsalz@openssl.org>
