summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Unlock CRYPTO_LOCK_UI on ui_open_session() failuretb2026-07-251-3/+5
| | | | | | | | | | | | | | | | | | | | | Both ui_open_session() implementations, open_console() in ui_openssl.c in base, and the one in ui_openssl_win.c in portable, grab the lock of type CRYPTO_LOCK_UI before doing anything else. The only internal (and, as far as I can tell, the only existing) caller, UI_process(), returns immediately on failure. The calling thread thus keeps holding the lock and the next call to UI_process() will block indefinitely. Fix this by using the common exit path, which calls ui_close_session() aka close_console(), both implementations of which release the lock. Thanks to Kartik (@sage-mode-hunter) who proposed an alternative fix for ui_openssl_win.c, which we would have to apply to ui_openssl.c as well. Matches OpenSSL behavior since PR #2037 Closes https://github.com/libressl/portable/pull/1334 ok kenjiro
* Improve SHA-3 performance.jsing2026-07-221-37/+281
| | | | | | | | | | | Replace the tiny-sha3 keccakf implementation with an unrolled and interleaved algorithm, that is hidden away in an obsolete reference implementation. This gets us 3.3x speed up on arm64 (Apple M2), a 1.3x speed up on amd64 (Intel i7-1165G7) and 6x speed up on sparc64 (M3000). ok tb@
* Remove redundant BIO_write() length assertions in b64_write()kenjiro2026-07-171-3/+1
| | | | | | | | | b64_write() asserted that BIO_write() does not return more bytes than requested in two places. Other BIO_write() call sites do not make this check, and there is no special handling here that depends on asserting this condition. ok tb@ beck@ joshua@
* 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@
* Fix X.509 constraints URI host parsing.jsing2026-07-141-29/+72
| | | | | | | | | | | | | | | An authority in a URI is only terminated by a slash, question mark or hash, however the current code also included colons. This allows a specically crafted userinfo to bypass name constraints host checks. Additionally, IPv6 literals may only be specified when enclosed with square brackets, which is not enforced. Rewrite parts of the host and IP parsing code to be more strict, fixing both of these issues in the process. Thanks to Jack Lloyd for reporting the userinfo bypass. ok tb@
* correspondigly -> correspondinglytb2026-07-131-1/+1
|
* LLVM now emits calls to strlen(3) and wcslen(3). Redirect those calls tokettenis2026-06-303-5/+9
| | | | | | | our hidden aliases to prevent unnecessary PLT entries (like we already do for memmove(3), memcpy(4) and memset(3)). ok deraadt@
* x509_vfy: sync get_crl_sk() with BoringSSL and OpenSSLtb2026-06-261-6/+18
| | | | | | | | | | | | Among CRLs with the same score prefer the one with the most recent lastUpdate (RFC 5280 thisUpdate). This pulls in OpenSSL commits 626aa248, e032117d, 8b7c51a0 from 2016, so before the license change. This uses the annoying ASN1_TIME_diff() API, but there is no better way, really. Every other ASN1_TIME API will be just as awkward. This fixes the currently failing x509_crl test cases. ok kenjiro
* Add OIDs for CCR, ErikIndex, ErikPartition, CommunityDefinitionjob2026-06-252-0/+10
| | | | | | | | | References: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ccr https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-erik-protocol https://datatracker.ietf.org/doc/html/draft-ietf-grow-yang-bgp-communities OK tb@
* Fix misleading comment in strstr(3)tim2026-06-231-2/+2
| | | | | | | From upstream musl: https://git.musl-libc.org/cgit/musl/commit?id=c53e9b239418eb3e0e8be256abd0f6ad7608bbcf OK tb@
* Avoid shift overflow in memmem(3) and strstr(3)tim2026-06-232-10/+10
| | | | | | | Fix from upstream musl: https://git.musl-libc.org/cgit/musl/commit?id=593caa456309714402ca4cb77c3770f4c24da9da OK tb@
* crl_cb(): fix EXFLAG_CRITICAL mishandlingtb2026-06-231-2/+2
| | | | | | | | | The EXFLAG_CRITICAL should be set on encountering a critical CRL extension unsupported by the library. The current loop does the opposite: it stops looking as soon as it finds the first critical extension the library supports... ok kenjiro
* x509_vfy: make a NULL check explicittb2026-06-221-2/+2
|
* x509_vfy: remove unnecessary NULL checks before freetb2026-06-221-7/+4
| | | | looks good to claudio
* 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.
* x509_vfy: another function pointer argument causing shadowing issuestb2026-06-221-3/+3
|
* bio_meth: rename function pointer arguments to avoid stdio.h shadowingtb2026-06-221-9/+9
|
* conf_api: remove a bunch of redundant parenthesestb2026-06-221-13/+14
|
* 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@
* x509_verify: fix incorrect purpose check in the non-legacy pathtb2026-06-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | If a purpose is configured on the verify context (which it currently never is), this check would only accept certificates for which the purpose check fails. Also, this code is not currently reachable from public API since x509_verify() is only ever called with a legacy xsc set on the verify ctx, so x509_verify_ccert_extensions() takes the path returning 1 earlier. X509_check_purpose() is one of these strange legacy APIs. It returns -1 on error, 0 if the cert fails the purpose check, 1 if it passes it and values between 2 and 5 indicate various legacy garbage meaning that the cert might possibly have been fit for this purpose until around a quarter century ago. While for CA certs the checks in "No we don't care about ..." exclude return values > 1, it is still possible for the S/MIME purpose to return 2 due to a workaround for some buggy NS certs, for example. In short: anything but 1 means unfit for the purpose or at best dubious, so reject such certs. Reported by Frank Denis ok kenjiro
* Avoid freeing a caller-owned buffer in PKCS7_verify()tb2026-06-091-7/+7
| | | | | | | | If a PKCS#7 S/MIME message comes with an empty set of digestAlgorithms in the SignedData, PKCS7_verify() would incorrectly free a caller-owned buffer. Fix the freeing logic to avoid this situation. From Igor Ustinov via OpenSSL
* Add some missing bounds checks to ASN1_mbstring_copy()tb2026-06-091-3/+20
| | | | | | | | | | | | | If the in string is unreasonably long, assigning strlen(in) to an int may overflow, so exclude this situation. Moreover, the code would unconditionally multiply nchar by 2 or 4, which could again overflow an int. Check for this situation and error out to avoid an out of bounds write. More may be needed in here, which will be revisited later. Based on a diff by Viktor Dukhovni via OpenSSL.
* Avoid out-of-bounds read in CMS password-based decryptiontb2026-06-091-1/+5
| | | | | | | | | | The RFC 3211 PWRI integrity check when unwrapping the password-derived key accesses seven bytes from a heap-allocated buffer. If an (invalid) block cipher with short blocks is in use 2 * blocksize may not be sufficient room for 7 bytes. In that silly case, the function performs an OOB read. Add length check to avoid this situation From Igor Ustinov via OpenSSL.
* Avoid NULL dereference in password-based CMS decryptiontb2026-06-091-1/+5
| | | | | | | | The keyDerivationAlgorithm field is OPTIONAL in the ASN.1 but required for password-based CMS. Check that the field is present before using it to avoid a crash. From Igor Ustinov via OpenSSL
* ecdh: add error codes for point at infinity/not on curvetb2026-06-091-3/+7
| | | | | | | | The point at infinity would previously raise EC_R_POINT_AT_INFINITY via EC_POINT_get_affine_coordinates(). For consistency, also raise an error for off-curve points. pointed out by/ok kenjiro
* Fix strange error check in EC_POINT_get_affine_coordinatestb2026-06-091-2/+2
| | | | | | EC_POINT_is_at_infinity() has a Boolean return nowadays, so drop > 0. ok jsing kenjiro
* Add a point at infinity check to ecdh_compute_key()tb2026-06-081-1/+4
| | | | | | | | | | | | | | While we already check that the peer's public point is on the curve and will reject the point at infinity when getting the affine coordinates, doing this earlier avoids doing work with the private key in a clearly invalid case. Suggested by Lucca Hirschi et al. [An EC_KEY_check_key() call was also suggested but this is a bit expensive and punishes callers that do that or equivalent already (e.g. ssh)] ok jsing kenjiro
* 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
* tls_conn_version: add missing .Pp in HISTORYtb2026-06-071-2/+3
|
* ec_convert: point_conversion_t -> point_conversion_form_t in a commenttb2026-06-071-3/+3
|
* ssl_kex: include ssl_local.htb2026-06-071-1/+2
|
* add X25519MLKEM768 to the start of the default ECDHE curves list, allowingsthen2026-06-062-6/+6
| | | | | | | libtls clients to connect to servers which don't offer any other curves (this has been seen in the wild with got, reported by stsp). ok tb@ depends on recent libssl changes (ssl_tlsext.c r1.161, t1_lib.c r1.209).
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-09-04 20:17:59 +0000