- Sep 08, 2018
-
-
Richard Levitte authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7154)
-
Richard Levitte authored
Reviewed-by:
-
- Sep 07, 2018
-
-
Matt Caswell authored
PR #3783 introduce coded to reset the server side SNI state in SSL_do_handshake() to ensure any erroneous config time SNI changes are cleared. Unfortunately SSL_do_handshake() can be called mid-handshake multiple times so this is the wrong place to do this and can mean that any SNI data is cleared later on in the handshake too. Therefore move the code to a more appropriate place. Fixes #7014 Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/7149)
-
Ben Kaduk authored
Ideally, SSL_get_servername() would do exactly as it is documented and return exactly what the client sent (i.e., what we currently are stashing in the SSL's ext.hostname), without needing to refer to an SSL_SESSION object. For historical reasons, including the parsed SNI value from the ClientHello originally being stored in the SSL_SESSION's ext.hostname field, we have had references to the SSL_SESSION in this function. We cannot fully excise them due to the interaction between user-supplied callbacks and TLS 1.2 resumption flows, where we call all callbacks but the client did not supply an SNI value. Existing callbacks expect to receive a valid SNI value in this case, so we must fake one up from the resumed session in order to avoid breakage. Otherwise, greatly simplify the implementation and just return the value in the SSL, as sent by the client. Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7115)
-
Ben Kaduk authored
Commit 1c4aa31d modified the state machine to clean up stale ext.hostname values from SSL objects in the case when SNI was not negotiated for the current handshake. This is natural from the TLS perspective, since this information is an extension that the client offered but we ignored, and since we ignored it we do not need to keep it around for anything else. However, as documented in https://github.com/openssl/openssl/issues/7014 , there appear to be some deployed code that relies on retrieving such an ignored SNI value from the client, after the handshake has completed. Because the 1.1.1 release is on a stable branch and should preserve the published ABI, restore the historical behavior by retaining the ext.hostname value sent by the client, in the SSL structure, for subsequent retrieval. [extended tests] Reviewed-by:
-
Matt Caswell authored
The is_tls13_capable() function should not return 0 if no certificates are configured directly because a certificate callback is present. Fixes #7140 Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7141)
-
Matt Caswell authored
That function was removed in favour of SSL_set_post_handshake_auth(). Update the docs accordingly. Reviewed-by:
-
Matt Caswell authored
Even though we already sent close_notify the server may not have recieved it yet and could issue a CertificateRequest to us. Since we've already sent close_notify we can't send any reasonable response so we just ignore it. Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Matt Caswell authored
If we've sent a close_notify then we are restricted about what we can do in response to handshake messages that we receive. However we can sensibly process NewSessionTicket messages. We can also process a KeyUpdate message as long as we also ignore any request for us to update our sending keys. Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Jack Lloyd authored
This test case is originally submitted in #6757, by Jack Lloyd. The test case has been modified to use the a different method to set the ID when computing the Z hash of SM2 signature. Reviewed-by:
Paul Yang <yang.yang@baishancloud.com> (Merged from https://github.com/openssl/openssl/pull/7113)
-
Paul Yang authored
zero-length ID is allowed, but it's not allowed to skip the ID. Fixes: #6534 Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Paul Yang authored
Thus users can use this function to set customized EVP_PKEY_CTX to EVP_MD_CTX structure. Reviewed-by:
-
Paul Yang authored
Reviewed-by:
-
Patrick Steuer authored
Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/7138)
-
Paul Yang authored
This addresses issue #6922. Reviewed-by:
-
- Sep 06, 2018
-
-
Pauli authored
Put a NULL check back in to avoid dereferencing the NULL pointer. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
- Sep 05, 2018
-
-
Shane Lontis authored
Reviewed-by:
-
Nicola Tuveri authored
Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
Nicola Tuveri authored
`RSA_free()` and friends are called in case of error from `RSA_new_method(ENGINE *e)` (or the respective equivalent functions). For the rest of the description I'll talk about `RSA_*`, but the same applies for the equivalent `DSA_free()`, `DH_free()`, `EC_KEY_free()`. If `RSA_new_method()` fails because the engine does not implement the required method, when `RSA_free(RSA *r)` is called, `r->meth == NULL` and a segfault happens while checking if `r->meth->finish` is defined. This commit fixes this issue by ensuring that `r->meth` is not NULL before dereferencing it to check for `r->meth->finish`. Fixes #7102 . Reviewed-by:
-
- Sep 04, 2018
-
-
Eric Curtin authored
-subj 'subject=C = US, ST = A, L = root, O = Hewlett Packard Enterprise Company, OU = Remote Device Access, CN = Hewlett Packard Enterprise Remote Device Access Test Local CA, emailAddress = rda@hpe.com' was a valid subject in openssl 1.0. Error received in 1.1 is: problems making Certificate Request Not very informative, I only figured this out because I compiled the code and added logging. Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Shane Lontis authored
Reviewed-by:
-
Richard Levitte authored
With the introduction of -pkeyopt, the number of bits may change without |newkey| being updated. Unfortunately, there is no API to retrieve the information from a EVP_PKEY_CTX either, so chances are that we report incorrect information. For the moment, it's better not to try to report the number of bits at all. Fixes #7086 Reviewed-by:
-
Matt Caswell authored
The SSL_client_version() function returns the value held in the legacy_version field of the ClientHello. This is never greater than TLSv1.2, even if TLSv1.3 later gets negotiated. Fixes #7079 Reviewed-by:
-
Matt Caswell authored
Check that we use an RSA certificate if an RSA key exchange ciphersuite is being used and we have both RSA and RSA-PSS certificates configured. Reviewed-by:
-
Matt Caswell authored
If we have selected a ciphersuite using RSA key exchange then we must not attempt to use an RSA-PSS cert for that. Fixes #7059 Reviewed-by:
-
Matt Caswell authored
Add a test to check that we create the correct number of tickets after a TLSv1.3 PSK. Reviewed-by:
-
Matt Caswell authored
Treat a connection using an external PSK like we would a resumption and send a single NewSessionTicket afterwards. Fixes #6941 Reviewed-by:
-
Matt Caswell authored
They did not make it clear how the memory management works for the |pctx| parameter. Fixes #7037 Reviewed-by:
-
Matt Caswell authored
If a client sends data to a server and then immediately closes without waiting to read the NewSessionTickets then the server can receive EPIPE when trying to write the tickets and never gets the opportunity to read the data that was sent. Therefore we ignore EPIPE when writing out the tickets in TLSv1.3 Fixes #6904 Reviewed-by:
-
