Reviewed-by: Richard Levitte <levitte@openssl.org>

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>

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 libcrypto support for Kerberos following on from the previous commit
which removed it from libssl.

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>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Since COMP_METHOD is now defined in comp_lcl.h, it is no
longer possible to create new TLS compression methods without
using the OpenSSL source.  Only ZLIB is supported by default.
Also, since the types are opaque, #ifdef guards to use "char *"
instead of the real type aren't necessary.

The changes are actually minor.  Adding missing copyright to some
files makes the diff misleadingly big.

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

Matt's note: I added a call to X509V3err to Kurt's original patch.

RT#3840

Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

This would cause memory corruption in opt_init() because it relies on the
terminating NULL.

RT#3842

Reviewed-by: Rich Salz <rsalz@openssl.org>

clang says: "s_cb.c:958:9: error: implicitly declaring library function
'memcpy'"

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

If sk_SSL_CIPHER_new_null() returns NULL then ssl_bytes_to_cipher_list()
should also return NULL.

Based on an original patch by mrpre <mrpre@163.com>.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Add SSL_use_certiicate_chain file functions: this is works the same
way as SSL_CTX_use_certificate_chain_file but for an SSL structure.

Update SSL_CONF code to use the new function.
Update docs.
Update ordinals.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@akamai.com>

For the various string-compare routines (strcmp, strcasecmp, str.*cmp)
use "strcmp()==0" instead of "!strcmp()"

Reviewed-by: Tim Hudson <tjh@openssl.org>

If server requests a certificate, but the client doesn't send one, cache
digested records. This is an optimisation and ensures the correct finished
mac is used when extended master secret is used with client authentication.

Reviewed-by: Tim Hudson <tjh@openssl.org>

Reviewed-by: Tim Hudson <tjh@openssl.org>

The file name given to -CAserial might not exist yet.  The
-CAcreateserial option decides if this is ok or not.

Previous to this change, -CAserial was a type '<' option, and in that
case, the existence of the file given as argument is tested quite
early, and is a failure if it doesn't.  With the type 's' option, the
argument is just a string that the application can do whatever it
wants with.

Reviewed-by: Rich Salz <rsalz@openssl.org>

This is just to make sure that option is tested on a Unix build.  This
option is already present in ms/testss.bat, so it's an easy steal.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Add command line switch entries to table and return SSL_CONF_TYPE_NONE for
them in SSL_CONF_cmd_value_type.

Update docs.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Compiling OpenSSL code with MSVC and /W4 results in a number of warnings.
One category of warnings is particularly interesting - C4701 (potentially
uninitialized local variable 'name' used). This warning pretty much means
that there's a code path which results in uninitialized variables being used
or returned. Depending on compiler, its options, OS, values in registers
and/or stack, the results can be nondeterministic. Cases like this are very
hard to debug so it's rational to fix these issues.

This patch contains a set of trivial fixes for all the C4701 warnings (just
initializing variables to 0 or NULL or appropriate error code) to make sure
that deterministic values will be returned from all the execution paths.

RT#3835

Signed-off-by: Matt Caswell <matt@openssl.org>

Matt's note: All of these appear to be bogus warnings, i.e. there isn't
actually a code path where an unitialised variable could be used - its just
that the compiler hasn't been able to figure that out from the logic. So
this commit is just about silencing spurious warnings.

Reviewed-by: Rich Salz <rsalz@openssl.org>

A copy&paste error as a result of the big apps cleanup broke the version
specific methods in s_server.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Just as with the OPENSSL_malloc calls, consistently use sizeof(*ptr)
for memset and memcpy.  Remove needless casts for those functions.
For memset, replace alternative forms of zero with 0.

Reviewed-by: Richard Levitte <levitte@openssl.org>

What could be better than to refer to the RFC that defines it?

Reviewed-by: Stephen Henson <steve@openssl.org>

Fix error in WIN32_rename() introduced by commit b4faea50

.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Ensure all fatal errors transition into the new error state for DTLS.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Ensure all fatal errors transition into the new error state on the client
side.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Ensure all fatal errors transition into the new error state on the server
side.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reusing an SSL object when it has encountered a fatal error can
have bad consequences. This is a bug in application code not libssl
but libssl should be more forgiving and not crash.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>