summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Document the TLSv1.3 control word, update the description of theschwarze2020-04-111-4/+30
| | | | | | | TLSv1 control word, and explain how TLSv1.3 cipher suites can be configured in LibreSSL and in OpenSSL. While here, also mention how users can inspect the DEFAULT list of cipher suites. Stimulus, feedback and OK from jsing@.
* Include TLSv1.3 cipher suites unless cipher string references TLSv1.3.jsing2020-04-091-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL has always taken the approach of enabling almost everything by default. As a result, if you wanted to run a secure TLS client/server you had to specify your own "secure" cipher string, rather than being able to trust the defaults as being sensible and secure. The problem is that with the introduction of TLSv1.3, most of these "secure" cipher strings result in the new TLSv1.3 cipher suites being excluded. The "work around" for this issue in OpenSSL was to add a new TLSv1.3 API (SSL_CTX_set_ciphersuites(), SSL_set_ciphersuites()) and have separate knobs for the pre-TLSv1.3 and TLSv1.3 cipher suites. This of course means that every application now needs to call two APIs, but it does mean that applications that only call SSL_CTX_set_cipher_list()/SSL_set_cipher_list() cannot remove TLSv1.3 cipher suites and prevent TLSv1.3 from working. We've taken a different approach and have allowed TLSv1.3 cipher suites to be manipulated via the existing SSL_set_cipher_list() API. However, in order to avoid problems with hardcoded cipher strings, change this behaviour so that we always include TLSv1.3 cipher suites unless the cipher string has a specific reference to the TLSv1.3 protocol or a TLSv1.3 cipher suite. This means that: $ openssl ciphers -v TLSv1.2:!TLSv1.3 still gives TLSv1.2 only cipher suites and: $ openssl ciphers -v AEAD-CHACHA20-POLY1305-SHA256 only lists a single TLSv1.3 cipher, however: $ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 now includes both TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 and all TLSv1.3 cipher suites (which also matches OpenSSL's openssl(1) behaviour). Issue encountered by kn@ with mumble. ok tb@
* Tidy line wrapping and remove an extra blank line.jsing2020-04-091-4/+3
|
* ssl_aes_is_accelerated() returns a boolean - treat it as such, rather thanjsing2020-04-091-2/+2
| | | | explicitly comparing against a value.
* Ensure legacy session ID is persistent during client TLS session.jsing2020-04-081-9/+14
| | | | | | | | | | | | Generate an unpredictable 32-byte legacy session ID during client initialisation, rather than when the ClientHello message is being created. Otherwise in the case of a HelloRetryRequest the legacy session ID values will differ between the first and second ClientHello messages, which is not permitted by the RFC. Fixes an issue talking TLSv1.3 to smtp.mail.yahoo.com. ok beck@
* Send a zero-length session identifier if TLSv1.3 is not enabled.jsing2020-04-061-4/+7
| | | | | | | | | If the maximum version is less than TLSv1.3, send a zero-length session identifier (matching the behaviour of the legacy TLS stack), rather than a 32 byte random identifier. The 32 byte random identifier is only needed for "compatibility" mode in TLSv1.3. ok beck@
* Void functions obviously do not return values; no need to elaborate.schwarze2020-03-305-31/+10
| | | | Patch from Martin Vahlensieck <academicsolutions dot ch>.
* Void functions obviously do not return values; no need to elaborate.schwarze2020-03-291-5/+2
| | | | Patch from Martin Vahlensieck <academicsolutions dot ch>.
* Consistently spell 'unsigned' as 'unsigned int', as style(9) seemstb2020-03-167-44/+45
| | | | | | | | | to prefer that. No binary change except in d1_srtp.c where the generated assembly differs only in line numbers (due to a wrapped long line) and in s3_cbc.c where there is no change in the generated assembly. ok inoguchi jsing
* The RFC is clear (section 5.3) that sequence number should never wrap.tb2020-03-161-5/+12
| | | | | | | | | We currently throw an error on overflow, but still wrap. Check up front if we would need to wrap and only increment if that case is excluded. This simplifies the increment loop and makes the returns in this function less magic. ok jsing
* Remove dtls1_enc().jsing2020-03-135-222/+11
| | | | | | | | | | | | | Like much of the original DTLS code, dtls1_enc() is effectively a renamed copy of tls1_enc(). Since then tls1_enc() has been modified, however the non-AEAD code remains largely the same. As such, remove dtls1_enc() and instead call tls1_enc() from the DTLS code. The tls1_enc() AEAD code does not currently work correctly with DTLS, however this is a non-issue since we do not support AEAD cipher suites with DTLS currently. ok tb@
* Correct TLSv1.3 sequence number increment and wrapping check.jsing2020-03-131-3/+3
| | | | Fix proposed by tb@
* Ensure that CBB_add_space() always provides zeroed memory.jsing2020-03-131-1/+2
| | | | ok tb@
* Use calloc() rather than malloc() when allocating initial CBB buffer.jsing2020-03-121-4/+3
| | | | | | | | | | CBB uses recallocarray() to expand buffers, however was still using malloc() for the initial buffer, which could result in memory being leaked in incorrect use cases. While here also use calloc() to allocate internal structs. ok inoguchi@ tb@
* Use calloc() rather than malloc() when allocating buffers.jsing2020-03-121-3/+3
| | | | | | This reduces the chance of accidently leaking stack memory. ok inoguchi@ tb@
* Stop overloading the record type for padding length.jsing2020-03-125-13/+10
| | | | | | | | Currently the CBC related code stuffs the padding length in the upper bits of the type field... stop doing that and add a padding_length field to the record struct instead. ok inoguchi@ tb@
* Use internal versions of SSL3_BUFFER, SSL3_RECORD and DTLS1_RECORD_DATA.jsing2020-03-129-53/+83
| | | | | | | | | SSL3_BUFFER, SSL3_RECORD and DTLS1_RECORD_DATA are currently still in public headers, even though their usage is internal. This moves to using _INTERNAL suffixed versions that are in internal headers, which then allows us to change them without any potential public API fallout. ok inoguchi@ tb@
* Use ctx->hs->secrets rather than the S3I(s) version.jsing2020-03-102-4/+4
| | | | ok inoguchi@ tb@
* Remove some unnecessary handshake enums/functions.jsing2020-03-104-26/+4
| | | | | | | Both session tickets and key updates are post-handshake handshake messages, which were originally included in the handshake code. ok inoguchi@ tb@
* Add a return value check to tls13_buffer_extend().jsing2020-03-101-1/+4
| | | | | | | | | In the unlikely event that the return value from the read callback is larger than the number of bytes we asked for, we can end up incrementing buf->len beyond capacity. Check the return value from the read callback to prevent this. ok inoguchi@ tb@
* Remove the enc function pointers.jsing2020-03-106-22/+12
| | | | | | | The enc function pointers do not serve any purpose these days - remove a layer of indirection and call dtls1_enc()/tls1_enc() directly. ok inoguchi@ tb@
* RFC 8446, section 4.1.3: If a TLSv1.2 client receives a ServerHello fortb2020-03-061-1/+27
| | | | | | | | TLSv1.1 or below, it should check whether the server's random value contains the magic downgrade protection cookie and in that case abort the handshake with an illegal parameter alert. ok inoguchi, jsing
* TLSv1.3 servers that intend to downgrade are required to set the lasttb2020-03-061-4/+8
| | | | | | | | | | | | | eight bytes of the server's random to a magic cookie (RFC 8446, 4.1.3). The TLSv1.3 spec changes the TLSv1.2 spec in that it recommends that TLSv1.2 servers that negotiate TLSv1.1 or below do the same. This gives a limited additional protection against downgrade attacks beyond what is already present in the Finished exchange. The TLSv1.3 part was already implemented in Hobart and can be trivially modified to do the TLSv1.2 bit as well. ok inoguchi, jsing
* The decryption_failed alert must not be sent by compliant implementations.tb2020-02-231-2/+2
| | | | | | | | Use a bad_record_mac alert instead. Found with tlsfuzzer's ChaCha20 test. ok beck inoguchi jsing
* According to RFC 8446, Section 4.4.4, recipients of incorrect Finishedtb2020-02-232-4/+4
| | | | | | | messages must terminate the connection with a decrypt_error alert, so replace the use of the deprecated decryption_failed alert accordingly. ok beck inoguchi jsing
* Remove the s2n macro now that it is finally unused.jsing2020-02-211-4/+1
| | | | ok inoguchi@ tb@
* Convert the SSL/TLS record creation code to CBB.jsing2020-02-211-18/+28
| | | | ok inoguchi@ tb@
* Convert the DTLS header creation code to CBB.jsing2020-02-211-20/+27
| | | | | | | Also consolidate it into the one place, since there is no reason to write the epoch and sequence out later. ok inoguchi@ tb@
* Remove some commented code, remove some pointless comments and move somejsing2020-02-211-17/+6
| | | | | | comments to their correct places. ok inoguchi@ tb@
* Convert dtls1_build_sequence_number() to CBB.jsing2020-02-211-7/+15
| | | | ok inoguchi@ tb@
* Move l2n/l2n8 into s3_cbc.c, since this is the only code that uses it.jsing2020-02-212-16/+16
| | | | ok inoguchi@ tb@
* Remove prefix_len, since it is always zero.jsing2020-02-211-4/+3
| | | | ok inoguchi@ tb@
* Remove now unused variable.jsing2020-02-211-3/+1
| | | | ok inoguchi@ tb@
* Refactor do_ssl3_write().jsing2020-02-191-97/+98
| | | | | | | | | | | | | When empty fragments were added as a countermeasure against chosen plaintext attacks on CBC, it was done by adding a recursive call to do_ssl3_write(). This makes the code more complex and difficult to change. Split the record creation code into a separate ssl3_create_record() function, which do_ssl3_write() calls. In the case where an empty fragment is needed, ssl3_create_record() is simply called twice, removing the need for recursion. ok inoguchi@ tb@
* drop unused include <openssl/curve25519.h>tb2020-02-184-10/+4
| | | | ok inoguchi jsing
* Avoid potential NULL dereference when parsing a server keyshare extension.jsing2020-02-161-1/+4
| | | | | | | | | | | | It is currently possible for key_share to be NULL when a TLS client receives a keyshare extension. However, for this to occur the client has to be doing TLS 1.2 or earlier, which means that it was invalid for the server to send the extension. As such, check for NULL and treat it as an invalid extension. Found by oss-fuzz (#20741 and #20745). ok inoguchi@ tb@
* Avoid leak for tmp.x25519inoguchi2020-02-162-5/+11
| | | | | | | | | | Changed to use local variable to hold malloc address rather than directly set to S3I(s)->tmp.x25519, and set that private_key pointer to S3I(s)->tmp.x25519 after all the "goto err;". Also added freezero for S3I(s)->tmp.x25519 to ssl3_free() and ssl3_clear(). ok jsing@ tb@
* Move the TLSv1.3 code that interfaces with the legacy APIs/stack into ajsing2020-02-153-309/+330
| | | | | | separate file. Discussed with beck@ and tb@
* Remove #include that is not needed.jsing2020-02-151-3/+1
|
* Re-enable the TLSv1.3 client since the known issues have been addressed.jsing2020-02-061-3/+1
| | | | ok tb@
* Add a workaround to make SSL_set_session() work with TLSv1.3.jsing2020-02-061-1/+9
| | | | | | | | While we do not currently do session resumption, just return the TLS_client_method() or TLS_server_method() when asked for a method that does TLSv1.3. ok tb@ (who also arrived at the same diff)
* Add support for handling hello retry requests in the TLSv1.3 client.jsing2020-02-061-5/+100
| | | | | | | | | In the case of a hello retry request, we need to replace the client hello with a synthetic handshake message, switch key share to that selected by the server, build and send a new client hello, then process the resulting server hello. ok tb@
* Correctly handle key share extensions in a hello retry request.jsing2020-02-062-4/+11
| | | | | | | | In a hello retry request the server will only send the selected group and not actually provide a key exchange. In this case we need to store the server selected group for further processing. ok tb@
* Refactor the server hello processing code in the TLSv1.3 client.jsing2020-02-052-22/+46
| | | | | | | | | | | | | Use flags to signal the need to switch to the legacy client and to identify a hello retry request. This allows the caller to take appropriate action, rather than trying to do this in the parsing/processing code. Split the key deriviation and record protection engagement code into a separate function, both for readability and reuse. Change handshake states outside of the processing code. ok tb@
* Remove the hello retry request processing code that was previously added.jsing2020-02-052-65/+16
| | | | | | | This got added to the wrong functions (server side, not client) - swap the now unimplemented send/recv functions between client and server. ok tb@
* Provide tls1_transcript_unfreeze() to avoid the need for manual flagsjsing2020-02-052-3/+10
| | | | | | mangling. ok tb@
* Pull the handshake message transcript code into its own function.jsing2020-02-052-7/+14
| | | | | | This is soon going to be used in the TLSv1.3 client code. ok tb@
* Rework tls13_legacy_handshake_message_{recv,sent}_cb() to usetb2020-02-053-16/+22
| | | | | | their own CBS as a preparation for upcoming HRR diffs. ok jsing
* Add support for TLSv1.3 key shares with secp256r1 and secp384r1 groups.jsing2020-02-041-5/+98
| | | | ok inoguchi@ tb@
* Free the transcript as soon as we initialise the transcript hash.jsing2020-02-042-2/+4
| | | | | | | | Unlike TLSv1.2 there is only a single hash in use, hence as soon as we know what the hash is and have initialised the transcript hash, we can free the transcript buffers. ok inoguchi@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 13:20:38 +0000