Age | Commit message (Collapse) | Author |
|
protect from future field reordering/removal.
No difference in generated assembly.
|
|
|
|
|
|
using EVP_AEAD. Also provide an EVP_AEAD-only equivalent of
ssl_cipher_get_evp().
|
|
magic numbers around.
ok deraadt@
|
|
do some other clean up while here.
ok deraadt@
|
|
check, so do not duplicate it here. Make the error handling consistent
by always using 'goto err' rather than returning in certain cases. Also
add a missing BIO_free(ssl) in BIO_new_ssl_connect().
ok deraadt@
|
|
|
|
discussed with tedu, ok jsing
|
|
switching cipher states using an EVP_CIPHER. This will facilitate the
addition of cipher state changes for EVP_AEAD. No functional change.
Based on Adam Langley's chromium patches.
|
|
|
|
c30718b5e7480add42598158
Don't know the full story, but it looks like a "can't do random
perfectly, so do it god awful" problem was found in 2013, and
replaced with "only do it badly if a flag is set". New flags
(SSL_MODE_SEND_SERVERHELLO_TIME and SSL_MODE_SEND_SERVERHELLO_TIME)
were added [Ben Laurie?] to support the old scheme of "use time_t
for first 4 bytes of the random buffer".
Nothing uses these flags [ecosystem scan by sthen]
Fully discourage use of these flags in the future by removing
support & definition of them. The buflen < 4 check is also interesting,
because no entropy would be returned. No callers passed such small
buffers.
ok miod sthen
|
|
Based on Adam Langley's chromium patches.
|
|
While this is not strictly correct (since the presence of SSL3_CC_READ does
not guarantee the absence of SSL3_CC_WRITE), in practice only one of these
flags is set at a time and there is existing logic which already relies on
this behaviour.
|
|
this is the only place where these variables are used.
|
|
|
|
code. Additionally, these need to be cleaned in the export case.
Based on Adam Langley's chromium patches.
|
|
Rather than doing a complex dance to figure out if we should reuse the
cipher context and clean it later on, just free it and allocate a new one.
This simplifies the code path, especially in the write case where special
handling is required for DTLS.
Also, calling EVP_CIPHER_CTX_init() for a newly created cipher context is
unnecessary, since EVP_CIPHER_CTX_new() already does this (not to mention
that it was already missing from the write case).
|
|
and others to the regress framework. These remaining ones just
muddle us up when re-reading code repeatedly.
ok jsing
|
|
|
|
ok miod
|
|
|
|
|
|
before calling it.
|
|
so do not bother checking before calling.
|
|
implicit NULL checks, so there is no point ensuring that the pointer is
non-NULL before calling them.
|
|
|
|
|
|
hackathon, just saying 'ass ember' was enough to start giggles.
Unfortunately far more offensive stuff remains in here...
|
|
DTLS fragments. A stream of 'Hello Request' messages will result in
infinite recursion, eventually crashing the DTLS client or server.
Fixes CVE-2014-0221, from OpenSSL.
Reported to OpenSSL by Imre Rad.
|
|
Fixes CVE-2014-3470, from OpenSSL.
ok deraadt@
|
|
DTLS fragments.
Fix for CVE-2014-0195, from OpenSSL.
Reported to OpenSSL by Juri Aedla.
ok deraadt@ beck@
|
|
is unchecked, which would result in a later null pointer dereference.
While here, RSA_free, DH_free and EC_KEY_free all have implicit NULL
checks, so avoid repeating them here.
ok beck@
|
|
secret. This is an additional safeguard against early ChangeCipherSpec
handling.
From OpenSSL.
ok deraadt@
|
|
Without this an early ChangeCipherSpec message would result in session
keys being generated, along with the Finished hash for the handshake,
using an empty master secret.
For a detailed analysis see:
https://www.imperialviolet.org/2014/06/05/earlyccs.html
This is a fix for CVE-2014-0224, from OpenSSL.
This issue was reported to OpenSSL by KIKUCHI Masashi. Unfortunately the
recent OpenSSL commit was the first we were made aware of the issue.
ok deraadt@ sthen@
|
|
|
|
free()ing it, rather than in conditional code.
Also do not bother setting server_opaque_prf_input (server, not client) to
NULL in conditional code 10 lines after explicitely free()ing it and setting
it to NULL (were the developers afraid of zombie pointers?)
ok guenther@
|
|
(From Frantisek Boranek)
OK from miod@
|
|
where it is feasible to do so. better safe than sorry.
|
|
(From Martin Brejcha)
OK from tedu@, miod@ and deraadt@
|
|
|
|
of the intel RDRAND instruction. Consensus was RDRAND should probably
only be used as an additional source of entropy in a mixer.
Guess which library bends over backwards to provide easy access to
RDRAND? Yep. Guess which applications are using this support? Not
even one... but still, this is being placed as a trap for someone.
Send this support straight to the abyss.
ok kettenis
|
|
|
|
isn't even exported, there's no (sane) way for someone else to use the
typedef. Eliminate the typedef and just use "struct _pqueue *".
duplicate typedef pointed out by Brent Cook (busterb (at) gmail.com)
ok miod@
|
|
this nasty function.
This gets rid of the nasty tmp variables used to hold temporary strings
and the DECIMAL_SIZE hack. it gets rid of the rather pointless null checks
for buf (since the original code dereferences it before checking). It also
gets rid of the insane possibility this could return -1 when stuff is
using the return values to compute lengths All the failure cases now
return 0 and an empty string like the first error case in the original
code.
ok miod@ tedu@
|
|
ok guenther
|
|
meaningful variable names with pointer arithmitic, rather than n, i, j
and p with array indexing.
Based on Adam Langley's chromium diffs.
ok miod@
|
|
results in the key block length calculation also being correct. Rename a
number of variables so that their purpose becomes clear and simplify some
of the code.
Inspired by Adam Langley's chromium diffs.
ok miod@
|
|
since all other characters are mapped through transparently.
ok jsing
|
|
memset(a->data, 0, (unsigned int)a->max);
but the decl is:
size_t max;
size_t could be larger than int, especially in some of the systems OpenSSL
purports to support.
How do _intentionally truncating_ casts like enter into a codebase?
Lack of understanding of C, at a minimum. Generally the objects are
small, but this code is _intentionally unready_ for large objects.
ok miod
|