- 08 Feb, 2018 1 commit
-
-
Richard Levitte authored
The slash should be there according to Microsoft documentation, see https://msdn.microsoft.com/en-us/library/7cafx990.aspx Fixes #5277 Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5278)
-
- 07 Feb, 2018 14 commits
-
-
Matt Caswell authored
tls13encryptiontest is an "internal" test. As with all the other internal tests it should not be run on a shared native Windows build. [extended tests] Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5266)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
If TLSv1.3 is enabled and combined with other options that extend the size of the ClientHello, then the clienthello test can sometimes fail because the ClientHello has grown too large. Part of the purpose of the test is to check that the padding extension works properly. This requires the ClientHello size to be kept within certain bounds. By restricting the number of ciphersuites sent we can reduce the size of the ClientHello. Reviewed-by:
-
Matt Caswell authored
[extended tests] Reviewed-by:
-
Richard Levitte authored
It turns out that even if you successfully build the engine, it might not load properly, so we cannot make the test program fail for it. See the message in commit 25b9d11c This reverts commit 227a1e3f . Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5276)
-
Richard Levitte authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5275)
-
Richard Levitte authored
If a module is disablable (i.e. can be configured with 'no-FOO'), the resulting header file needs to be guarded with a check of the corresponding OPENSSL_NO_FOO. While this seem fairly innocuous, it has an impact on the information in util/*.num, generated by mkdef.pl. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
The afalg engine was moved down from engines/afalg/ to engines/, but the test wasn't changed accordingly. This was undetected because the test program didn't fail when it couldn't load the engine. Reviewed-by:
-
Richard Levitte authored
If you know that there's no afalg engine, don't run this test. test/recipes/30-test_afalg.t checks this correctly. Reviewed-by:
-
Pauli authored
MacOS seems to define __GLIBC__ but not __GLIBC_PREREQ. Reviewed-by:
-
Pauli authored
Remove the timer and TSC additional input code and instead provide a single routine that attempts to use the "best" timer/counter available on the system. It attempts to use TSC, then various OS dependent resources and finally several tries to obtain the date. If any of these timer/counters is successful, the rest are skipped. No randomness is credited for this. Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/5231)
-
Pauli authored
If such a timer/counter register is not available, the return value is always zero. This matches the assembly implementations' behaviour. Reviewed-by:
-
Pauli authored
Patch by @levitte. Reviewed-by:
-
- 06 Feb, 2018 5 commits
-
-
Richard Levitte authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5268)
-
Rich Salz authored
Reviewed-by:
-
Patrick Steuer authored
Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
Andy Polyakov <appro@openssl.org> Reviewed-by:
-
Patrick Steuer authored
Signed-off-by:
-
Richard Levitte authored
This script kept its own database of disablable algorithms, which is a maintenance problem, as it's not always perfectly in sync with what Configure does. However, we do have all the data in configdata.pm, produced by Configure, so let's use that instead. Also, make sure to parse the *err.h header files, as they contain function declarations that might not be present elsewhere. Reviewed-by:
-
- 05 Feb, 2018 4 commits
-
-
Dr. Matthias St. Pierre authored
The functions RAND_bytes() and RAND_priv_bytes() are now both based on a common implementation using RAND_DRBG_bytes() (if the default OpenSSL rand method is active). This not only simplifies the code but also has the advantage that additional input from a high precision timer is added on every generate call if the timer is available. Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5251)
-
Dr. Matthias St. Pierre authored
When comparing the implementations of drbg_bytes() and RAND_DRBG_bytes(), it was noticed that the former split the buffer into chunks when calling RAND_DRBG_generate() to circumvent the size limitation of the buffer to outlen <= drb->max_request. This loop was missing in RAND_DRBG_bytes(), so it was adopted from drbg_bytes(). Reviewed-by:
-
Dr. Matthias St. Pierre authored
This check not only prevented the automatic reinstantiation of the DRBG, which is implemented in RAND_DRBG_generate(), but also prevented an error message from being generated in the case of failure. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
- 02 Feb, 2018 5 commits
-
-
Tatsuhiro Tsujikawa authored
Reviewed-by:
-
Tatsuhiro Tsujikawa authored
Reviewed-by:
-
Tatsuhiro Tsujikawa authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
- 01 Feb, 2018 11 commits
-
-
Richard Levitte authored
The assumption that the received buffer has to be NUL-terminated was faulty. Fault found in #5224 Reviewed-by:
-
David Benjamin authored
BN_from_montgomery_word doesn't have a constant memory access pattern. Replace the pointer trick with a constant-time select. There is, of course, still the bn_correct_top leak pervasive in BIGNUM itself. See also https://boringssl-review.googlesource.com/22904 from BoringSSL. Reviewed-by:
-
David Benjamin authored
The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its bit length are both secret. The only public upper bound is the bit width of the corresponding modulus (RSA n, p, and q, respectively). Although BN_num_bits is constant-time (sort of; see bn_correct_top notes in preceding patch), this does not fix the root problem, which is that the windows are based on the minimal bit width, not the upper bound. We could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API and may be called with larger exponents. Instead, use all top*BN_BITS2 bits in the BIGNUM. This is still sensitive to the long-standing bn_correct_top leak, but we need to fix that regardless. This may cause us to do a handful of extra multiplications for RSA keys which are just above a whole number of words, but that is not a standard RSA key size. Reviewed-by:
-
David Benjamin authored
(This patch was written by Andy Polyakov. I only wrote the commit message. Mistakes in the analysis are my fault.) BN_num_bits, by way of BN_num_bits_word, currently leaks the most-significant word of its argument via branching and memory access pattern. BN_num_bits is called on RSA prime factors in various places. These have public bit lengths, but all bits beyond the high bit are secret. This fully resolves those cases. There are a few places where BN_num_bits is called on an input where the bit length is also secret. This does *not* fully resolve those cases as we still only look at the top word. Today, that is guaranteed to be non-zero, but only because of the long-standing bn_correct_top timing leak. Once that is fixed, a constant-time BN_num_bits on such inputs must count bits on each word. Instead, those cases should not call BN_num_bits at all. In particular, BN_mod_exp_mont_consttime uses the exponent bit width to pick windows, but it should be using the maximum bit width. The next patch will fix this. Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu for reporting this issue. Reviewed-by:
-
Michael Richardson authored
added macro to create version number use the macro to build OPENSSL_VERSION_AT_LEAST(maj,min,fix) so that customers of libssl (such as ruby-openssl) do not need to be so aware of openssl version numbers. includes updates to ssl(7) and OPENSSL_VERSION_NUMBER(3) man page Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Richard Levitte authored
So as not to be mixed up with a device specification... Reviewed-by:
-
Todd Short authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> Reviewed-by:
-
Todd Short authored
Reviewed-by:
-
Todd Short authored
Reviewed-by:
-
Todd Short authored
Add SSL_verify_client_post_handshake() for servers to initiate PHA Add SSL_force_post_handshake_auth() for clients that don't have certificates initially configured, but use a certificate callback. Update SSL_CTX_set_verify()/SSL_set_verify() mode: * Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after the initial handshake. * Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless of when the certificate authentication takes place; either initial handshake, re-negotiation, or post-handshake authentication. Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options Add support to s_client: * Enabled automatically when cert is configured * Can be forced enabled via -force_pha Add support to s_server: * Use 'c' to invoke PHA in s_server * Remove some dead code Update documentation Update unit tests: * Illegal use of PHA extension * TLSv1.3 certificate tests DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is implemented, it's PHA support state machine may need to be different. Add a TODO and a #error Update handshake context to deal with PHA. The handshake context for TLSv1.3 post-handshake auth is up through the ClientFinish message, plus the CertificateRequest message. Subsequent Certificate, CertificateVerify, and Finish messages are based on this handshake context (not the Certificate message per se, but it's included after the hash). KeyUpdate, NewSessionTicket, and prior Certificate Request messages are not included in post-handshake authentication. After the ClientFinished message is processed, save off the digest state for future post-handshake authentication. When post-handshake auth occurs, copy over the saved handshake context into the "main" handshake digest. This effectively discards the any KeyUpdate or NewSessionTicket messages and any prior post-handshake authentication. This, of course, assumes that the ID-22 did not mean to include any previous post-handshake authentication into the new handshake transcript. This is implied by section 4.4.1 that lists messages only up to the first ClientFinished. Reviewed-by:
-
