BLKINIT optimization worked on T4, but for some reason appears "too
aggressive" for T3 triggering intermiitent EC failures. It's not clear
why only EC is affected...
Reviewed-by: Tim Hudson <tjh@openssl.org>
Move per-connection state out of the CERT structure: which should just be
for shared configuration data (e.g. certificates to use).
In particular move temporary premaster secret, raw ciphers, peer signature
algorithms and shared signature algorithms.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Rewrite and tidy ASN1_INTEGER and ASN1_ENUMERATED handling.
Remove code duplication.
New functions to convert between int64_t and ASN.1 types without the
quirks of the old long conversion functions.
Add documentation.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Move these functions into t1_clnt.c, t1_srvr.c and t1_meth.c and take
advantage of the existing tls1_get*_method() functions that all the other
methods are using. Since these now have to support SSLv3 anyway we might
as well use the same set of get functions for both TLS and SSLv3.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Following the version negotiation rewrite all of the previous code that was
dedicated to version negotiation can now be deleted - all six source files
of it!!
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Continuing from the previous commit this changes the way we do client side
version negotiation. Similarly all of the s23* "up front" state machine code
has been avoided and again things now work much the same way as they already
did for DTLS, i.e. we just do most of the work in the
ssl3_get_server_hello() function.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
This commit changes the way that we do server side protocol version
negotiation. Previously we had a whole set of code that had an "up front"
state machine dedicated to the negotiating the protocol version. This adds
significant complexity to the state machine. Historically the justification
for doing this was the support of SSLv2 which works quite differently to
SSLv3+. However, we have now removed support for SSLv2 so there is little
reason to maintain this complexity.
The one slight difficulty is that, although we no longer support SSLv2, we
do still support an SSLv3+ ClientHello in an SSLv2 backward compatible
ClientHello format. This is generally only used by legacy clients. This
commit adds support within the SSLv3 code for these legacy format
ClientHellos.
Server side version negotiation now works in much the same was as DTLS,
i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to
that then when a ClientHello is received it will work out the most
appropriate version to respond with. Also, SSLv23_method and
SSLv23_server_method have been replaced with TLS_method and
TLS_server_method respectively. The old SSLv23* names still exist as
macros pointing at the new name, although they are deprecated.
Subsequent commits will look at client side version negotiation, as well of
removal of the old s23* code.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Follow the same convention the other OPENSSL_NO_xxx header files
do, and use #error instead of making the header file be a no-op.
Reviewed-by: Matt Caswell <matt@openssl.org>
The move of headers from crypto/ to crypto/include/internal/ needs
this extra inclusion directory or the build fails.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
Added depencies on the public variants of some keys in test to Makefile.
Added the newly introduced key files from test/ in the list of files
to copy in util/pl/unix.pl.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are header files in crypto/ that are used by the rest of
OpenSSL. Move those to include/internal and adapt the affected source
code, Makefiles and scripts.
The header files that got moved are:
crypto/constant_time_locl.h
crypto/o_dir.h
crypto/o_str.h
Reviewed-by: Matt Caswell <matt@openssl.org>
Having the INTxx_MIN et al macros defined in a public header is
unnecessary and risky. Also, it wasn't done for all platforms that
might need it.
So we move those numbers to an internal header file, do the math
ourselves and make sure to account for the integer representations we
know of.
This introduces include/internal, which is unproblematic since we
already use -I$(TOP)/include everywhere. This directory is different
from crypto/include/internal, as the former is more general internal
headers for all of OpenSSL, while the latter is for libcrypto only.
Reviewed-by: Matt Caswell <matt@openssl.org>
Include appropriate headers for standard integer types in e_os2.h
This should use stdint.h, inttypes.h or a workaround for systems which
have neither.
Reviewed-by: Matt Caswell <matt@openssl.org>
If an EVP implementation (such as an engine) fails out early, it's
possible to call EVP_CIPHER_CTX_cleanup() which will call
ctx->cipher->cleanup() before the cipher_data has been initialized
via ctx->cipher->init(). Guarantee it's all-bytes-zero as soon as
it is allocated.
Reviewed-by: Matt Caswell <matt@openssl.org>
The function obj_cmp() (file crypto/objects/obj_dat.c) can in some
situations call memcmp() with a null pointer and a zero length.
This is invalid behaviour. When compiling openssl with undefined
behaviour sanitizer (add -fsanitize=undefined to compile flags) this
can be seen. One example that triggers this behaviour is the pkcs7
command (but there are others, e.g. I've seen it with the timestamp
function):
apps/openssl pkcs7 -in test/testp7.pem
What happens is that obj_cmp takes objects of the type ASN1_OBJECT and
passes their ->data pointer to memcmp. Zero-sized ASN1_OBJECT
structures can have a null pointer as data.
RT#3816
Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Following on from the removal of libcrypto and libssl support for Kerberos
this commit removes all remaining references to Kerberos.
Reviewed-by: Rich Salz <rsalz@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>
Remove Kerberos related options from the apps to prepare for the
subsequent commits which will remove libcrypto and libssl support for
Kerberos.
Reviewed-by: Rich Salz <rsalz@openssl.org>
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>
Original 'sizeof(ADDED_OBJ)' was replaced with 'sizeof(*ao)'. However,
they return different sizes. Therefore as the result heap gets corrupted
and at some point later debug version of malloc() detects the corruption.
On x86 we can observe that as follows:
sizeof(*ao) == 4
sizeof(*ao[0]) == sizeof(ADDED_OBJ) == 8
Issue reproduces with either enabling CRT debug heap or Application
Verifier's full-page heap.
Basic debugging data from the moment the corruption is first detected:
0:000:x86> |
. 0 id: 283c create name: openssl.exe
0:000:x86> kcn
#
00 MSVCR120D!_heap_alloc_dbg_impl
01 MSVCR120D!_nh_malloc_dbg_impl
02 MSVCR120D!_nh_malloc_dbg
03 MSVCR120D!malloc
04 LIBEAY32!default_malloc_ex
05 LIBEAY32!CRYPTO_malloc
06 LIBEAY32!lh_insert
07 LIBEAY32!OBJ_add_object
08 LIBEAY32!OBJ_create
09 openssl!add_oid_section
0a openssl!req_main
0b openssl!do_cmd
0c openssl!main
0d openssl!__tmainCRTStartup
0e openssl!mainCRTStartup
0f KERNEL32!BaseThreadInitThunk
10 ntdll_77d60000!__RtlUserThreadStart
11 ntdll_77d60000!_RtlUserThreadStart
Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
