- 25 4月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
We were allocating the write buffer based on the size of max_send_fragment, but ignoring it when writing data. We should fragment handshake messages if they exceed max_send_fragment and reject application data writes that are too large. Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3286)
-
- 18 3月, 2017 2 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2918)
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2918)
-
- 16 3月, 2017 3 次提交
-
-
由 Matt Caswell 提交于
Draft-19 changes the HRR transcript hash so that the initial ClientHello is replaced in the transcript with a special synthetic message_hash message that just contains a hash of ClientHello1 as its message body. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2895)
-
由 Matt Caswell 提交于
As per draft-19 Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2895)
-
由 Matt Caswell 提交于
The end of early data is now indicated by a new handshake message rather than an alert. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2895)
-
- 08 3月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
In TLSv1.3 the above messages signal a key change. The spec requires that the end of these messages must align with a record boundary. We can detect this by checking for decrypted but as yet unread record data sitting in OpenSSL buffers at the point where we process the messages. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2875)
-
- 05 3月, 2017 1 次提交
-
-
由 Matt Caswell 提交于
We do not allow the generation of TLSv1.3 cookies. But if we receive one in an HRR we will echo it back in the ClientHello. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2839)
-
- 04 3月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2840)
-
- 03 3月, 2017 9 次提交
-
-
由 Matt Caswell 提交于
This is for consistency with the rest of the API where all the functions are called *early_data*. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
This is for consistency with the rest of the API where all the functions are called *early_data*. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
We provide SSL_write_early() which *must* be called first on a connection (prior to any other IO function including SSL_connect()/SSL_do_handshake()). Also SSL_write_early_finish() which signals the end of early data. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
-
- 28 2月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
This adds partial support for TLS 1.3 certificate request message. The request context and extensions are currently ignored on receive and set to zero length on send. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2728)
-
- 25 2月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2739)
-
- 24 2月, 2017 4 次提交
-
-
由 Kurt Roeckx 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> GH: #1964
-
由 Benjamin Kaduk 提交于
Provide a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. This is akin to BoringSSL's "select_certificate_cb" (though it is not API compatible), and as the name indicates, one major use is to examine the supplied server name indication and select what certificate to present to the client. However, it can also be used to make more sweeping configuration changes to the SSL object according to the selected server identity and configuration. That may include adjusting the permitted TLS versions, swapping out the SSL_CTX object (as is traditionally done in a tlsext_servername_callback), changing the server's cipher list, and more. We also wish to allow an early callback to indicate that it needs to perform additional work asynchronously and resume processing later. To that effect, refactor the second half of tls_process_client_hello() into a subroutine to be called at the post-processing stage (including the early callback itself), to allow the callback to result in remaining in the same work stage for a later call to succeed. This requires allocating for and storing the CLIENTHELLO_MSG in the SSL object to be preserved across such calls, but the storage is reclaimed after ClientHello processing finishes. Information about the CliehtHello is available to the callback by means of accessor functions that can only be used from the early callback. This allows extensions to make use of the existing internal parsing machinery without exposing structure internals (e.g., of PACKET), so that applications do not have to write fragile parsing code. Applications are encouraged to utilize an early callback and not use a servername_callback, in order to avoid unexpected behavior that occurs due to the relative order of processing between things like session resumption and the historical servername callback. Also tidy up nearby style by removing unnecessary braces around one-line conditional bodies. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
-
由 Benjamin Kaduk 提交于
Split off the portions that mutate the SSL object into a separate function that the state machine calls, so that the public API can be a pure function. (It still needs the SSL parameter in order to determine what SSL_METHOD's get_cipher_by_char() routine to use, though.) Instead of returning the stack of ciphers (functionality that was not used internally), require using the output parameter, and add a separate output parameter for the SCSVs contained in the supplied octets, if desired. This lets us move to the standard return value convention. Also make both output stacks optional parameters. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
-
由 Benjamin Kaduk 提交于
Move ssl_bytes_to_cipher_list() to ssl_lib.c and create a public wrapper around it. This lets application early callbacks easily get SSL_CIPHER objects from the raw ciphers bytes without having to reimplement the parsing code. In particular, they do not need to know the details of the sslv2 format ClientHello's ciphersuite specifications. Document the new public function, including the arguably buggy behavior of modifying the supplied SSL object. On the face of it, such a function should be able to be pure, just a direct translation of wire octets to internal data structures. Reviewed-by: NMatt Caswell <matt@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2279)
-
- 17 2月, 2017 4 次提交
-
-
由 Matt Caswell 提交于
Too many KeyUpdate message could be inicative of a problem (e.g. an infinite KeyUpdate loop if the peer always responds to a KeyUpdate message with an "update_requested" KeyUpdate response), or (conceivably) an attack. Either way we limit the number of KeyUpdate messages we are prepared to handle. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2609)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2609)
-
由 Matt Caswell 提交于
This just receives the message. It doesn't actually update any keys yet. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2609)
-
由 Matt Caswell 提交于
This implements the server side KeyUpdate sending capability as well. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2609)
-
- 15 2月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2623)
-
- 14 2月, 2017 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2341)
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2341)
-
- 02 2月, 2017 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2339)
-
- 30 1月, 2017 7 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
This mops up various edge cases with key_shares and makes sure we still generate the handshake secret if we haven't been provided with one but we have a PSK. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
Requires a refactor of the ServerHello parsing, so that we parse first and then subsequently process. This is because the resumption information is held in the extensions block which is parsed last - but we need to know that information earlier. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
This is required for the later addition of resumption support. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
由 Matt Caswell 提交于
The record layer was making decisions that should really be left to the state machine around unexpected handshake messages that are received after the initial handshake (i.e. renegotiation related messages). This commit removes that code from the record layer and updates the state machine accordingly. This simplifies the state machine and paves the way for handling other messages post-handshake such as the NewSessionTicket in TLSv1.3. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2259)
-
- 24 1月, 2017 1 次提交
-
-
由 Cory Benfield 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1646)
-