summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Handle X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE in newtb2021-04-281-4/+1
| | | | | | | | verifier." (r1.27). While this may have "fixed" one corner case, it broke expectations of Perl Net::SSLeay and Ruby OpenSSL regression tests. ok bcook
* Relax SAN DNSname validation and constraints to permit non leading *beck2021-04-271-19/+21
| | | | | | | | | | | wildcards. While we may choose not to support them the standards appear to permit them optionally so we can't declare a certificate containing them invalid. Noticed by jeremy@, and Steffan Ulrich and others. Modify the regression tests to test these cases and not check the SAN DNSnames as "hostnames" anymore (which don't support wildcards). ok jsing@, tb@
* Do not leave errors on the error stack on PKCS12_parse() success.tb2021-04-241-1/+3
| | | | | | | | Fix is the same as OpenSSL commit ffbf304d4832bd51bb0618f8ca5b7c26647ee664 Found by Alex Gaynor with a new pyca cryptography regress test. ok inoguchi
* Enable the new verifier again so hopefully the remaining kinks get ironedtb2021-04-241-2/+2
| | | | | | out in this release cycles. discussed with deraadt and jsing
* Fix indent of EC_METHODs as requested by jsing.tb2021-04-206-192/+192
| | | | While there zap trailing whitespace from a KNF approximation gone wrong.
* Compare pointer against NULL and fix a KNF issue.tb2021-04-201-3/+3
| | | | ok jsing
* Prepare to provide EC_POINT_set_compressed_coordinatestb2021-04-205-57/+41
| | | | ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Provide EC_POINT_{g,s}et_Jprojective_coordinates for internal usetb2021-04-2010-77/+97
| | | | ok jsing
* Simplify code after adding EC_POINT_{s,g}et_affine_coordinates()tb2021-04-203-73/+18
| | | | ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Prepare to provide EC_POINT_{g,s}et_affine_coordinatestb2021-04-2018-92/+90
| | | | | | Similar to part of OpenSSL commit 8e3cced75fb5fee5da59ebef9605d403a999391b ok jsing
* Simplify after EC_POINT_get_curve() additiontb2021-04-202-30/+8
| | | | ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Prepare to provide EC_GROUP_{get,set}_curve(3)tb2021-04-206-41/+51
| | | | | | | | | | | | | There are numerous functions in ec/ that exist with _GF2m and _GFp variants for no good reason. The code of both variants is the same. The EC_METHODs contain a pointer to the appropriate version. This commit hides the _GF2m and _GFp variants from internal use and provides versions that work for both curve types. These will be made public in an upcoming library bump. Similar to part of OpenSSL commit 8e3cced75fb5fee5da59ebef9605d403a999391b ok jsing
* Avoid division by zero in hybrid point encodingtb2021-04-191-17/+49
| | | | | | | | | | | | | | | In hybrid and compressed point encodings, the form octet contains a bit of information allowing to calculate y from x. For a point on a binary curve, this bit is zero if x is zero, otherwise it must match the rightmost bit of of the field element y / x. The existing code only considers the second possibility. It could thus fail with a division by zero error as found by Guido Vranken's cryptofuzz. This commit adds a few explanatory comments to oct2point and fixes some KNF issues. The only actual code change is in the last hunk which adds a BN_is_zero(x) check to avoid the division by zero. ok jsing
* Switch back to the legacy verifier for the release.tb2021-04-151-2/+2
| | | | | | | | | | | This is disappointing as a lot of work was put into the new verifier during this cycle. However, there are still too many known bugs and incompatibilities. It is better to be faced with known broken behavior than with new broken behavior and to switch now rather than via errata. This way we have another cycle to iron out the kinks and to fix some of the remaining bugs. ok jsing
* Don't leak param->name in x509_verify_param_zero()tb2021-04-051-1/+2
| | | | | | | | | For dynamically allocated verify parameters, param->name is only ever set in X509_VERIFY_set1_name() where the old one is freed and the new one is assigned via strdup(). Setting it to NULL without freeing it beforehand is a leak. looks correct to millert, ok inoguchi
* Bump minors after symbol additiontb2021-03-311-1/+1
|
* Expose various DTLSv1.2 specific functions and definestb2021-03-311-0/+1
| | | | ok bcook inoguchi jsing
* Provide missing prototype for d2i_DSAPrivateKey_fp(3)tb2021-03-311-1/+2
| | | | ok bcook inoguchi jsing
* Document EVP_PKEY_new_CMAC_key(3)tb2021-03-311-16/+4
| | | | ok bcook inoguchi jsing
* Provide EVP_PKEY_new_CMAC_key(3)tb2021-03-312-5/+2
| | | | ok bcook inoguchi jsing
* Prepare documenting EVP_PKEY_new_CMAC_key(3)tb2021-03-291-2/+54
| | | | Based on some text in OpenSSL 1.1.1's EVP_PKEY_new.pod.
* Prepare to provide EVP_PKEY_new_CMAC_key()tb2021-03-294-20/+84
| | | | | | | sebastia ran into this when attempting to update security/hcxtools. This will be tested via wycheproof.go once the symbol is public. ok jsing, tested by sebastia
* Avoid mangled output in BIO_debug_callbacktb2021-03-251-4/+12
| | | | | | | Instead of blindly skipping 14 characters, we can use the return value of snprintf() to determine how much we should skip. From Martin Vahlensieck with minor tweaks by me
* Fix copy-paste error in previoustb2021-03-191-2/+2
| | | | | | | Found the hard way by lists y42 org via an OCSP validation failure that in turn caused pkg_add over TLS to fail. Detailed report by sthen. ok sthen
* Use EXFLAG_INVALID to handle out of memory and parse errors intobhe2021-03-132-11/+45
| | | | | | x509v3_cache_extensions(). ok tb@
* Zap a useless variable.tb2021-03-121-4/+2
| | | | suggested by jsing
* Missing void in function definitiontb2021-03-121-2/+2
| | | | ok jsing
* Fix checks of memory caps of constraints namestb2021-03-123-20/+32
| | | | | | | | | | | | | | | x509_internal.h defines caps on the number of name constraints and other names (such as subjectAltNames) that we want to allocate per cert chain. These limits are checked too late. In a particularly silly cert that jan found on ugos.ugm.ac.id 443, we ended up allocating six times 2048 x509_constraint_name structures before deciding that these are more than 512. Fix this by adding a names_max member to x509_constraints_names which is set on allocation against which each addition of a name is checked. cluebat/ok jsing ok inoguchi on earlier version
* spelling: refenece -> referencejmc2021-03-121-3/+3
|
* spellingjsg2021-03-1212-37/+37
|
* LibreSSL 3.3.2bcook2021-03-071-3/+3
|
* Set is_trusted in x509_verify_ctx_add_chain()tb2021-02-261-2/+2
| | | | | | | | If we're about to add a chain we have a trust path, so we have at least one trusted certificate. This fixes a thinko from r1.31 and fixes the openssl(1) cms verify test. ok jsing (who had the same diff)
* Fix two bugs in the legacy verifiertb2021-02-251-6/+10
| | | | | | | | | | | | | | | To integrate the new X.509 verifier, X509_verify_cert() was refactored. The code building chains in the legacy verifier was split into a separate function. The first bug is that its return value was treated as a Boolean although it wasn't. Second, the return alone is not enough to decide whether to carry on the validation or not. Slightly rearrange things to restore the behavior of the legacy verifier prior to this refactoring. Issue found and test case provided by Anton Borowka and jan. ok jan jsing
* Rename depth to num_untrusted so it identifies what it actually represents.jsing2021-02-251-6/+6
| | | | ok tb@
* Avoid passing last and depth to x509_verify_cert_error() on ENOMEM.jsing2021-02-251-3/+2
| | | | | | | | | In x509_verify_ctx_set_xsc_chain(), an ENOMEM case is currently passing the last certificate and depth (which is no longer actually depth) to x509_verify_cert_error(). Given we've hit an ENOMEM situation, neither of these are useful so remove both. ok tb@
* Fix comment explaining last_untrusted. This should really be calledtb2021-02-241-2/+2
| | | | | | num_untrusted, but unfortunately it's public... ok jsing tobhe
* Make the new validator check for EXFLAG_CRITICALtb2021-02-241-8/+15
| | | | | | | | | | | | | | | | | | | | | | As should be obvious from the name and the comment in x509_vfy.h int last_untrusted; /* index of last untrusted cert */ last_untrusted actually counts the number of untrusted certs at the bottom of the chain. Unfortunately, an earlier fix introducing x509_verify_set_xsc_chain() assumed that last_untrusted actually meant the index of the last untrusted cert in the chain, resulting in an off-by-one, which in turn led to x509_vfy_check_chain_extension() skipping the check for the EXFLAG_CRITICAL flag. A second bug in x509_verify_set_xsc_chain() assumed that it is always called with a trusted root, which is not necessarily the case anymore. Address this with a temporary fix which will have to be revisited once we will allow chains with more than one trusted cert. Reported with a test case by tobhe. ok jsing tobhe
* Pull in fix for EVP_CipherUpdate() overflow from OpenSSL.tb2021-02-181-1/+23
| | | | | | | | | | | | | | ok inoguchi commit 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1 Author: Matt Caswell <matt@openssl.org> Date: Tue Feb 2 17:17:23 2021 +0000 Don't overflow the output length in EVP_CipherUpdate calls CVE-2021-23840 Reviewed-by: Paul Dale <pauli@openssl.org>
* Sync cert.pem with Mozilla NSS root CAs, except "GeoTrust Global CA", ok tb@sthen2021-02-121-659/+417
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notably this update removes various old Symantec roots (GeoTrust, thawte, VeriSign) that were set in NSS to be distrusted on 1/1/2021. Nobody should have been using these for years; only certain subCAs signed by these were valid in NSS in that time due to an exemption: https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec Notably Apple's "Apple IST CA 2 - G1" which is still in use for some endpoints (it is cross signed by another CA too but these endpoints are publishing the GeoTrust intermediate cert). So for now I have skipped removal of "GeoTrust Global CA" to avoid affecting these sites. Debian ran into this when they updated their cert database and had to back this part out, affected sites are not reachable on Android Firefox and maybe other newer Firefoxes. Some sites that were affected have moved to a different CA in the last few days but others, notably api.push.apple.com, remain (I can only guess that there is a complicated problem involved, possibly cert pinning on old devices - the clock is ticking though as this expires in May 2022 anyway ;) Additions: /C=RO/O=CERTSIGN SA/OU=certSIGN ROOT CA G2 /C=HU/L=Budapest/O=Microsec Ltd./2.5.4.97=VATHU-23584497/CN=e-Szigno Root CA 2017 /C=KR/O=NAVER BUSINESS PLATFORM Corp./CN=NAVER Global Root Certification Authority /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global Certification Authority /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global ECC P256 Certification Authority /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global ECC P384 Certification Authority Removals: /C=US/O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority /C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA /C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA 2 /C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3 /C=TW/O=Government Root Certification Authority /C=LU/O=LuxTrust S.A./CN=LuxTrust Global Root 2 /C=US/O=thawte, Inc./OU=(c) 2007 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G2 /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G3 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2007 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G4 /C=CH/O=WISeKey/OU=Copyright (c) 2005/OU=OISTE Foundation Endorsed/CN=OISTE WISeKey Global Root GA CA
* KNFtb2021-02-111-4/+7
|
* Add OID for draft-ietf-opsawg-finding-geofeedsjob2021-02-032-0/+2
| | | | | | | | | https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds describes a mechanism to authenticate RFC 8805 Geofeed data files through the RPKI. OpenSSL counterpart https://github.com/openssl/openssl/pull/14050 OK tb@ jsing@
* Add a bunch of RPKI OIDsjob2021-02-022-1/+26
| | | | | | | | | | | | | RFC6482 - A Profile for Route Origin Authorizations (ROAs) RFC6484 - Certificate Policy (CP) for the RPKI RFC6493 - The RPKI Ghostbusters Record RFC8182 - The RPKI Repository Delta Protocol (RRDP) RFC8360 - RPKI Validation Reconsidered draft-ietf-sidrops-rpki-rta - A profile for RTAs Also in OpenSSL: https://github.com/openssl/openssl/commit/d3372c2f35495d0c61ab09daf7fba3ecbbb595aa OK sthen@ tb@ jsing@
* Set chain on xsc on chain build failure.jsing2021-01-091-1/+3
| | | | | | | | Prior to calling the callback, ensure that the current (invalid and likely incomplete) chain is set on the xsc. Some things (like auto chain) depend on this functionality. ok beck@
* Bail out early after finding an single chain if we are have been called frombeck2021-01-091-1/+9
| | | | | | | | x509_vfy and have an xsc. There's no point in finding more chains since that API can not return them, and all we do is trigger buggy callbacks in calling software. ok jsing@
* search the intermediates only after searching the root certs, clarifybeck2021-01-081-11/+15
| | | | | | | this in the comments. helps avoid annoying situations with the legacy callback ok jsing@
* Handle X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE in new verifier.jsing2021-01-051-1/+4
| | | | | | Yet another mostly meaningless error value... Noted by and ok tb@
* Gracefully handle root certificates being both trusted and untrusted.jsing2021-01-052-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When a certificate (namely a root) is specified as both a trusted and untrusted certificate, the new verifier will find multiple chains - the first being back to the trusted root certificate and a second via the root that is untrusted, followed by the trusted root certificate. This situation can be triggered by a server that (unnecessarily) includes the root certificate in its certificate list. While this validates correctly (using the first chain), it means that we encounter a failure while building the second chain due to the root certificate already being in the chain. When this occurs we call the verify callback indicating a bad certificate. Some sensitive software (including bacula and icinga), treat this single bad chain callback as terminal, even though we successfully verify the certificate. Avoid this problem by simply dumping the chain if we encounter a situation where the certificate is already in the chain and also a trusted root - we'll have already picked up the trusted root as a shorter path. Issue with icinga2 initially reported by Theodore Wynnychenko. Fix tested by sthen@ for both bacula and icinga2. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-24 17:07:55 +0000