- 15 3月, 2018 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5520)
-
由 Matt Caswell 提交于
In TLSv1.3 the session is not ready until after the end of the handshake when we are constructing the NewSessionTicket. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5621)
-
- 14 3月, 2018 4 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5392)
-
由 Matt Caswell 提交于
With the current mechanism, old cipher strings that used to work in 1.1.0, may inadvertently disable all TLSv1.3 ciphersuites causing connections to fail. This is confusing for users. In reality TLSv1.3 are quite different to older ciphers. They are much simpler and there are only a small number of them so, arguably, they don't need the same level of control that the older ciphers have. This change splits the configuration of TLSv1.3 ciphers from older ones. By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable them through your existing config. Fixes #5359 Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5392)
-
由 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)
-
由 Matt Caswell 提交于
As of TLSv1.3 draft-25 the record header data must be used as AAD Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5604)
-
- 13 3月, 2018 3 次提交
-
-
由 Tim Hudson 提交于
As per discussion with Peter Sylvester Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5603)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5600)
-
由 Benjamin Saunders 提交于
These functions are similar to SSL_CTX_set_cookie_{generate,verify}_cb, but used for the application-controlled portion of TLS1.3 stateless handshake cookies rather than entire DTLSv1 cookies. Reviewed-by: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5463)
-
- 12 3月, 2018 1 次提交
-
-
由 Todd Short 提交于
Adds application data into the encrypted session ticket Reviewed-by: NPaul Dale <paul.dale@oracle.com> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3802)
-
- 10 3月, 2018 2 次提交
-
-
由 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)
-
由 Todd Short 提交于
Add functions that will do the work of assigning certificate, privatekey and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the publickey. This will permit the keys to pass validation for both ECDSA and RSA. If a private key has already been set for the certificate, it is discarded. A real private key can be set later. This is an all-or-nothing setting of these parameters. Unlike the SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions, the existing cert or privatekey is not modified (i.e. parameters copied). This permits the existing cert/privatekey to be replaced. It replaces the sequence of: * SSL_use_certificate() * SSL_use_privatekey() * SSL_set1_chain() And may actually be faster, as multiple checks are consolidated. The private key can be NULL, if so an ENGINE module needs to contain the actual private key that is to be used. Note that ECDH (using the certificate's ECDSA key) ciphers do not work without the private key being present, based on how the private key is used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead. Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/1130)
-
- 09 3月, 2018 3 次提交
-
-
由 Matt Caswell 提交于
Allow users to distinguish between an error occurring and an HRR being issued. Fixes #5549 Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5562)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5554)
-
由 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)
-
- 08 3月, 2018 1 次提交
-
-
由 FdaSilvaYY 提交于
... and add some missing known values. Sort ssl/tls extension array list Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5304)
-
- 05 3月, 2018 3 次提交
-
-
由 Todd Short 提交于
This fixes an issue raised in PR #4964 by kaduk. Reviewed-by: NBen Kaduk <kaduk@mit.edu> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5491)
-
由 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)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5470)
-
- 01 3月, 2018 2 次提交
-
-
由 Benjamin Kaduk 提交于
When early data support was first added, this seemed like a good idea, as it would allow applications to just add SSL_read_early_data() calls as needed and have things "Just Work". However, for applications that do not use TLS 1.3 early data, there is a negative side effect. Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects derived from it) means that when generating a session ticket, tls_construct_stoc_early_data() will indicate to the client that the server supports early data. This is true, in that the implementation of TLS 1.3 (i.e., OpenSSL) does support early data, but does not necessarily indicate that the server application supports early data, when the default value is nonzero. In this case a well-intentioned client would send early data along with its resumption attempt, which would then be ignored by the server application, a waste of network bandwidth. Since, in order to successfully use TLS 1.3 early data, the application must introduce calls to SSL_read_early_data(), it is not much additional burden to require that the application also calls SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing so closes this scenario where early data packets would be sent on the wire but ignored. Update SSL_read_early_data.pod accordingly, and make s_server and our test programs into applications that are compliant with the new requirements on applications that use early data. Fixes #4725 Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5483)
-
由 Kurt Roeckx 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> GH: #4672
-
- 26 2月, 2018 1 次提交
-
-
由 Tatsuhiro Tsujikawa 提交于
This commit adds SSL_export_keying_material_early() which exports keying material using early exporter master secret. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5252)
-
- 24 2月, 2018 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5439)
-
- 23 2月, 2018 1 次提交
-
-
由 Pauli 提交于
The return at the end isn't reachable. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5442)
-
- 21 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
This could in theory result in an overread - but due to the over allocation of the underlying buffer does not represent a security issue. Thanks to Fedor Indutny for reporting this issue. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NBen Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5414)
-
- 19 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
According to TLSv1.3 draft-24 the record version for ClientHello2 should be TLS1.2, and not TLS1.0 as it is now. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5377)
-
- 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 2 次提交
-
-
由 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)
-
由 Dr. Matthias St. Pierre 提交于
The NIST standard presents two alternative ways for seeding the CTR DRBG, depending on whether a derivation function is used or not. In Section 10.2.1 of NIST SP800-90Ar1 the following is assessed: The use of the derivation function is optional if either an approved RBG or an entropy source provides full entropy output when entropy input is requested by the DRBG mechanism. Otherwise, the derivation function shall be used. Since the OpenSSL DRBG supports being reseeded from low entropy random sources (using RAND_POOL), the use of a derivation function is mandatory. For that reason we change the default and replace the opt-in flag RAND_DRBG_FLAG_CTR_USE_DF with an opt-out flag RAND_DRBG_FLAG_CTR_NO_DF. This change simplifies the RAND_DRBG_new() calls. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5294)
-
- 13 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 12 2月, 2018 2 次提交
-
-
由 Matt Caswell 提交于
We should always check the return code. This fixes a coverity issue. Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5308)
-
由 Matt Caswell 提交于
On the client we calculate the age of the ticket in seconds but the server may work in ms. Due to rounding errors we could overestimate the age by up to 1s. It is better to underestimate it. Otherwise, if the RTT is very short, when the server calculates the age reported by the client it could be bigger than the age calculated on the server - which should never happen. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5306)
-
- 10 2月, 2018 1 次提交
-
-
由 Bernd Edlinger 提交于
the possibly indeterminate pointer value in wpend_buf. Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5305)
-
- 09 2月, 2018 1 次提交
-
-
由 Matt Caswell 提交于
In <= TLSv1.2 a Finished message always comes immediately after a CCS except in the case of NPN where there is an additional message between the CCS and Finished. Historically we always calculated the Finished MAC when we processed the CCS. However to deal with NPN we also calculated it when we receive the Finished message. Really this should only have been done if we hand negotiated NPN. This simplifies the code to only calculate the MAC when we receive the Finished. In 1.1.1 we need to do it this way anyway because there is no CCS (except in middlebox compat mode) in TLSv1.3. Coincidentally, this commit also fixes the fact that no-nextprotoneg does not currently work in master. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5285)
-
- 03 2月, 2018 3 次提交
-
-
由 Tatsuhiro Tsujikawa 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4944)
-
由 Tatsuhiro Tsujikawa 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4944)
-
由 Tatsuhiro Tsujikawa 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4944)
-
- 02 2月, 2018 3 次提交
-
-
由 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 提交于
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)
-