The old custom extensions API was not TLSv1.3 aware. Extensions are used
extensively in TLSv1.3 and they can appear in many different types of
messages. Therefore we need a new API to be able to cope with that.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3139)
This move prepares for the later addition of the new custom extensions
API. The context codes have an additional "SSL_" added to their name to
ensure we don't have name clashes with other applications.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3139)
This is especially harmful since OPENSSL_cleanup() has already called
the RAND cleanup function
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3137)
Under UEFI build environment, we may encounter the OSSL_SSIZE macro
re-definition error in e_os2.h if any module call OpenSSL API directly
by including "openssl/xxxx.h" (caused by the predefined _WIN32/_WIN64
macro, which should have been un-defined under OPENSSL_SYS_UEFI).
Though it's not one recommended usage, this patch could still eliminate
the possible build issue by refining the OSSL_SSIZE definition under
OPENSSL_SYS_UEFI.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3121)
If no default method was yet given, RAND_get_rand_method() will set it
up. Doing so just to clean it away seems pretty silly, so instead,
use the default_RAND_meth variable directly.
This also clears a possible race condition where this will try to init
things, such as ERR or ENGINE when in the middle of a OPENSSL_cleanup.
Fixes#3128
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3136)
It's sheer luck that this was used for the first field only which also
has the same type in all data structures, so the offsets were never wrong
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3127)
This commit contains some optimizations in PKCS5_PBKDF2_HMAC() and
HMAC_CTX_copy() functions which together makes PBKDF2 computations
faster by 15-40% according to my measurements made on x64 Linux with
both asm optimized and no-asm versions of SHA1, SHA256 and SHA512.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1708)
Credit to OSS-Fuzz for finding this.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3088)
This increases portability of SSL_SESSION files between architectures
where the size of |long| may vary. Before this, SSL_SESSION files
produced on a 64-bit long architecture may break on a 32-bit long
architecture.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3088)
Add functions to add/retrieve the certificate_authorities. The older
client_CA functions mainly just call the new versions now.
Rename fields sice new extension can be generated by client and server.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3015)
dhparams correctly handles X9.42 params in PEM format. However it failed
to correctly processes them when reading/writing DER format.
Fixes#3102
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3111)
DHparams has d2i_DHparams_fp, d2i_DHxparams_bio etc, but the equivalent
macros for DHxparams were omitted.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3111)
The macro SSL_get_server_tmp_key() returns information about the temp key
used by the server during a handshake. This was returning NULL for TLSv1.3
and causing s_client to omit this information in its connection summary.
Fixes#3081
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3114)
Make sure the server can write normal data after earlier writing early data.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3091)
Commit 9b5c865df introduced a synthetic delay between arrival of EoED and
CF. We actually want to delay the arrival of CF even further to demonstrate
that we can write early data even when "in init".
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3091)
If we have received the EoED message but not yet had the CF then we are
"in init". Despite that we still want to write application data, so suppress
the "in init" check in ssl3_write_bytes() in that scenario.
Fixes#3041
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3091)
SSL_get_max_early_data() recently added by 3fc8d85610 ("Construct the
ticket_early_data_info extension", 2017-02-17) is supposed to take an
SSL, but it doesn't.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3113)
This test doesn't actually fail completely, but there's no real
pattern to distinguish which data files should be omitted when no-ec2m
is configured and which should not.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3103)
It's of course also possible to just add them to the PR description,
but having these lines in the commit messages provide better
automation.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3104)
When creating a single commit PR, github will now automatically
include the commit comment first in the pull request description, and
add the template content last. That makes the description section at
the end useless.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3104)
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...
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
