- Apr 04, 2017
-
-
Richard Levitte authored
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)
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Also Z varieties. Reviewed-by:
-
- Apr 03, 2017
-
-
Dr. Stephen Henson authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3015)
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
Dr. Stephen Henson authored
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:
-
Matt Caswell authored
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:
-
Matt Caswell authored
DHparams has d2i_DHparams_fp, d2i_DHxparams_bio etc, but the equivalent macros for DHxparams were omitted. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
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:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Make sure the server can write normal data after earlier writing early data. Reviewed-by:
-
Tatsuhiro Tsujikawa authored
Reviewed-by:
-
Matt Caswell authored
Commit 9b5c865d 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:
-
Matt Caswell authored
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:
-
Kazuki Yamaguchi authored
SSL_get_max_early_data() recently added by 3fc8d856 ("Construct the ticket_early_data_info extension", 2017-02-17) is supposed to take an SSL, but it doesn't. Reviewed-by:
-
- Apr 02, 2017
-
-
Richard Levitte authored
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)
-
Richard Levitte authored
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:
-
Richard Levitte authored
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 authored
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:
-
- Apr 01, 2017
-
-
Andy Polyakov authored
Configure started with 'require 5.10.0', but if executed by older perl it failed with "might be runaway multi-line // string" instead of naturally expected "Perl v5.10.0 required--this is only v5.x.y". Reviewed-by: -
Andy Polyakov authored
Reviewed-by: -
Andy Polyakov authored
Originally there was dependency on BN configuration parameters, but it stemmed from times when "long long" support was optional. Today we require 64-bit support from compiler, and there is no reason to have "greatest-width integer" depend on BN configuration. Reviewed-by:
-
- Mar 31, 2017
-
-
Jon Spillett authored
Reviewed-by:
-
Matt Caswell authored
Numerous changes have been made to the supported built-in extensions and SSL_extension_supported() has not kept up. Reviewed-by:
-
- Mar 30, 2017
-
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
'j' is specified as modifier for "greatest-width integer type", which in practice means 64 bits on both 32- and 64-bit platforms. Since we rely on __attribute__((__format__(__printf__,...))) to sanitize BIO_print format, we can use it to denote [u]int64_t-s in platform-neutral manner. Reviewed-by:
-
Matt Caswell authored
s_client was always saying that early_data was rejected even when it was accepted. This was because it was using the wrong test to detect the end of the handshake. It was using SSL_in_init() which only tells you whether it is currently processing/sending/expecting handshake messages. It should use SSL_is_init_finished() which tells you that no handshake messages are being processed/sent/expected AND we have completed the handshake. In the early data case we are not processing/sending handshake messages and we are expecting early data (not a handshake message) - but the handshake has not yet completed. Reviewed-by:
-
Matt Caswell authored
This tests the bug fixed in the previous commit. We introduce a synthetic delay between the server receiving EoED and CF and check that we can still send early data. Reviewed-by:
-
Matt Caswell authored
If the server received EoED then SSL_read_early_data() will return SSL_READ_EARLY_DATA_FINISH. However if the CF has not yet been processed then SSL_is_init_finished() will still return 0. Therefore we should still be able to write early data. Fixes #3041 Reviewed-by:
-
Jon Spillett authored
Reviewed-by:
-
