- Feb 20, 2019
-
-
Shane Lontis authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8281)
-
Nicola Tuveri authored
Reviewed-by:
-
Nicola Tuveri authored
This commit adds a simple unit test to make sure that the constant-time flag does not "leak" among BN_CTX frames: - test_ctx_consttime_flag() initializes (and later frees before returning) a BN_CTX object, then it calls in sequence test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same BN_CTX object. The process is run twice, once with a "normal" BN_CTX_new() object, then with a BN_CTX_secure_new() one. - test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame before ending it. - test_ctx_check_ct_flag() then starts a new frame and gets a number of BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new frame should have BN_FLG_CONSTTIME set. In actual BN_CTX usage inside libcrypto the leak could happen at any depth level in the BN_CTX stack, with varying results depending on the patterns of sibling trees of nested function calls sharing the same BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the called BN_* functions. This simple unit test abstracts away this complexity and verifies that the leak does not happen between two sibling functions sharing the same BN_CTX object at the same level of nesting. Reviewed-by:
-
Richard Levitte authored
Because test order can be randomized, running foo_init() as a separate test is unsafe practice. Instead, we make it possible to call it multiple times, and call it at the start of each separate test. Reviewed-by:
-
- Feb 19, 2019
-
-
Andy Polyakov authored
E.g. on MIPS64 it gives >20% improvement... Reviewed-by:
-
Ionut Mihalcea authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
-
Matthias Kraft authored
The AIX binder needs to be instructed that the output will have no entry point (see AIX' ld manual: -e in the Flags section; autoexp and noentry in the Binder section). Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
In TLSv1.3 it is illegal to interleave handshake records with non handshake records. Fixes #8189 Reviewed-by:
-
Richard Levitte authored
There were some faults that got caught by the updated doc-nits Reviewed-by:
-
Pauli authored
A randomised order causes failure due to unintentional dependencies between two of the test cases. [extended tests] Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8279)
-
- Feb 18, 2019
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
While we're at it, we also check for names that contain white-space, as they are invalid. Reviewed-by:
-
Corinna Vinschen authored
Cygwin binaries should not enforce text mode these days, just use text mode if the underlying mount point requests it CLA: trivial Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Reviewed-by:
-
Richard Levitte authored
The NAME section format is comma separated names to the left of the left of the dash, free form on the right. If we don't follow that form, programs like apropos(1) and whatis(1) can't do their job properly. Reviewed-by:
-
Richard Levitte authored
- Add a bit more text about that is expected of the user or OSSL_METHOD_STOREs. - Clarify what a method and what a numeric identity are. - Change all mentions of 'implementation' and 'result' to 'method'. To clarify further: OpenSSL has used the term 'method' for structures that mainly contains function pointers. Those are the methods that are expected to be stored away in OSSL_METHOD_STOREs. In the end, however, it's the caller's responsibility to define exactly what they want to store, as long as its 'methods' are associated with a numeric identity and properties. Reviewed-by:
-
Matt Caswell authored
Found by Coverity Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/8260)
-
Pauli authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8224)
-
Pauli authored
Properties are a sequence of comma separated name=value pairs. A name without a corresponding value is assumed to be a Boolean and have the true value 'yes'. Values are either strings or numbers. Strings can be quoted either _"_ or _'_ or unquoted (with restrictions). There are no escape characters inside strings. Number are either decimal digits or '0x' followed by hexidecimal digits. Numbers are represented internally as signed sixty four bit values. Queries on properties are a sequence comma separated conditional tests. These take the form of name=value (equality test), name!=value (inequality test) or name (Boolean test for truth). Queries can be parsed, compared against a definition or merged pairwise. Reviewed-by:
-
- Feb 17, 2019
-
-
Vedran Miletić authored
CLA: trivial Reviewed-by:
-
Jan Macku authored
CLA: trivial Reviewed-by:
-
David Benjamin authored
Reviewed-by: -
David Benjamin authored
The add/double shortcut in ecp_nistz256-x86_64.pl left one instruction point that did not unwind, and the "slow" path in AES_cbc_encrypt was not annotated correctly. For the latter, add .cfi_{remember,restore}_state support to perlasm. Next, fill in a bunch of functions that are missing no-op .cfi_startproc and .cfi_endproc blocks. libunwind cannot unwind those stack frames otherwise. Finally, work around a bug in libunwind by not encoding rflags. (rflags isn't a callee-saved register, so there's not much need to annotate it anyway.) These were found as part of ABI testing work in BoringSSL. Reviewed-by: -
Billy Brumley authored
Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/8254)
-
Billy Brumley authored
This commit adds a dedicated function in `EC_METHOD` to access a modular field inversion implementation suitable for the specifics of the implemented curve, featuring SCA countermeasures. The new pointer is defined as: `int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)` and computes the multiplicative inverse of `a` in the underlying field, storing the result in `r`. Three implementations are included, each including specific SCA countermeasures: - `ec_GFp_simple_field_inv()`, featuring SCA hardening through blinding. - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's Little Theorem (FLT) inversion. - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which already features SCA hardening through blinding. From a security point of view, this also helps addressing a leakage previously affecting conversions from projective to affine coordinates. This commit also adds a new error reason code (i.e., `EC_R_CANNOT_INVERT`) to improve consistency between the three implementations as all of them could fail for the same reason but through different code paths resulting in inconsistent error stack states. Co-authored-by:
-
- Feb 16, 2019
-
-
Andy Polyakov authored
"Windows friendliness" means a) unified PIC-ification, unified across all platforms; b) unified commantary delimiter; c) explicit ldur/stur, as Visual Studio assembler can't automatically encode ldr/str as ldur/stur when needed. Reviewed-by:
-
Andy Polyakov authored
"Windows friendliness" means a) flipping .thumb and .text directives, b) always generate Thumb-2 code when asked(*); c) Windows-specific references to external OPENSSL_armcap_P. (*) so far *some* modules were compiled as .code 32 even if Thumb-2 was targeted. It works at hardware level because processor can alternate between the modes with no overhead. But clang --target=arm-windows's builtin assembler just refuses to compile .code 32... Reviewed-by:
-
Patrick Steuer authored
Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
-
- Feb 15, 2019
-
-
Richard Levitte authored
The context builds on CRYPTO_EX_DATA, allowing it to be dynamically extended with new data from the different parts of libcrypto. Reviewed-by:
-
Richard Levitte authored
This allows allocation of items at indexes that were created after the CRYPTO_EX_DATA variable was initialized, using the exact same method that was used then. Reviewed-by:
-
David Asraf authored
New function to return internal pointer for field. Reviewed-by:
-
Richard Levitte authored
safestack.h, lhash.h and sparse_array.h all define macros to generate a full API for the containers as static inline functions. This potentially generates unused code, which some compilers may complain about. We therefore need to mark those generated functions as unused, so the compiler knows that we know, and stops complaining about it. Reviewed-by:
-
Todd Short authored
Add SSL_OP64_NO_EXTENDED_MASTER_SECRET, that can be set on either an SSL or an SSL_CTX. When processing a ClientHello, if this flag is set, do not indicate that the EMS TLS extension was received in either the ssl3 object or the SSL_SESSION. Retain most of the sanity checks between the previous and current session during session resumption, but weaken the check when the current SSL object is configured to not use EMS. Reviewed-by:
-
Matt Caswell authored
Otherwise this can result in an incorrect calculation of the maximum encoded integer length, meaning an insufficient buffer size is allocated. Thanks to Billy Brumley for helping to track this down. Fixes #8209 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Richard Levitte authored
This makes `--strict-warnings` into a compiler pseudo-option, i.e. it gets treated the same way as any other compiler option given on the configuration command line, but is retroactively replaced by actual compiler warning options, depending on what compiler is used. This makes it easier to see in what order options are given to the compiler from the configuration command line, i.e. this: ./config -Wall --strict-warnings would give the compiler flags in the same order as they're given, i.e.: -Wall -Werror -Wno-whatever ... instead of what we got previously: -Werror -Wno-whatever ... -Wall Reviewed-by:
-
- Feb 14, 2019
-
-
Matt Caswell authored
The "verify_return_error" option in s_client is documented as: Return verification errors instead of continuing. This will typically abort the handshake with a fatal error. In practice this option was ignored unless also accompanied with the "-verify" option. It's unclear what the original intention was. One fix could have been to change the documentation to match the actual behaviour. However it seems unecessarily complex and unexpected that you should need to have both options. Instead the fix implemented here is make the option match the documentation so that "-verify" is not also required. Note that s_server has a similar option where "-verify" (or "-Verify") is still required. This makes more sense because those options additionally request a certificate from the client. Without a certificate there is no possibility of a verification failing, and so "-verify_return_error" doing nothing seems ok. Fixes #8079 Reviewed-by:
-
Matt Caswell authored
The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message exchange in TLSv1.3. Unfortunately experience has shown that this confuses some applications who mistake it for a TLSv1.2 renegotiation. This means that KeyUpdate messages are not handled properly. This commit removes the use of SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake message exchange. Individual post-handshake messages are still signalled in the normal way. This is a potentially breaking change if there are any applications already written that expect to see these TLSv1.3 events. However, without it, KeyUpdate is not currently usable for many applications. Fixes #8069 Reviewed-by:
-
Sam Roberts authored
set_cipher_list() sets TLSv1.2 (and below) ciphers, and its success or failure should not depend on whether set_ciphersuites() has been used to setup TLSv1.3 ciphers. Reviewed-by:
-
Richard Levitte authored
There are times when one might want to use something like DEFINE_STACK_OF in a .c file, because it defines a stack for a type defined in that .c file. Unfortunately, when configuring with `--strict-warnings`, clang aggressively warn about unused functions in such cases, which forces the use of such DEFINE macros to header files. We therefore disable this warning from the `--strict-warnings` definition for clang. (note for the curious: `-Wunused-function` is enabled via `-Wall`) Reviewed-by:
-
