summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add FIPS 180-4 references for SHA-256 constants.HEADmasterjsing2026-04-251-1/+6
|
* Simplify PKCS7_get_issuer_and_serial()tb2026-04-241-9/+6
| | | | | | | | | The i variable is unused. Likewise for the first assignment to ri. Instead of an incomplete check that idx is in range, which still results in a NULL deref if idx < 0, check if ri is not NULL before accessing, as sk_value() checks the index correctly. ok jsing kenjiro
* wycheproof: skip BLS test vectors to prepare for updatetb2026-04-211-1/+3
|
* pkcs7test: factor main into a helper so we can add some unit tests easilytb2026-04-211-3/+13
|
* mlkem: use <openssl/mlkem.h> instead of "mlkem.h"tb2026-04-201-2/+3
| | | | patch from portable
* tls_keypair: add missing <limits.h>tb2026-04-201-1/+3
| | | | from bcook kenjiro
* ec_pmeth: fix 20yo comment: *outlen -> *keylentb2026-04-201-2/+2
|
* libtls: consistently handle allocation failurestb2026-04-162-6/+6
| | | | | | | | | Use tls_set_errorx() or tls_error_setx() rather than the versions without x for TLS_ERROR_OUT_OF_MEMORY. ENOMEM adds no further info. From Michael Forney ok bcook
* libtls: use TLS_ERROR_OUT_OF_MEMORY after malloc failuretb2026-04-161-2/+2
| | | | | | | | | | tls_config_load_file() hat a spot that used TLS_ERROR_UNKNOWN, so switch that to the usual error code. Use tls_error_setx() since strerror(ENOMEM) adds nothing. From Michael Forney ok bcook
* libtls: use tls_error_setx() after BIO_new_mem_buf()tb2026-04-161-2/+2
| | | | | | | | | | This is the only place where tls_error_set() was used. While the new length check now guarantees that the failure is due to ENOMEM, this info does not add value. From Michael Forney ok bcook
* libtls: prefer x version of error settingtb2026-04-165-17/+17
| | | | | | | | | | If a check fails and errno is not necessarily set by the previous API call use tls_set_errorx() or tls_error_setx() since turning an unrelated errno into an error string is unhelpful. From Michael Forney ok bcook
* libtls: add missing length checks before BIO_new_mem_buf()tb2026-04-162-2/+17
| | | | | | | | | | | | Like all proper libcrypto APIs, BIO_new_mem_buf() takes an int as a length argument. Check the size_t passed in to be at most INT_MAX to avoid issues with truncation and overflow like it's done everywhere else. After release this should probably be clamped down further since legitimate files (certs and keys) are nowhere near this large. Prompted by a diff by Michael Forney ok jsing
* keypairtest: zero out tls_error before running teststb2026-04-151-2/+2
| | | | | | | Otherwise tls_error_clear() (called e.g. via tls_error_vset()) will free the bad error->msg pointer. From Michael Forney
* Prior to this we substring matched and allowed a leading .beck2026-04-133-7/+75
| | | | | | | | | | | on a SAN DNSname constraint. This is not correct, as with a DNSname constraint, it may exacly match or match zero or more additional components on the front of the candidte to match. Spotted by Haruto Kimura <hkimura2026@gmail.com> ok tb@ kenjiro@
* Bump LibreSSL version for the releasetb2026-04-081-3/+3
| | | | ok deraadt
* Rename labellen to label_lentb2026-04-072-24/+24
| | | | Requested by jsing, ok beck
* Fix NULL deref for malformed OAEP parameters in CMS decryptiontb2026-04-072-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | This converts rsa_cms_decrypt() to use X509_ALGOR_get0() and fixes a NULL deref when a parameter is (invalidly) omitted similar to the fix in ec/ec_ameth.c r1.66 from a couple years back. There is currently an XXX annotating a hairy leak due to trying to be smart and stealing the parameters from the oaep object. Instead, just make a copy of the label string and free it in the exit path. The diff adds an error for labellen == 0 since that is an invalid encoding of pSpecifiedEmpty (see RFC 8017) -- per the DER the default must be omitted. This way we avoid a malloc(0) implementation-defined behavior. This minor issue was assigned CVE-2026-28390 by OpenSSL and was reported by too many to list. The fix is my own. It is similar to OpenSSL's fix only because I rewiewed theirs and suggested an improvement or two. This is the last of the "security fixes" in today's OpenSSL release that "affect" LibreSSL. All the other bugs were already fixed a few years back or we didn't have the code/bugs in the first place. ok beck jsing
* Refactor and fix ocsp_find_signer_sk()tb2026-04-071-12/+17
| | | | | | | | | | | | | Instead of reaching deep inside the OCSP_BASICRESP and ignoring its semantics and then try to untangle things in ocsp_find_signer_sk(), pass the OCSP_BASICRESP and use OCSP_resp_get0_id() which has the logic built in. Avoids a crash if you call OCSP_basic_verify() after OCSP_BASICRESP_new() without OCSP_basic_sign(). This cannot happen on a deserialized OCSP object. Prompted by a report by Kamil Frankowicz, Jan Kaminski, Bartosz Michalowski. ok jsing
* Add a few to-do items to the crl_cb()tb2026-04-071-1/+6
| | | | | | | | Prompted by the "fix" fighting symptoms of misdesign in Delta CRL processing rather than addressing the root cause. Probably the best fix is to remove support for Indirect CRLs and Delta CRLs outright. ok jsing
* Stop Delta CRL processing if a CRL number is misssingtb2026-04-071-4/+8
| | | | | | | | | | | | | | | | A malformed Delta CRL could cause a crash. Funnily enough the deserializer recognizes this and marks such a CRL as invalid, but nothing ever checks the EXFLAG_INVALID for CRLs. For certificates this would usually result in verification failure due to x509v3_cache_extensions() failing. This is only reachable if the X509_V_FLAG_USE_DELTAS is used, which only a handful of ports do, plus openssl(1) does if you use the undocumented -use_deltas flag. Reported by Igor Morgenstern to OpenSSL who then sat on this since Jan 8 and assigned CVE-2026-28388. ok jsing
* x509v3.h: remove pointless #ifdef HEADER_CONF_Htb2026-04-061-3/+1
| | | | | | | | | x509v3.h has included conf.h since June 20, 1999, OpenSSL commit ba404b5e, so HEADER_CONF_H has been defined since then. Also since then, CONF_VALUE (only available via conf.h) has been used outside of HEADER_CONF_H, making that #ifdef doubly pointless. ok bcook jsing kenjiro
* cms_local.h: remove #ifdef X509V3_HEADER_Htb2026-04-061-4/+3
| | | | | | | | | All thirteen files including cms_local.h do that after including cms.h, which already includes x509v3.h, so this is always defined. While here make the cms_local.h a bit more selfstanding by including asn1.h and x509v3.h ok bcook jsing (who had the same diff) kenjiro
* 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@
* Fix min vs max in failure output.jsing2026-04-031-3/+3
|
* Use DTLS_client_method() instead of DTLSv1_client_method().jsing2026-04-031-3/+3
|
* 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@
* Adjust depth check to match change in verifier.jsing2026-04-011-2/+2
|
* Restore the previous behaviour with maximum verification depth.jsing2026-04-011-7/+7
| | | | | | | | | | | The maximum depth is not expected to include the leaf certificate - restore the decrement prior to checking, which means the previous behaviour is retained for the callback depth and the maximum depth. Reduce the maximum depth by one in order to avoid the overwrite that could previously occur. Thanks to anton@ for flagging the rust-openssl failure in regress. ok tb@
* Fix an off-by-one error in the X.509 verifier depth checking.jsing2026-03-311-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | In x509_verify_build_chains(), ensure that we check the current depth against max_depth prior to turning it into a legacy-style depth index. Additionally, add a guard to x509_verify_chain_append() so that we avoid exceeding the maximum certs per chain, even if we fail to handle this correctly elsewhere. Also prevent the legacy callback from being able to override the maximum verification depth. The current off-by-one allows for a 4 byte overwrite to occur on heap allocated memory - this will likely trigger a crash on OpenBSD (but may go unnoticed elsewhere). This is only reachable if a TLS client is talking to a malicious server or if a TLS server has client certificate verification enabled - in both cases the verification depth also needs to be set to the maximum allowed value of 32. It is worth noting that many TLS clients/servers set the maximum verification depth to a value that is much less than the default. A libtls client or server uses a default depth of 6 and is not impacted in this configuration. Thanks to Calif.io in collaboration with Claude and Anthropic Research, for reporting the issue. ok tb@
* Add additional X.509 verifier test cases.jsing2026-03-312-2/+28
| | | | The second case (14b) currently triggers a bug in the new verifier.
* Run new test certificate bundles through Go's verifier.jsing2026-03-311-0/+2
|
* Add additional certificate test bundles.jsing2026-03-314-0/+1450
|
* Generate two additional certificate test scenarios which have deep chains.jsing2026-03-311-0/+16
|
* libssl regress: adjust golden numbers for RSASSA-PSStb2026-03-302-39/+44
| | | | | | Add the three RSASSA-PSS SignatureScheme 0x080b, 0x080a, 0x0809 in the appropriate spots in (components of) the ClientHello and adjust various length octets by adding 6.
* 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
|
* ML-KEM: ensure that key_768 is only dereferenced with 768-bit keystb2026-03-291-3/+7
| | | | | | | | | This looks like a NULL dereference that should crash, but for some reason it doesn't, even with -O0 with all compilers i tried. At the very least it may result in compilers deducing that key_768 != NULL and lead to incorrect optimizations. ok claudio jsing kenjiro miod
* Add missing include path required to reach newly added crypto_assembly.hanton2026-03-291-2/+3
| | | | include.
* Include crypto_assembly.h instead of manually ensuring _CET_ENDBR exists.jsing2026-03-286-36/+12
| | | | ok kenjiro@ tb@
* Provide a crypto_assembly.h internal header.jsing2026-03-281-0/+30
| | | | | | | | | This will contain defines and macros that we need for assembly code, without polluting other headers that are primarily used for C code. For now, this just unconditionally provides _CET_ENDBR on amd64. ok kenjiro@ tb@
* libtls: const workarounds for X509_NAME in OCSP for OpenSSL 4tb2026-03-281-4/+5
| | | | | | | | | | | | | | The API to look up a cert by subject or issuer name clearly only needs to do name comparisons in a collection of certs so should by all means take a const X509_NAME * as an argument. However, this isn't all that easy to do and hence it's only in OpenSSL 4 that this obvious step was reached. This means that there is no way around casting for older code. One could cast the return value of X509_get_issuer_name() or the argument passed to the two lookups by subject. jsing slightly prefers the second approach, so this is what we do here. ok djm jsing kenjiro
* libtls: simple cases of const for X509_NAME *tb2026-03-282-6/+6
| | | | | | | | | | | After the const sprinkling in OpenSSL 1.1, X509_get_{issuer,subject}_name() still returned a non-const pointer for unclear reasons. In OpenSSL 4, the return value also grew a const qualifier, so move the two "name" in tls_conninfo.c and the "subject_name" in tls_verify.c to const. They are only used for further processing by already const correct functions (at least as far as X509_NAME is concerned). ok djm jsing kenjiro
* openssl speed: whitespace tweaktb2026-03-191-3/+3
|
* openssl speed: add benchmarking support for ML-KEMkenjiro2026-03-181-2/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for benchmarking ML-KEM key encapsulation mechanisms to openssl speed. The following operations are measured: - key generation - encapsulation - decapsulation Two parameter sets are supported: mlkem768 mlkem1024 The benchmark can be invoked using the following options: mlkem run all ML-KEM benchmarks mlkem768 run ML-KEM-768 benchmarks mlkem1024 run ML-KEM-1024 benchmarks Results are reported similarly to other public key algorithms, showing time per operation and operations per second. Machine-readable output (-mr) support is also added for ML-KEM. ok tb
* sync with Mozilla root CA store, ok tb@sthen2026-03-181-174/+42
| | | | | | | | - remove CommScope CA (they requested it themselves; https://bugzilla.mozilla.org/show_bug.cgi?id=1994866) - add new cert: /C=HU/L=Budapest/O=Microsec Ltd./2.5.4.97=VATHU-23584497/CN=e-Szigno TLS Root CA 2023
* libcrypto: prefix EC_KEY methods with ec_key_tb2026-03-185-100/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We received reports that the too generic internal ecdsa_{sign,verify}() symbol names clash in some static links. The naming here is annoying because the EC_KEY_METHOD amalgamated the no longer existing ECDH and ECDSA methods which themselves had poorly chosen method names, still reflected in public API. There are various messes here. The ECDSA verify methods are declared in ec_local.h, whereas the ECDSA sign methods are in ecdsa_local.h (which is itself pretty useless and really only about EC_KEY_METHOD). I therefore merged the ECDSA method declarations into ec_local.h and deleted ecdsa_local.h since I see no real benefit to the latter. ecdsa.c needs ec_local.h anyway. Having the method declarations next to EC_KEY_METHOD seems sensible. I left the order as it was, matching ecdsa.c. The eckey_compute_pubkey() prototype should probably be moved down. With one exception I just added an ec_key_ prefix. This leads to a a repetition of 'key' in ec_key_ecdh_compute_key() which I chose to live with because it matches the public ECDH_compute_key() (mostly used by SSH implementations). The exception is ec_key_generate_key() where I expanded the gen() leading to another _key repetition but this then matches EC_KEY_generate_key(). Thanks to Rosen Penev for reporting and sending an initial diff. See also https://github.com/gsliepen/tinc/issues/478 ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-06-02 08:14:46 +0000