summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* libssl: ensure server selected ALPN was advertisedtb7 days1-6/+20
| | | | | | | | | | | | | | | Per RFC 7301, section 3.2, "In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert. If a server does not do that and chooses a protocol that we have not advertised, we should abort the handshake. The RFC does not specify an alert for this case. BoringSSL chose illegal_parameter and OpenSSL decode_error. I slightly prefer illegal_parameter, so went with that. Reported by Acts1631 with a similar diff. ok jsing kenjiro
* tlsext_alpn_client_process(): rename list and prototb7 days1-8/+8
| | | | | | | Use server_list and selected instead of list and proto to reduce noise in the next commit. ok jsing kenjiro
* grammar; a -> anjsg12 days5-15/+15
| | | | ok schwarze@ sthen@ krw@
* Change RFC references from 8446 to 9846 and adjust section numberstb2026-08-2118-97/+95
| | | | with/ok kenjiro
* SSL_get_finished: remove comment about TLSv1.0 and TLSv1.1tb2026-08-211-4/+2
| | | | ok kenjiro
* Simplify handling of remaining record content on switch to legacy stack.jsing2026-08-211-35/+13
| | | | | | | | Now that the legacy stack uses struct tls_content, store any remaining record content directly, rather than fudging up a record that the legacy stack will process on the next read. ok kenjiro@ tb@
* Allocate TLS 1.3 receive buffers lazilykenjiro2026-08-211-14/+7
| | | | | | | | | | | | The receive buffer is not used for records created for sending. Avoid allocating a maximum-sized buffer in tls13_record_new() and instead allocate a header-sized buffer when tls13_record_recv() is first called. The buffer will grow as needed once the record length is known. This avoids an unnecessary allocation for outgoing records and reduces the initial allocation size for incoming records. ok tb jsing
* libssl: use correct alert for key_share without supported_groupstb2026-08-181-2/+2
| | | | | | | | | | | | | | | | Processing the key_share extension requires a supported_groups extension. RFC 9846, section 9.2 explicitly mandates a missing_extension alert in this situation, so use that instead of illegal_parameter. We do have code in tls13_client_hello_required_extensions() implementing the requirements on extensions of the relevant paragraph of that section with the corrrect alerts. The error in the extension processing happens before hitting these checks in this particular case. Reported by Tom Gouville of the tlspuffin team as part of https://github.com/libressl/portable/issues/1279 ok jsing kenjiro
* SSL_CTX_new(): fix spelling of NULLtb2026-08-141-3/+3
|
* Make file-local functions statickenjiro2026-07-314-11/+11
| | | | | | | These functions are only used within their implementation files and do not need external linkage. Mark them static. ok tb
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-09-05 14:58:31 +0000