- 15 3月, 2018 1 次提交
-
-
由 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
-
- 14 12月, 2017 3 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4701)
-
由 Matt Caswell 提交于
The CCS may be sent at different times based on whether or not we sent an HRR earlier. In order to make that decision this commit also updates things to make sure we remember whether an HRR was used or not. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4701)
-
由 Matt Caswell 提交于
The new ServerHello format is essentially now the same as the old TLSv1.2 one, but it must additionally include supported_versions. The version field is fixed at TLSv1.2, and the version negotiation happens solely via supported_versions. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4701)
-
- 04 12月, 2017 3 次提交
-
-
由 Matt Caswell 提交于
Follow up from the conversion to use SSLfatal() in the state machine to clean things up a bit more. [extended tests] Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4778)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4778)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4778)
-
- 22 11月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
SNI needs to be consistent before we accept early_data. However a server may choose to not acknowledge SNI. In that case we have to expect that a client may send it anyway. We change the consistency checks so that not acknowledging is treated more a like a "wild card", accepting any SNI as being consistent. Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4738)
-
- 06 11月, 2017 1 次提交
-
-
由 FdaSilvaYY 提交于
Based on patch from Tomasz Moń: https://groups.google.com/forum/#!topic/mailing.openssl.dev/fQxXvCg1uQYReviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/1008)
-
- 30 10月, 2017 1 次提交
-
-
由 Benjamin Kaduk 提交于
We currently increment the SSL_CTX stats.sess_accept field in tls_setup_handshake(), which is invoked from the state machine well before ClientHello processing would have had a chance to switch the SSL_CTX attached to the SSL object due to a provided SNI value. However, stats.sess_accept_good is incremented in tls_finish_handshake(), and uses the s->ctx.stats field (i.e., the new SSL_CTX that was switched to as a result of SNI processing). This leads to the confusing (nonsensical) situation where stats.sess_accept_good is larger than stats.sess_accept, as the "sess_accept" value was counted on the s->session_ctx. In order to provide some more useful numbers, increment s->ctx.stats.sess_accept after SNI processing if the SNI processing changed s->ctx to differ from s->session_ctx. To preserve the property that any given accept is counted only once, make the corresponding decrement to s->session_ctx.stats.sess_accept when doing so. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/4549)
-
- 16 10月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
Previously if a client received an HRR then we would do version negotiation immediately - because we know we are going to get TLSv1.3. However this causes a problem when we emit the 2nd ClientHello because we start changing a whole load of stuff to ommit things that aren't relevant for < TLSv1.3. The spec requires that the 2nd ClientHello is the same except for changes required from the HRR. Therefore the simplest thing to do is to defer the version negotiation until we receive the ServerHello. Fixes #4292 Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4527)
-
- 12 10月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
Fixes #4496 Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/4519)
-
- 06 10月, 2017 2 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4475)
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4475)
-
- 04 10月, 2017 1 次提交
-
-
由 Todd Short 提交于
When an SSL's context is swtiched from a ticket-enabled context to a ticket-disabled context in the servername callback, no session-id is generated, so the session can't be resumed. If a servername callback changes the SSL_OP_NO_TICKET option, check to see if it's changed to disable, and whether a session ticket is expected (i.e. the client indicated ticket support and the SSL had tickets enabled at the time), and whether we already have a previous session (i.e. s->hit is set). In this case, clear the ticket-expected flag, remove any ticket data and generate a session-id in the session. If the SSL hit (resumed) and switched to a ticket-disabled context, assume that the resumption was via session-id, and don't bother to update the session. Before this fix, the updated unit-tests in 06-sni-ticket.conf would fail test #4 (server1 = SNI, server2 = no SNI). Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/1529)
-
- 26 9月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Rename tls1_get_curvelist to tls1_get_grouplist, change to void as it can never fail and remove unnecessary return value checks. Clean up the code. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/=4412)
-
- 23 9月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Instead of storing supported groups in on-the-wire format store them as parsed uint16_t values. This simplifies handling of groups as the values can be directly used instead of being converted. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4406)
-
- 07 9月, 2017 1 次提交
-
-
由 Benjamin Kaduk 提交于
In OpenSSL 1.1.0, when there were no extensions added to the ServerHello, we did not write the extension data length bytes to the end of the ServerHello; this is needed for compatibility with old client implementations that do not support TLS extensions (such as the default configuration of OpenSSL 0.9.8). When ServerHello extension construction was converted to the new extensions framework in commit 7da160b0, this behavior was inadvertently limited to cases when SSLv3 was negotiated (and similarly for ClientHellos), presumably since extensions are not defined at all for SSLv3. However, extensions for TLS prior to TLS 1.3 have been defined in separate RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such should be considered an optional protocol feature in those cases. Accordingly, be conservative in what we send, and skip the extensions block when there are no extensions to be sent, regardless of the TLS/SSL version. (TLS 1.3 requires extensions and can safely be treated differently.) Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/4296)
-
- 31 8月, 2017 3 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/3926)
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/3926)
-
由 Matt Caswell 提交于
Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/3926)
-
- 30 8月, 2017 1 次提交
-
-
由 Pauli 提交于
Removed e_os.h from all bar three headers (apps/apps.h crypto/bio/bio_lcl.h and ssl/ssl_locl.h). Added e_os.h into the files that need it now. Directly reference internal/nelem.h when required. Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4188)
-
- 18 8月, 2017 1 次提交
-
-
由 Todd Short 提交于
Force non-empty padding extension. When enabled, force the padding extension to be at least 1 byte long. WebSphere application server cannot handle having an empty extension (e.g. EMS/EtM) as the last extension in a client hello. This moves the SigAlgs extension last for TLSv1.2 to avoid this issue. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3921)
-
- 15 8月, 2017 1 次提交
-
-
由 Benjamin Kaduk 提交于
Commit 02f0274e moved ALPN processing into an extension finalization function, as the only documented ordering requirement from previous commits was that ALPN processing occur after SNI processing, and SNI processing is performed before the extension finalization step. However, it is useful for applications' alpn_select callbacks to run after ciphersuite selection as well -- at least one application protocol specification (HTTP/2) imposes restrictions on which ciphersuites are usable with that protocol. Since it is generally more preferrable to have a successful TLS connection with a default application protocol than to fail the TLS connection and not be able to have the preferred application protocol, it is good to give the alpn_select callback information about the ciphersuite to be used, so that appropriate restrctions can be enforced in application code. Accordingly, split the ALPN handling out into a separate tls_handl_alpn() function akin to tls_handle_status_request(), called from tls_post_process_client_hello(). This is an alternative to resuscitating ssl_check_clienthello_tlsext_late(), something of an awkwward name itself. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4070)
-
- 11 8月, 2017 1 次提交
-
-
由 FdaSilvaYY 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4108)
-