- Apr 19, 2018
-
-
Emilia Kasper authored
The behaviour of X509_cmp_time used to be undocumented. The new behaviour, documented in master, is to return only 0, 1, or -1. Make the code in the other branches to adhere to this behaviour too, to reduce confusion. There is nothing to be gained from returning other values. Fixes GH#4954 Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4955) (cherry picked from commit 48345917)
-
- Apr 17, 2018
-
-
John Eichenberger authored
The wrong flags were being tested. It is the rsa->meth flags not the rsa flags that should be tested. wpa_supplicant has a bit of code that 1. Allocates and defines a RSA_METHOD structure. 2. calls RSA_new(); 3. calls RSA_set_method(). In current versions of that code the rsa_sign and rsa_verify members of the RSA_METHOD structure are not defined, thus making it compatible with the really old versions of OpenSSL. But should one change it use the rsa_sign method one must set the RSA_FLAG_SIGN_VER bit of the RSA_METHOD structure to indicate that one or both of those new methods are required. In doing so, OpenSSL will not call the new methods, not without this change. CLA: trivial Change-Id: I6e65a80f21399f25e966466ff676e3b21f85f360 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
We cannot provide a certificate status on a resumption so we should ignore this extension in that case. Fixes #1662 Reviewed-by:
-
- Apr 16, 2018
-
-
Billy Brumley authored
RSA key generation: ensure BN_mod_inverse and BN_mod_exp_mont both get called with BN_FLG_CONSTTIME flag set. CVE-2018-0737 Reviewed-by:
Matt Caswell <matt@openssl.org> (cherry picked from commit 6939eab0)
-
- Apr 12, 2018
-
-
Daniel Bevenius authored
This is a minor update which hopefully makes these particular lines read a little easier. Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
- Apr 07, 2018
-
-
Rich Salz authored
Reviewed-by:
-
- Apr 05, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
There are two undocumented DSA parameter generation options available in the genpkey command line app: dsa_paramgen_md and dsa_paramgen_q_bits. These can also be accessed via the EVP API but only by using EVP_PKEY_CTX_ctrl() or EVP_PKEY_CTX_ctrl_str() directly. There are no helper macros for these options. dsa_paramgen_q_bits sets the length of q in bits (default 160 bits). dsa_paramgen_md sets the digest that is used during the parameter generation (default SHA1). In particular the output length of the digest used must be equal to or greater than the number of bits in q because of this code: if (!EVP_Digest(seed, qsize, md, NULL, evpmd, NULL)) goto err; if (!EVP_Digest(buf, qsize, buf2, NULL, evpmd, NULL)) goto err; for (i = 0; i < qsize; i++) md[i] ^= buf2[i]; /* step 3 */ md[0] |= 0x80; md[qsize - 1] |= 0x01; if (!BN_bin2bn(md, qsize, q)) goto err; qsize here is the number of bits in q and evpmd is the digest set via dsa_paramgen_md. md and buf2 are buffers of length SHA256_DIGEST_LENGTH. buf2 has been filled with qsize bits of random seed data, and md is uninitialised. If the output size of evpmd is less than qsize then the line "md[i] ^= buf2[i]" will be xoring an uninitialised value and the random seed data together to form the least significant bits of q (and not using the output of the digest at all for those bits) - which is probably not what was intended. The same seed is then used as an input to generating p. If the uninitialised data is actually all zeros (as seems quite likely) then the least significant bits of q will exactly match the least significant bits of the seed. This problem only occurs if you use these undocumented and difficult to find options and you set the size of q to be greater than the message digest output size. This is for parameter generation only not key generation. This scenario is considered highly unlikely and therefore the security risk of this is considered negligible. Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
- Apr 03, 2018
-
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
Thanks to Sem Voigtländer for reporting this issue. Reviewed-by:
-
- Mar 28, 2018
-
-
Miroslav Suk authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> Reviewed-by:
-
- Mar 27, 2018
-
-
Philippe Antoine authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/5687)
-
Matt Caswell authored
If we don't have OID data for an object then we should fail if we are asked to encode the ASN.1 for that OID. Fixes #5723 Reviewed-by:
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
- Mar 26, 2018
-
-
Matt Caswell authored
Constructed types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. Therefore we limit the stack depth. CVE-2018-0739 Credit to OSSFuzz for finding this issue. Reviewed-by: -
Bernd Edlinger authored
Reviewed-by:
-
- Mar 25, 2018
-
-
Bernd Edlinger authored
Reviewed-by:
-
- Mar 21, 2018
-
-
Matt Caswell authored
Fixes #5711 Reviewed-by:
-
Samuel Weiser authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
Samuel Weiser authored
Reviewed-by:
-
Samuel Weiser authored
Replaced variable-time GCD with consttime inversion to avoid side-channel attacks on RSA key generation Reviewed-by:
-
- Mar 20, 2018
-
-
Bernd Edlinger authored
Reviewed-by:
-
- Mar 15, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
It is quite likely for there to be multiple certificates with empty subjects, which are still distinct because of subjectAltName. Therefore we allow multiple certificates with an empty Subject even if unique_subject is set to yes. Reviewed-by:
-
Matt Caswell authored
Commit 87e8feca (16 years ago!) introduced a bug where if we are attempting to insert a cert with a duplicate subject name, and duplicate subject names are not allowed (which is the default), then we get an unhelpful error message back (error number 2). Prior to that commit we got a helpful error message which displayed details of the conflicting entry in the database. That commit was itself attempting to fix a bug with the noemailDN option where we were setting the subject field in the database too early (before extensions had made any amendments to it). This PR moves the check for a conflicting Subject name until after all changes to the Subject have been made by extensions etc. This also, co-incidentally Fixes the ca crashing bug described in issue 5109. Fixes #5109 Reviewed-by:
-
Matt Caswell authored
This reverts commit a3d684ff . Empty Subjects are permissible Reviewed-by:
-
Matt Caswell authored
This reverts commit dd37f6f1 . Empty Subjects are permissible. Reviewed-by:
-
- Mar 14, 2018
-
-
Richard Levitte authored
The void* needs to be cast to a char* first. Fixes #5614 Reviewed-by:
-
- Mar 12, 2018
-
-
Matt Caswell authored
We should be using ASN1_OBJECT_free() not OPENSSL_free(). Fixes #5568 Reviewed-by:
-
Matt Caswell authored
If a mem allocation failed we would ignore it. This commit fixes it to always check. Reviewed-by:
-
- Mar 11, 2018
-
-
Kurt Roeckx authored
Reviewed-by:
-
- Mar 08, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
- Mar 07, 2018
-
-
Dr. Matthias St. Pierre authored
BIO_get_mem_data() and BIO_get_mem_ptr() assign to *pp, not pp Reviewed-by:
-
