- 22 11月, 2019 1 次提交
-
-
由 Benjamin Kaduk 提交于
As was done for ciphers, supported groups, and EC point formats in https://github.com/openssl/openssl/pull/9162, only write the negotiated SNI hostname value to the session object when not resuming, even for TLS 1.3 resumptions. Otherwise, when using a stateful session cache (as is done by default when 0-RTT data is enabled), we can have multiple SSLs active using the same in-memory session object, which leads to double-frees and similar race conditions in the SNI handler prior to this commit. Fortunately, since draft-ietf-tls-tls13-22, there is no requirement that the SNI hostname be preserved across TLS 1.3 resumption, and thus not a need to continually update the session object with the "current" value (to be used when producing session tickets, so that the subsequent resumption can be checked against the current value). So we can just relax the logic and only write to the session object for initial handshakes. This still leaves us in a somewhat inconsistent state, since if the SNI value does change across handshakes, the session object will continue to record the initial handshake's value, even if that bears no relation to the current handshake. The current SSL_get_servername() implementation prefers the value from the session if s->hit, but a more complete fix for that and related issues is underway in https://github.com/openssl/openssl/pull/10018; there is no need to wait for the complete fix for SNI name handling in order to close the race condition and avoid runtime crashes. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10441) (cherry picked from commit 2a5385511051d33be8d2b20d7669d8b1862fe510)
-
- 12 11月, 2019 1 次提交
-
-
由 Ido Ben-Natan 提交于
The resumption_label variable when CHARSET_EBCDIC was enabled, was misspelled. Instead of evaluating to 'res binder' as expected, it evaluated to 'red binder'. CLA: trivial Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/10396) (cherry picked from commit 6ed12cec7216c3e81b58f5cafa41775e456feaee)
-
- 28 9月, 2019 1 次提交
-
-
由 Dr. Matthias St. Pierre 提交于
Apart from public and internal header files, there is a third type called local header files, which are located next to source files in the source directory. Currently, they have different suffixes like '*_lcl.h', '*_local.h', or '*_int.h' This commit changes the different suffixes to '*_local.h' uniformly. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9681)
-
- 14 8月, 2019 1 次提交
-
-
由 opensslonzos-github 提交于
Fix a few places where calling ossl_isdigit does the wrong thing on EBCDIC based systems. Replaced with ascii_isdigit. Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9556) (cherry picked from commit 48102247ff513d4c57b40b19c1d432f37b9e4b02)
-
- 01 8月, 2019 1 次提交
-
-
由 raja-ashok 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9471) (cherry picked from commit 59b2cb2638dda3e07385ad36a41f0e141b36987b)
-
- 18 6月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
The previous 2 commits moved supported groups and ciphers out of the session object to avoid race conditions. We now also move ecpointformats for consistency. There does not seem to be a race condition with access to this data since it is only ever set in a non-resumption handshake. However, there is no reason for it to be in the session. Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9176)
-
- 05 3月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
Sessions must be immutable once they can be shared with multiple threads. We were breaking that rule by writing the ticket index into it during the handshake. This can lead to incorrect behaviour, including failed connections in multi-threaded environments. Reported by David Benjamin. Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8383) (cherry picked from commit c96ce52ce293785b54a42d119c457aef739cc2ce)
-
- 26 2月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8347)
-
- 07 1月, 2019 1 次提交
-
-
由 Matt Caswell 提交于
The cryptopro extension is supposed to be unsolicited and appears in the ServerHello only. Additionally it is unofficial and unregistered - therefore we should really treat it like any other unknown extension if we see it in the ClientHello. Fixes #7747 Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7984) (cherry picked from commit 23fed8ba0ec895e1b2a089cae380697f15170afc)
-
- 06 1月, 2019 1 次提交
-
-
由 Dmitry Belyavskiy 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7985) (cherry picked from commit 673e0bbbe4b9cbd19a247c0b18c171bb0421915a)
-
- 05 12月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Fix some issues in tls13_hkdf_expand() which impact the above function for TLSv1.3. In particular test that we can use the maximum label length in TLSv1.3. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7755) (cherry picked from commit 0fb2815b873304d145ed00283454fc9f3bd35e6b)
-
- 12 11月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0. If it was called on the client side then it was ignored. In 1.1.1 it now makes sense to have a CA list defined for both client and server (the client now sends it the the TLSv1.3 certificate_authorities extension). Unfortunately some applications were using the same SSL_CTX for both clients and servers and this resulted in some client ClientHellos being excessively large due to the number of certificate authorities being sent. This commit seperates out the CA list updated by SSL(_CTX)?_set_client_CA_list() and the more generic SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list() still has no effect on the client side. If both CA lists are set then SSL(_CTX)?_set_client_CA_list() takes priority. Fixes #7411 Reviewed-by: NViktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7503) (cherry picked from commit 98732979001dbb59320803713c4c91ba40234250)
-
- 04 11月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
Commit 9ef9088c switched the SSL/SSL_CTX statistics counters to using Thread-Sanitizer-friendly primitives. However, it erroneously converted an addition of -1 (for s->session_ctx->stats.sess_accept) to an addition of +1, since that is the only counter API provided by the internal tsan_assist.h header until the previous commit. This means that for each accepted (initial) connection, the session_ctx's counter would get doubly incremented, and the (switched) ctx's counter would also get incremented. Restore the counter decrement so that each accepted connection increments exactly one counter exactly once (in net effect). Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7464) (cherry picked from commit 2aaa0b146b967397a6e61fa8df969e7847f82086)
-
- 29 10月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/7194) (cherry picked from commit 60690b5b8396d7d5234cd067206190fb8aca78d2)
-
- 08 9月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
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: NTim Hudson <tjh@openssl.org> Reviewed-by: NViktor Dukhovni <viktor@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/7149)
-
- 07 9月, 2018 1 次提交
-
-
由 Ben Kaduk 提交于
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: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7115)
-
- 22 8月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
We need to ensure that the min-max version range we use when constructing the ClientHello is the same range we use when we validate the version selected by the ServerHello. Otherwise this may appear as a fallback or downgrade. Fixes #6964 Reviewed-by: NViktor Dukhovni <viktor@openssl.org> (Merged from https://github.com/openssl/openssl/pull/7013)
-
- 07 8月, 2018 1 次提交
-
-
由 Andy Polyakov 提交于
Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6786)
-
- 20 7月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
In particular, adhere to the rule that we must not modify any property of an SSL_SESSION object once it is (or might be) in a session cache. Such modifications are thread-unsafe and have been observed to cause crashes at runtime. To effect this change, standardize on the property that SSL_SESSION->ext.hostname is set only when that SNI value has been negotiated by both parties for use with that session. For session resumption this is trivially the case, so only new handshakes are affected. On the client, the new semantics are that the SSL->ext.hostname is for storing the value configured by the caller, and this value is used when constructing the ClientHello. On the server, SSL->ext.hostname is used to hold the value received from the client. Only if the SNI negotiation is successful will the hostname be stored into the session object; the server can do this after it sends the ServerHello, and the client after it has received and processed the ServerHello. This obviates the need to remove the hostname from the session object in case of failed negotiation (a change that was introduced in commit 9fb6cb81 in order to allow TLS 1.3 early data when SNI was present in the ClientHello but not the session being resumed), which was modifying cached sessions in certain cases. (In TLS 1.3 we always produce a new SSL_SESSION object for new connections, even in the case of resumption, so no TLS 1.3 handshakes were affected.) Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6378)
-
- 02 7月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NViktor Dukhovni <viktor@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6469)
-
- 11 6月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
TLSv1.3 ignores the alert level, so we should suppress sending of warning only alerts. Fixes #6211 Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6370)
-
- 07 6月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
All tickets on a connection need to have a unique nonce. When this was originally implemented we only ever sent one ticket on the conneciton so this didn't matter. We were just using the value 0. Now we can get multiple tickets to we need to start doing the ticket nonce properly. Fixes #6387 Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6415)
-
- 31 5月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Fix some instances where we weren't checking the error return. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6373)
-
- 15 3月, 2018 2 次提交
-
-
由 Matt Caswell 提交于
Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per feedback. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5520)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5520)
-
- 14 3月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
As per the latest text in TLSv1.3 draft-26 Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5604)
-
- 10 3月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
At the core of things is the concept that each extension is only defined in certain context(s) -- the ClientHello, EncryptedExtensions, etc., and sometimes only for a specific protocol or protocol range; we want to enforce that we only parse or generate extensions in the context(s) for which they are defined. There is some subtlety here, in that the protocol version in use is not known when generating the ClientHello (but it is known when the ClientHello extensions are being parsed!), so the SSL_IS_TLS13() macro must be used with caution. Nonetheless, by making assertions about whether we are acting in a server role and whether the current context is (not) a ClientHello, we can consolidate almost all of the logic for determining whether an extension is permitted in a given protocol message, whether we are generating or parsing that message. The only logic that remains separate relates to generating the ClientHello, as it depends on an external factor (the maximum permitted TLS version) that is not defined in the parsing context. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2945)
-
- 09 3月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
We also default to SHA256 as per the spec if we do not have an explicit digest defined. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5554)
-
- 05 3月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
They are valid for use in a CertificateRequest message, but we did not allow it. If a server sent such a message using either of those two extensions then the handshake would abort. This corrects that error, but does not add support for actually processing the extensions. They are simply ignored, and a TODO is inserted to add support at a later time. This was found during interoperability testing with btls: https://gitlab.com/ilari_l/btls Prompted by these errors I reviewed the complete list of extensions and compared them with the latest table in draft-24 to confirm there were no other errors of a similar type. I did not find any. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5490)
-
- 15 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Coverity was complaining because we checked if s->ctx is NULL and then later on in the function deref s->ctx anyway. In reality if s->ctx is NULL then this is an internal error. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5334)
-
- 14 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
The s_client psk_use_session_cb callback has a comment stating that we should ignore a key that isn't suitable for TLSv1.3. However we were actually causing the connection to fail. Changing the return value fixes the issue. Also related to this is that the early_data extension was not marked as TLSv1.3 only which it should be. Fixes #5202 Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5205)
-
- 02 2月, 2018 2 次提交
-
-
由 Todd Short 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4964)
-
由 Todd Short 提交于
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: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4964)
-
- 26 1月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
The new extension is like signature_algorithms, but only for the signature *on* the certificate we will present to the peer (the old signature_algorithms extension is still used for signatures that we *generate*, i.e., those over TLS data structures). We do not need to generate this extension, since we are the same implementation as our X.509 stack and can handle the same types of signatures, but we need to be prepared to receive it, and use the received information when selecting what certificate to present. There is a lot of interplay between signature_algorithms_cert and signature_algorithms, since both affect what certificate we can use, and thus the resulting signature algorithm used for TLS messages. So, apply signature_algorithms_cert (if present) as a filter on what certificates we can consider when choosing a certificate+sigalg pair. As part of this addition, we also remove the fallback code that let keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled the key type into what is covered by the signature algorithm, so we should not apply this sort of compatibility workaround. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5068)
-
- 25 1月, 2018 3 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4435)
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4435)
-
由 Matt Caswell 提交于
This just adds the various extension functions. More changes will be required to actually use them. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4435)
-
- 09 1月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5038)
-
- 03 1月, 2018 1 次提交
-
-
由 Benjamin Kaduk 提交于
Although this is forbidden by all three(!) relevant specifications, there seem to be multiple server implementations in the wild that send it. Since we didn't check for unexpected extensions in any given message type until TLS 1.3 support was added, our previous behavior was to silently accept these extensions and pass them over to the custom extension callback (if any). In order to avoid regression of functionality, relax the check for "extension in unexpected context" for this specific case, but leave the protocol enforcment mechanism unchanged for other extensions and in other extension contexts. Leave a detailed comment to indicate what is going on. Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4463)
-
- 18 12月, 2017 1 次提交
-
-
由 Paul Yang 提交于
Reviewed-by: NKurt Roeckx <kurt@roeckx.be> Reviewed-by: NMatt Caswell <matt@openssl.org> GH: #4934
-