- 25 Jun, 2017 6 commits
-
-
Richard Levitte authored
This function is undocumented, but similarly named functions (such as 'curl_global_cleanup') are documented as internals that should not be called by scripts. Fixes #3765 Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3768)
-
Benjamin Kaduk authored
Reviewed-by:
-
Benjamin Kaduk authored
Test for each of DSA, SHA1, and SHA224. Use the symbolic names for SignatureScheme comparisons just added. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3326)
-
Benjamin Kaduk authored
Reviewed-by:
-
Benjamin Kaduk authored
Put them into the TLSProxy::Message namespace along with the extension type constants. Reviewed-by:
-
Benjamin Kaduk authored
In draft-ietf-tls-tls13-20 Appendix B we find that: This section describes protocol types and constants. Values listed as _RESERVED were used in previous versions of TLS and are listed here for completeness. TLS 1.3 implementations MUST NOT send them but might receive them from older TLS implementations. Similarly, in section 4.2.3 we see: Legacy algorithms Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either with RSA using RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages. Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility. Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see Section 4.4.2.2). However, we are currently sending the SHA2-based DSA signature schemes and many SHA1-based schemes, which is in contradiction with the specification. Because TLS 1.3 support will appear in OpenSSL 1.1, we are bound by stability requirements to continue to offer the DSA signature schemes and the deprecated hash algorithms. at least until OpenSSL 1.2. However, for pure TLS 1.3 clients that do not offer lower TLS versions, we can be compliant. Do so, and leave a note to revisit the issue when we are permitted to break with sacred historical tradition. Reviewed-by:
-
- 24 Jun, 2017 2 commits
-
-
Andy Polyakov authored
Curiously enough out-of-order Silvermont benefited most from optimization, 33%. [Originally mentioned "anomaly" turned to be misreported frequency scaling problem. Correct results were collected under older kernel.] Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/3739)
-
Andy Polyakov authored
Reviewed-by:
-
- 23 Jun, 2017 5 commits
-
-
Matt Caswell authored
[extended tests] Reviewed-by:
-
Matt Caswell authored
Something environmental changed in travis so that it started preferring the ubuntu clang-3.9 version instead of the llvm.org one. This breaks the sanitiser based builds. This change forces travis to de-prioritise the ubuntu clang packages. [extended tests] Reviewed-by:
-
Matt Caswell authored
Following on from the previous commit this fixes another instance where we need to treat a -ve return from EVP_DigestVerify() as a bad signature. Reviewed-by:
-
Matt Caswell authored
Prior to 72ceb6a6 we treated all failures from the call to EVP_DigestVerifyFinal() as if it were a bad signature, and failures in EVP_DigestUpdate() as an internal error. After that commit we replaced this with the one-shot function EVP_DigestVerify() and treated a 0 return as a bad signature and a negative return as an internal error. However, some signature errors can be negative (e.g. according to the docs if the form of the signature is wrong). Therefore we should treat all <=0 returns as a bad signature. This fixes a boringssl test failure. Reviewed-by:
-
Matt Caswell authored
We were adding more tests than we had data for due to use of sizeof instead of OSSL_NELEM. I also changed the 8 bit tests for consistency, although they were already working. Reviewed-by:
-
- 22 Jun, 2017 4 commits
-
-
Pauli authored
This macro aborts the test which prevents later tests from executing. It also bypasses the test framework output functionality. Reviewed-by:
-
Matt Caswell authored
In 1.0.2 and before OBJ_create() allowed the sn or ln parameter to be NULL. Commit 52832e47 changed that so that it crashed if they were NULL. This was causing problems with the built-in config oid module. If a long name was provided OBJ_create() is initially called with a NULL ln and therefore causes a crash. Fixes #3733 Reviewed-by:
-
Alexey Komnin authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
David Benjamin authored
Per RFC 7905, the cipher suite names end in "_SHA256". The original implementation targeted the -03 draft, but there was a -04 draft right before the RFC was published to make the names consistent. Reviewed-by:
-
- 21 Jun, 2017 23 commits
-
-
Pauli authored
This is an implementation of a BIO filter that produce TAP compatible output for the test framework. The current test indentation level is honoured. The test output functions have been modified to not attempt to indent their output and to not include the leading '#' character. The filter is applied to bio_err only. bio_out is left unchanged, although tests using bio_out have been modified to use bio_err instead. Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3732)
-
Richard Levitte authored
Reviewed-by:
-
Pauli authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3731)
-
Sascha Steinbiss authored
Adding a get1 style accessor as brought up in mailing list post https://mta.openssl.org/pipermail/openssl-users/2016-November/004796.html Reviewed-by:
-
Paul Yang authored
initialize some local variables Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Andy Polyakov authored
[skip ci] Reviewed-by:
-
Andy Polyakov authored
[skip ci] Reviewed-by:
-
Matt Caswell authored
The value of BIO_CTRL_DGRAM_SET_PEEK_MODE was clashing with the value for BIO_CTRL_DGRAM_SCTP_SET_IN_HANDSHAKE. In an SCTP enabled build BIO_CTRL_DGRAM_SCTP_SET_IN_HANDSHAKE was used unconditionally with the reasoning that it would be ignored if SCTP wasn't in use. Unfortunately due to this clash, this wasn't the case. The BIO ended up going into peek mode and was continually reading the same data over and over - throwing it away as a replay. Fixes #3723 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Found while developing the PSK tests Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Ensure that we properly distinguish between successful return (PSK provided), successful return (no PSK provided) and failure. 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:
-
Matt Caswell authored
Broken through previous PSK related commits Reviewed-by:
-
