- Mar 06, 2018
-
-
knekritz authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5372)
-
Alex Gaynor authored
Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
Bernd Edlinger authored
Had been observed with recent gcc-8 snapshot and $ ./config --strict-warnings enable-asan Reviewed-by:
-
Kurt Roeckx authored
We currently don't support the algorithm from NIST SP 800-90C 10.1.2 to use a weaker DRBG as source Reviewed-by: -
Kurt Roeckx authored
It was calling the BN_rand() when it should have call BN_priv_rand() Reviewed-by:Tim Hudson <tjh@openssl.org> GH: #5514
-
- Mar 05, 2018
-
-
Tomas Mraz authored
Either files or directories of *.cnf or *.conf files can be included. Recursive inclusion of directories is not supported. Reviewed-by:
Andy Polyakov <appro@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5351)
-
Todd Short authored
This fixes an issue raised in PR #4964 by kaduk. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> Reviewed-by:
-
Matt Caswell authored
They are valid for use in a CertificateRequest message, but we did not allow it. If a server sent such a message using either of those two extensions then the handshake would abort. This corrects that error, but does not add support for actually processing the extensions. They are simply ignored, and a TODO is inserted to add support at a later time. This was found during interoperability testing with btls: https://gitlab.com/ilari_l/btls Prompted by these errors I reviewed the complete list of extensions and compared them with the latest table in draft-24 to confirm there were no other errors of a similar type. I did not find any. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5470)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
- Mar 04, 2018
-
-
Alex Gaynor authored
Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
- Mar 03, 2018
-
-
Richard Levitte authored
Rely on the build.info constructor to do the right thing. Fixes #5500 Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Debugging asserts had implicit casts that triggered the warnings. However, instead of making the casts explicit it's more appropriate to perform checks that ensure that implicit casts were safe. ec/curve448/scalar.c: size_t-fy scalar_decode_short. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Alex Gaynor authored
Reviewed-by:
-
- Mar 02, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
This adds the Ed448 test vectors from RFC8032 and the X448 test vectors from RFC7748. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
This adds all of the relevant EVP plumbing required to make X448 and Ed448 work. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
- Mar 01, 2018
-
-
Ivan Filenko authored
CLA: trivial Reviewed-by:
-
Brad Spencer authored
CLA: trivial Reviewed-by:
-
Andy Polyakov authored
Why is it redundant? We're looking at carry from addition of small, 11-bit number to 256-bit one. And carry would mean only one thing, resulting first limb being small number and remaing ones - zeros. Hence adding 38 to first limb can't carry. Reviewed-by:
-
Benjamin Kaduk authored
When early data support was first added, this seemed like a good idea, as it would allow applications to just add SSL_read_early_data() calls as needed and have things "Just Work". However, for applications that do not use TLS 1.3 early data, there is a negative side effect. Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects derived from it) means that when generating a session ticket, tls_construct_stoc_early_data() will indicate to the client that the server supports early data. This is true, in that the implementation of TLS 1.3 (i.e., OpenSSL) does support early data, but does not necessarily indicate that the server application supports early data, when the default value is nonzero. In this case a well-intentioned client would send early data along with its resumption attempt, which would then be ignored by the server application, a waste of network bandwidth. Since, in order to successfully use TLS 1.3 early data, the application must introduce calls to SSL_read_early_data(), it is not much additional burden to require that the application also calls SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing so closes this scenario where early data packets would be sent on the wire but ignored. Update SSL_read_early_data.pod accordingly, and make s_server and our test programs into applications that are compliant with the new requirements on applications that use early data. Fixes #4725 Reviewed-by:
-
- Feb 28, 2018
-
-
Kurt Roeckx authored
Reviewed-by: -
David Makepeace authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Related to #3709 Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
This is to address issue #3404, only works in Unix-like platforms Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
- Feb 27, 2018
-
-
David Benjamin authored
Thumb2 addresses are a bit a mess, depending on whether a label is interpreted as a function pointer value (for use with BX and BLX) or as a program counter value (for use with PC-relative addressing). Clang's integrated assembler mis-assembles this code. See https://crbug.com/124610#c54 for details. Instead, use the ADR pseudo-instruction which has clear semantics and should be supported by every assembler that handles the OpenSSL Thumb2 code. (In other files, the ADR vs SUB conditionals are based on __thumb2__ already. For some reason, this one is based on __APPLE__, I'm guessing to deal with an older version of clang assembler.) It's unclear to me which of clang or binutils is "correct" or if this is even a well-defined notion beyond "whatever binutils does". But I will note that https://github.com/openssl/openssl/pull/4669 suggests binutils has also changed behavior around this before. Reviewed-by:
-
