summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove stale SECURE RENEGOTIATION referencekenjiro2026-07-171-5/+3
| | | | | | | | | SSL_CTX_set_options(3) no longer has a SECURE RENEGOTIATION section, but SSL_OP_LEGACY_SERVER_CONNECT still referenced it. Replace the dangling cross reference with a note that the option is no longer set by default. ok tb@ beck@
* Make dtls1_do_write_ccs() self contained.jsing2026-07-161-4/+5
| | | | | | | | A ChangeCipherSpec message is always the same single byte. Make dtls1_do_write_ccs() know how to send this message, which avoids the use of buffers and needing to keep copies for retransmission. ok kenjiro@ tb@
* Clean up sequence number and message header handling.jsing2026-07-162-26/+13
| | | | | | | | | | | dtls1_set_message_header() is only called in one place - inline the write handshake sequence number handling. Rename dtls1_set_message_header_int() to dtls1_set_message_header(). The dtls12_write_ccs() code does not use handshake sequence numbers (since they're not handshake messages) - stop pretending that it does. ok kenjiro@ tb@
* Check that the server selected ciphersuite is valid for use with TLSv1.2.jsing2026-07-151-1/+10
| | | | | | | | | | In the legacy stack, ensure that the server selected ciphersuite is valid for use with TLSv1.2 - this effectively means that it is not a TLSv1.3 ciphersuite. We currently fail the handshake, but at a later stage. Reported by Tom Gouville from the tlspuffin team. ok tb@
* Remove check for use of TLSv1.2 ciphersuites with TLSv1.1 and earlier.jsing2026-07-151-9/+1
| | | | | | | We no longer negotiate any TLS version lower than TLSv1.2, so this is now redundant. ok tb@
* SSL_alert_desc_string: update manpage after change to return "!!" alwaystb2026-06-221-39/+36
| | | | | Also change some totally unreadable roff macros to slightly less unreadable mdoc markup.
* Correct secondary key share handling for HelloRetryRequests.jsing2026-06-141-2/+12
| | | | | | | | | | With the introduction of a secondary key share, we fail to ensure that the HelloRetryRequest does not specify the group that was used for the secondary key share. We also fail to free the secondary key share early in this case, meaning that it lingers in memory until the SSL is reset or freed. Fix both of these issues. ok tb@
* Improve TLSv1.3 server handling of no shared groups.jsing2026-06-141-6/+17
| | | | | | | | | | | | | | | While we currently correctly handle the no-shared-group case, it currently fails late when we try to create the key share. Improve detection and handling so that we fail sooner and send an alert to the client when processing client key shares. While here rename preferred_group_found to shared_group_found - we look for the client preferred group, but any group that we select will always be in the client list (even if it's the last one). Reported by the tlspuffin team. ok tb@
* Send illegal parameter alerts for various HelloRetryRequest violations.jsing2026-06-141-6/+10
| | | | | | | | | | | Be more RFC compliant and send illegal parameter alerts when the client receives a HelloRetryRequest that requests a group that we did not offer or a group that we sent a key share for in the ClientHello. These were annotated as missing, but not previously implemented. Prompted by a report from the tlspuffin team. ok tb@
* Mop up SSL_CTX_set_options(3).jsing2026-06-141-89/+5
| | | | | | | | | SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is now a no-op, tidy up SSL_OP_LEGACY_SERVER_CONNECT and reflect the current state of SSL_OP_ALL Delete the entire "SECURE RENEGOTIATION" section that contained ancient ramblings. ok beck@ tb@
* Remove SSL_OP_LEGACY_SERVER_CONNECT from default options.jsing2026-06-142-9/+4
| | | | | | | | | | | | Remove SSL_OP_LEGACY_SERVER_CONNECT from the default SSL options and the SSL_OP_ALL define. This means that we will now refuse to connect to a TLSv1.2 server if it does not support the Renegotiation Indication (RI) extension. This prevents a class of attacks against TLS clients that are talking to TLSv1.2-only servers that permit client initiated renegotiation. Raised by Lucca Hirschi et al from Inria. ok beck@ tb@
* tlsext: add XXX to consider refusing anything but uncompressed point formattb2026-06-081-1/+3
| | | | ok jsing kenjiro
* ssl_kex: ensure the public key uses uncompressed encodingtb2026-06-081-2/+22
| | | | | | | | | | | | | | | | | | | EC_POINT_oct2point() does most of the validation we need it to do, but it has to accept the point at infinity, compressed and hybrid encodings for historic reasons. So exclude these cases: the point at infinity makes no sense here and will be caught later in ECDH_compute_key(), the compressed and hybrid encodings MUST NOT be supported per RFC 8422 section 5.1.2. This is implemented using the strategy already used in ec_convert.c since the point_conversion_form_t is completely unfit for anything. Set decode_error to ensure we send that alert. We may make some effort to use illegal_parameter later. Issue about the missing alert and the point at infinity raised by Lucca Hirschi et al. ok jsing kenjiro
* Add a decode_error argument to ssl_kex_peer_public_ecdhe_ecp()tb2026-06-083-8/+11
| | | | ok jsing kenjiro
* ssl_kex: include ssl_local.htb2026-06-071-1/+2
|
* Correctly handle failure to buffer DTLS messages.jsing2026-06-061-3/+5
| | | | | | | If we fail to buffer an outgoing DTLS message, we're not going to be able to retransmit it. Correctly propagate the failure. ok kenjiro@ tb@
* Move DTLS change cipher spec handling to its own function.jsing2026-06-064-14/+22
| | | | | | | | When a TLSv1.2 change cipher spec message has been built, call a separate function that can handle the DTLS specific processing rather than including this in the TLS code. ok kenjiro@ tb@
* Move DTLS handshake message handling to its own function.jsing2026-06-063-14/+30
| | | | | | | | When a TLSv1.2 handshake message has been built, call a separate function that can handle the DTLS specific processing rather than including this in the TLS code. ok kenjiro@ tb@
* Remove ssl3_handshake_msg_hdr_len()jsing2026-06-062-11/+3
| | | | | | | This function is only called in one location, which is always a DTLS context - use DTLS1_HM_HEADER_LENGTH directly instead. ok kenjiro@ tb@
* libssl: don't break TLSv1.2 with X25519MLKEM768tb2026-06-062-3/+30
| | | | | | | | | | | | | | | | | | | | If the list of 'groups' starts with X25519MLKEM768 for a TLSv1.2 server, ssl3_send_server_kex_ecdhe() attempts to use NID_X25519MLKEM768, which it receives from tls1_get_supported_groups(). This does not work because it never received the peer's public keys, which causes an error return from tls_key_share_server_generate_mlkem768x25519(). For a TLSv1.2-only client with custom supported group list we will currently send ML-KEM if configured. We should not do this. There is more to fix here: if a TLSv1.2 client is misconfigured with only X25519MLKEM768, we should not send a supported groups extension (with this commit we'll send an empty one, which is an RFC violation). This commit simply filters X25519MLKEM768 out of the supported groups list if we're configured to be TLSv1.2-only. feedback/ok jsing kenjiro (on an earlier version)
* Drop gcc3 -Wunininitialized workaroundtb2026-06-041-2/+2
| | | | discussed with miod
* libssl: const correct ssl_*version* APItb2026-06-042-18/+21
| | | | | | | None of these functions modifies the SSL pointer. An upcoming diff will need to call one of them with a const pointer, so fix all of them. ok jsing kenjiro
* Clean up signature algorithm handling.jsing2026-05-315-261/+66
| | | | | | | | | | | Now that we no longer support TLSv1.0 and TLSv1.1, SSL_USE_SIGALGS() is always true - remove all of the code that handles the non-sigalgs path, along with SSL_USE_SIGALGS() and the related flags. Also remove SIGALG_RSA_PKCS1_MD5_SHA1 and references to it, since this is also now unused. ok kenjiro@ tb@
* remove prototype for removed dtls1_get_cipher()jsg2026-05-251-2/+1
| | | | ok jsing@
* Remove unused prototype.jsing2026-05-251-2/+1
|
* Introduce and use dtls12_handshake_msg.jsing2026-05-166-77/+363
| | | | | | | | | | | | | | | | | | | Add struct dtls12_handshake_msg and various related functions, which allow for the construction of DTLS handshake messages and associated fragments. Use this on the DTLS write path for sending handshake message fragments. This means that we no longer modify the init buffer, which also fixes a bug where the message callback is called with a corrupted handshake message when multiple fragments have been sent. We also now correctly track fragment offsets when sending a handshake message that results in multiple calls to dtls1_do_write_handshake_message(). This is the first step towards further untangling of the write path in the legacy TLS stack. ok kenjiro@ tb@
* libssl: record extension lengths in ClientHello hashingtb2026-05-091-1/+4
| | | | | | | | | | | | | | | | The ClientHello hash is intended to ensure that the second CH after an HRR only makes the allowed changes to the TLS extensiosn by recording message type followed by the raw extension data if it must remain unchanged. This makes it possible (in principle) that part of free form extension data is confused with type (and length) information of a subsequent extension. Recording the length after the type prevents such a confusion and fixes the framing of the extensions. Found by Frank Denis ok jsing
* ssl_lib: trade two extra empty lines for a missing onetb2026-05-091-4/+2
|
* Get rid of struct dtls1_retransmit_state.jsing2026-05-062-26/+10
| | | | | | | | | | | | | In order to retransmit DTLS messages we potentially need to use the record protection from a previous epoch. However, DTLS currently also saves and restores the session, which is unnecessary - all of the record protection and keys are handled in the TLS record layer. Remove the rather useless dtls1_retransmit_state struct and just keep the epoch - keeping pointers hanging around to sessions is pretty nasty and unnecessary. ok kenjiro@ tb@
* Avoid use of uninitialised decode_error variable.jsing2026-05-061-10/+14
| | | | | | | | | | | | | | | | | | Pull initialisation of decode_error and invalid_key up to tls_key_share_{client,server}_peer_public(), which are the entry points for the key share code. The entry point was previously tls_key_share_peer_public(), however with the introduction of MLKEM this was split into separate client and server functions, without the initialisation being included. Also initialise decode_error and invalid_params on entry to tls_key_share_peer_params(). Code that reaches tls_key_share_client_peer_public_mlkem768x25519() could previously result in code branching based on decode_error, which is uninitialised stack based memory. Thanks to Guido Vranken of Aisle Research for reporting this issue. With and ok tb@
* Refactor dtls1_do_write_handshake_message().jsing2026-04-301-43/+44
| | | | | | | | If the call to dtls1_write_bytes() fails, handle the potential MTU update and return/continue, which allows for the remainder to be moved out of an else statement. ok kenjiro@ tb@
* Split dtls1_do_write() into handshake message and CCS handling.jsing2026-04-291-33/+59
| | | | | | | | | | | | dtls1_do_write() is currently a single function that handles both handshake messages and CCS. This is a strange mix that only serves to complicate the code - handshake messages have their own headers and may need to be fragmented, while CCS must be sent verbatim (and only contain a single byte). Pull the CCS part out into a separate function, simplifying the code. By definition, when sending a CCS message the MTU will already be set appropriately. ok kenjiro@ tb@
* Avoid unnecessary lookups in dtls1_retransmit_message().jsing2026-04-291-37/+6
| | | | | | | | | | dtls1_retransmit_buffered_messages() is iterating over the sent_messages pqueue, only to pass dtls1_retransmit_message() a sequence number that it turns back into a priority, to then do a lookup on the sent_messages pqueue. This is pointless given that we already have the message that we need to retransmit - just pass that to dtls1_retransmit_message() directly. ok kenjiro@ tb@
* Remove unused frag_off argument from dtls1_retransmit_message().jsing2026-04-291-4/+3
| | | | ok kenjiro@ tb@
* Make dtls1_retransmit_message() static.jsing2026-04-292-78/+76
| | | | | | | This function is only called from dtls1_retransmit_buffered_messages(). Make it static and move it above the caller. ok kenjiro@ tb@
* Inline dtls1_fix_message_header().jsing2026-04-291-16/+5
| | | | | | | | This is only used in one place and it makes no sense to have it as a separate function. Furthermore, pull up an assertion so that we check before assigning frag_len. ok kenjiro@ tb@
* Convert DTLS code to ssl_msg_callback().jsing2026-04-291-14/+7
| | | | ok kenjiro@ tb@
* Remove lib/libssl/test.jsing2026-04-0353-4409/+0
| | | | | | This is all unhelpful historical cruft. Discussed with tb@
* Remove workaround for SSL 3.0/TLS 1.0 CBC vulnerability.jsing2026-04-035-80/+8
| | | | | | | | We no longer support TLSv1.0 and definitely do not support SSLv3 - remove the empty fragments workaround for the CBC vulnerability in these protocols. ok kenjiro@ tb@
* Ensure that we cannot negotiate TLSv1.1 or lower.jsing2026-04-033-13/+21
| | | | | | | | | TLS versions prior to TLSv1.2 were disabled a while ago, however this was done in the version handling code. Remove TLSv1.1 and earlier from ssl_get_method() and add an explicit min version check in the legacy client and server, to provide a stronger guarantee. ok kenjiro@ tb@
* Remove ssl_server_legacy_first_packet()jsing2026-04-033-97/+2
| | | | | | | | | This has not been reachable since we made the TLSv1.3 stack the default entry point - tls13_record_layer_read_record() will send a protocol version alert and raise an error, which means we never transition into the legacy stack. ok kenjiro@
* Mop up mac_packet.jsing2026-04-034-15/+8
| | | | | | This is a left over from when we accepted SSLv2 ClientHello messages. ok kenjiro@
* libssl: announce support for RSASSA-PSS signature schemestb2026-03-301-1/+7
| | | | | | | | | | | | | | | Announce the signature schemes for RSASSA-PSS with pubkey OID RSASSA-PSS between RSASSA-PSS with pubkey OID rsaEncryption and RSASSA-PKCS1-v1_5. This is the last step in the everlasting saga for making these signature schemes and certificates with RSASSA-PSS OID work. Fortunately, these are rarely used since they are extremely complex and inefficient also due to the large size of the parameters. This addresses bug reports by Steffen Ullrich and Tom Lane. Tested by bluhm. ok djm jsing kenjiro
* ssl_sigalg_pkey_ok: allow RSASSA-PSS with pubkey OID RSASSA-PSStb2026-03-301-5/+6
| | | | | | | | | | | | This fixes a long-standing logic error that hasn't been noticed because we never announced the rsa_pss_pss_sha{256,384,512} SignatureScheme. The EVP_PKEY_id() of a RSA-PSS pubkey is EVP_PKEY_RSA_PSS, not EVP_PKEY_RSA. Thanks to beck for helping me figure out how to fix this correctly. It drove me nuts for a very long time. Problem also noticed by Tom Lane due to some PostgreSQL regress failures. ok djm jsing kenjiro
* ssl_sigalgs: whitespace tweaktb2026-03-301-1/+2
|
* Rename RANK{768,1024} to MLKEM{768,1024}_RANKtb2026-01-011-3/+3
| | | | | | | | | RANK768 and RANK1024 are awfully short and generic names for public constants. Before we make it worse with similarly named constants for ML-DSA, let's fix this. This follows the naming convention used by the other macros in the mlkem code. ok kenjiro jsing
* Hook up X25519MKLEM768 to the TLS 1.3 handshakebeck2025-12-045-39/+100
| | | | | | | | | | | | | | | | | | | | | | | | This does the following: 1) Adds a second key share prediction to the TLS 1.3 handshake. We only add one as we are unlikely to want to send more than one PQ one, and one classical one and are unlikely to waste bytes on a second PQ algorithm (anything that wants something else that we support can HRR to get it) 2) Adds X25519MLKEM768 (4588) to our list of supported groups. We add this to our preferred client and server key shares for TLS 1.3 and we now have a separate list for TLS 1.2 which does not do this, cleaning up the old "full list" from the comments. 3) Updates the golden magic numbers in the regression tests to allow for the above two things changing the handshake, so the regress tests pass. With this you can successfully hybrid PQ with servers and clients that support it. ok tb@ kenjiro@
* Add a MLKEM768_X25519 hybrid key share.beck2025-12-047-26/+348
| | | | | | | | | | | | This implements the currently in use MLKEM768_X25519 hybrid key share as outlined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ This commit does not yet wire this up to anything, that is done in follow on changes. ok tb@ jsing@ kenjiro@
* Simplify tls13_server_hello_build()tb2025-10-251-5/+5
| | | | | | | | There's no need to pass in the hrr parameter as it is redundant with the tls13.hrr flag. This avoids boolean blindness in the caller and removes a leftover from before we had tls13.hrr. ok jsing kenjiro
* Add missing Nm line for SSL_SESSION_duptb2025-10-241-2/+3
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-09-04 16:24:04 +0000