- May 14, 2015
-
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Dr. Stephen Henson authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Dr. Stephen Henson authored
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>
-
- May 13, 2015
-
-
Rich Salz authored
Had old patch, forgot to push/patch this to master Reviewed-by: Matt Caswell <matt@openssl.org>
-
Rich Salz authored
Various bugs found by Viktor, Emilia, Matt, etc. Reviewed-by: Matt Caswell <matt@openssl.org>
-
Rich Salz authored
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>
-
Rich Salz authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Rich Salz authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Andy Polyakov authored
Support cross-compile platforms that don't support FINGERPRINT_premain, e.g. VxWorks. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Matt Caswell <matt@openssl.org>
-
Hanno Böck authored
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>
-
Matt Caswell authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
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>
-
Matt Caswell authored
Remove libcrypto support for Kerberos following on from the previous commit which removed it from libssl. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
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>
-
Matt Caswell authored
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>
-
Matt Caswell authored
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>
-
Gunnar Kudrjavets authored
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>
-
- May 12, 2015
-
-
Dr. Stephen Henson authored
Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Rich Salz authored
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>
-
Dr. Stephen Henson authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
- May 11, 2015
-
-
Rich Salz authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Kurt Cancemi authored
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>
-
Kurt Cancemi authored
This would cause memory corruption in opt_init() because it relies on the terminating NULL. RT#3842 Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Bjoern D. Rasmussen authored
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>
-
Matt Caswell authored
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>
-
- May 08, 2015
-
-
Dr. Stephen Henson authored
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>
-
- May 07, 2015
-
-
Viktor Dukhovni authored
Reviewed-by: Rich Salz <rsalz@akamai.com>
-
Rich Salz authored
For the various string-compare routines (strcmp, strcasecmp, str.*cmp) use "strcmp()==0" instead of "!strcmp()" Reviewed-by: Tim Hudson <tjh@openssl.org>
-
- May 06, 2015
-
-
Dr. Stephen Henson authored
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>
-