- May 02, 2017
-
-
Rich Salz authored
Code by Steve Henson. Backport to 1.0.2 from commit fe2d1491 Fixes #2346 Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3364)
-
Rich Salz authored
Reviewed-by:
-
Todd Short authored
ASN1_GENERALIZEDTIME and ASN1_UTCTIME may be specified using offsets, even though that's not supported within certificates. To convert the offset time back to GMT, the offsets are supposed to be subtracted, not added. e.g. 1759-0500 == 2359+0100 == 2259Z. Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3335) (cherry picked from commit ae32742e)
-
- Apr 30, 2017
-
-
Rich Salz authored
Bug found and fix suggested by Julian Rüth. Push error if fflush fails Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3348)
-
- Apr 27, 2017
-
-
Bernd Edlinger authored
It is not necessary to remove leading zeros here because RSA_padding_check_PKCS1_OAEP_mgf1 appends them again. As this was not done in constant time, this might have leaked timing information. Reviewed-by:
-
- Apr 24, 2017
-
-
Rich Salz authored
Reviewed-by:
-
Alex Gaynor authored
EV Guidelines section 9.2.5 says jurisdictionCountryName follows the same ASN.1 encoding rules as countryName. Reviewed-by:
-
- Apr 22, 2017
-
-
Camille Guérin authored
'X509_XTORE_CTX_cleanup' -> 'X509_STORE_CTX_cleanup' Reviewed-by:
Kurt Roeckx <kurt@openssl.org> Reviewed-by:
-
David Benjamin authored
BN_is_prime_fasttest_ex begins by rejecting if a <= 1. Then it goes to set A := abs(a), but a cannot be negative at this point. Reviewed-by:
-
- Apr 13, 2017
-
-
junfx authored
If exiting non-zero, which not consistent with shell conventions, the shells/scripts treat the cmd as failed. CLA: trivial Reviewed-by:
-
- Apr 11, 2017
-
-
Rich Salz authored
Reviewed-by:
-
- Apr 04, 2017
-
-
Andy Polyakov authored
It seems to be problematic to probe processor capabilities with SIGILL on MacOS X. The problem should be limited to cases when application code is debugged, but crashes were reported even during normal execution... [backport of 0bd93bbe ] Reviewed-by:
-
- Apr 03, 2017
-
-
Matt Caswell authored
dhparams correctly handles X9.42 params in PEM format. However it failed to correctly processes them when reading/writing DER format. Reviewed-by:
-
Matt Caswell authored
DHparams has d2i_DHparams_fp, d2i_DHxparams_bio etc, but the equivalent macros for DHxparams were omitted. Reviewed-by:
-
- Mar 31, 2017
-
-
Jon Spillett authored
Reviewed-by:
-
- Mar 29, 2017
-
-
Matt Caswell authored
This causes a minor (64 bytes on my machine) mem leak in s_server/s_client. Reviewed-by:
-
Steven Collison authored
These ciphers don't appear to be documented anywhere. Given the performance[1] benefits I think it makes sense to expose them. [1] https://software.intel.com/sites/default/files/open-ssl-performance-paper.pdf Reviewed-by:
-
Steven Collison authored
These were added to the help in ad775e04 but not the pods. Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Jon Spillett authored
Reviewed-by:
-
- Mar 26, 2017
-
-
Andy Polyakov authored
Even though Apple refers to Procedure Call Standard for ARM Architecture (AAPCS), they apparently adhere to custom version that doesn't follow stack alignment constraints in the said standard. [Why or why? If it's vendor lock-in thing, then it would be like worst spot ever.] And since bsaes-armv7 relied on standard alignment, it became problematic to execute the code on iOS. Reviewed-by:
-
- Mar 25, 2017
-
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
Don't access memory before checking the correct length in aesni_cbc_hmac_sha256_ctrl in case EVP_CTRL_AEAD_TLS1_AAD. Reviewed-by:
-
- Mar 24, 2017
-
-
Andy Polyakov authored
This module is used only with odd input lengths, i.e. not used in normal PKI cases, on contemporary processors. The problem was "illuminated" by fuzzing tests. Reviewed-by:
-
- Mar 23, 2017
-
-
Richard Levitte authored
Fixes #2542 Reviewed-by:
-
- Mar 22, 2017
-
-
Andy Polyakov authored
Initial IV was disregarded on SHAEXT-capable processors. Amazingly enough bulk AES128-SHA* talk-to-yourself tests were passing. Reviewed-by:
-
- Mar 21, 2017
-
-
Matt Caswell authored
Set the correct variable, and then actually send the alert! Found by, and fix suggested by, Raja Ashok. Reviewed-by:
-
Matt Caswell authored
We should not write to |out| in error cases, so we should defer doing this until the "done" block. Reviewed-by:
-
Matt Caswell authored
An internal error path could result in a memory leak. Also remove some redundant code. Reviewed-by:
-
- Mar 20, 2017
-
-
Richard Levitte authored
LONG and ZLONG items (which are OpenSSL private special cases of ASN1_INTEGER) are encoded into DER with padding if the leading octet has the high bit set, where the padding can be 0x00 (for positive numbers) or 0xff (for negative ones). When decoding DER to LONG or ZLONG, the padding wasn't taken in account at all, which means that if the encoded size with padding is one byte more than the size of long, decoding fails. This change fixes that issue. Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Kurt Roeckx authored
llvm's ubsan reported: runtime error: negation of -9223372036854775808 cannot be represented in type 'long'; cast to an unsigned type to negate this value to itself Found using afl Reviewed-by:
-
Kurt Roeckx authored
Found by afl Reviewed-by:
-
- Mar 15, 2017
-
-
Bernd Edlinger authored
Reviewed-by:
-
- Mar 13, 2017
-
-
Bernd Edlinger authored
and RSA_verify_PKCS1_PSS_mgf1 with 512-bit RSA vs. sha-512. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Andy Polyakov authored
Exteneded feature flags were not pulled on AMD processors, as result a number of extensions were effectively masked on Ryzen. Original fix for x86_64cpuid.pl addressed this problem, but messed up processor vendor detection. This fix moves extended feature detection past basic feature detection where it belongs. 32-bit counterpart is harmonized too. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Matt Caswell authored
DTLSv1_listen() is stateless. We never increment the record read sequence while listening, and we reflect the incoming record's sequence number in our write sequence. The logic for doing the write sequence reflection was *after* we had finished processing the incoming ClientHello and before we write the ServerHello. In the normal course of events this is fine. However if we need to write an early alert during ClientHello processing (e.g. no shared cipher), then we haven't done the write sequence reflection yet. This means the alert gets written with the wrong sequence number (it will just be set to whatever value we left it in the last time we wrote something). If the sequence number is less than expected then the client will believe that the incoming alert is a retransmit and will therefore drop it, causing the client to hang waiting for a response from the server. Fixes #2886 Reviewed-by:
-
