summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix some KNF issuestb2020-12-161-7/+8
|
* Use natural sizes for S3I(s)->tmp's *_md arraystb2020-12-151-6/+4
| | | | | | | | | | | | | | | | | | | | It is a historical artifact that cert_verify_md[], finish_md[] and peer_finish_md[] are twice as large as they need to be. This is confusing, especially for finish_md[] and peer_finish_md[] which are copied to to previous_client_finished[] and previous_server_finished[] which are only half as large. It is easy to check that they will never get more than EVP_MAX_MD_SIZE data written to them. In 1998, EVP_MAX_MD_SIZE was 20 bytes long (for SHA-1). This got bumped to 16+20 for the SSLv3-specific md5+sha1. Apparently under the impression that EVP_MAX_MD_SIZE was still 20 bytes, someone else doubled finish_md[]'s size to EVP_MAX_MD_SIZE*2 and added /* actually only needs to be 16+20 */. A bit later finish_md[] was split up, and still a bit later the comment was amended for TLSv1. Shortly thereafter SHA-512 required a bump of EVP_MAX_MD_SIZE to 64 by a third person and we have been carrying 192 bytes of untouched memory in each of our SSLs ever since. ok inoguchi jsing (jsing had the same diff)
* Fix return value variable type in tls_keypair_load_certinoguchi2020-12-151-2/+2
| | | | | | | ERR_peek_error() returns unsigned long. Reported by github issue by @rozhuk-im. ok bcook@ jsing@
* Fix SSL_get{,_peer}_finished() with TLSv1.3tb2020-12-142-2/+28
| | | | | | | | | | As reported by Steffen Ullrich and bluhm, the Finished tests in p5-Net-SSLeay's t/local/43_misc_functions.t broke with with TLSv1.3. The reason for this is that we don't copy the MDs over to the SSL, so the API functions can't retrieve them. This commit fixes this part of the test (one unrelated test still fails). ok inoguchi jsing
* Switch finish{,_peer}_md_len from int to size_ttb2020-12-141-3/+3
| | | | | | | This is the natural type for these and it simplifies an upcoming commit. The few consumers have been carefully checked to be fine with this. ok inoguchi jsing
* LibreSSL 3.3.1libressl-v3.3.1bcook2020-12-081-3/+3
|
* Fix a NULL dereference in GENERAL_NAME_cmp()tb2020-12-086-11/+94
| | | | | | | | | | | | Comparing two GENERAL_NAME structures containing an EDIPARTYNAME can lead to a crash. This enables a denial of service attack for an attacker who can control both sides of the comparison. Issue reported to OpenSSL on Nov 9 by David Benjamin. OpenSSL shared the information with us on Dec 1st. Fix from Matt Caswell (OpenSSL) with a few small tweaks. ok jsing
* Enable t_mmap-1 test. It is skipped on NetBSD, but works for us.bluhm2020-12-062-3/+10
|
* Mark bitmask_{start,end}_values[] and g_probable_mtu[] const.tb2020-12-051-4/+4
| | | | ok jsing kn
* Mark nid_list[] const. This moves 116 bytes to .rodata.tb2020-12-051-2/+2
| | | | ok jsing kn
* Move point-on-curve check to set_affine_coordinatestb2020-12-044-18/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bad API design makes it possible to set an EC_KEY public key to a point not on the curve. As a consequence, it was possible to have bogus ECDSA signatures validated. In practice, all software uses either EC_POINT_oct2point*() to unmarshal public keys or issues a call to EC_KEY_check_key() after setting it. This way, a point on curve check is performed and the problem is mitigated. In OpenSSL commit 1e2012b7ff4a5f12273446b281775faa5c8a1858, Emilia Kasper moved the point-on-curve check from EC_POINT_oct2point to EC_POINT_set_affine_coordinates_*, which results in more checking. In addition to this commit, we also check in the currently unused codepath of a user set callback for setting compressed coordinates, just in case this will be used at some point in the future. The documentation of EC_KEY_check_key() is very vague on what it checks and when checks are needed. It could certainly be improved a lot. It's also strange that EC_KEY_set_key() performs no checks, while EC_KEY_set_public_key_affine_coordinates() implicitly calls EC_KEY_check_key(). It's a mess. Issue found and reported by Guido Vranken who also tested an earlier version of this fix. ok jsing
* grammar fixes from Varik "The Genuine Article!!!" Valefor;jmc2020-12-033-9/+9
|
* Extend the methods test to cover dtls methods as welltb2020-12-011-1/+57
|
* Enable ssl_methods unit test.tb2020-12-011-1/+2
|
* Add an ssl_methods() unit test that currently only covers thetb2020-12-011-0/+192
| | | | | behavior of SSL_is_server(). This would have caught the regression introduced in the method unification.
* Bring back *_client_method() structstb2020-12-013-11/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | The method unification broke an API promise of SSL_is_server(). According to the documentation, calling SSL_is_server() on SSL objects constructed from generic and server methods would result in 1 even before any call to SSL_set_accept_state(). This means the information needs to be available when SSL_new() is called, so must come from the method itself. Prior to the method unification, s->server would be set to 0 or 1 in SSL_new() depending on whether the accept method was undefined or not. Instead, introduce a flag to the internal structs to distinguish client methods from server and generic methods and copy that flag to s->server in SSL_new(). This problem was reported to otto due to breakage of DoH in net/dnsdist. The reason for this is that www/h2o relies on SSL_is_server() to decide whether to call SSL_accept() or SSL_connect(). Thus, the h2o server would end up responding to a ClientHello with another ClientHello, which results in a handshake failure. The bandaid applied to www/h2o can be removed once this fix has made it into snaps. No other breakage is known. This commit brings back only about half of the duplication removed in the method unification, so is preferable to a full revert. ok jsing
* Avoid undefined behavior due to memcpy(NULL, NULL, 0)tb2020-11-251-4/+6
| | | | | | | | | This happens if name->der_len == 0. Since we already have a length check, we can malloc and memcpy inside the conditional. This also makes the code easier to read. agreement from millert ok jsing
* mapalign() only handles allocations >= a page; problem found by and ok semarie@otto2020-11-231-1/+3
|
* fix another misleading line break and indentlibressl-v3.3.0tb2020-11-201-3/+4
|
* fix confusing line break and indenttb2020-11-201-3/+4
|
* $OpenBSD$tb2020-11-191-0/+1
|
* Plug leak in x509_verify_chain_dup()tb2020-11-181-2/+2
| | | | | | | | | | | | | | | x509_verify_chain_new() allocates a few members of a certificate chain: an empty stack of certificates, a list of errors encountered while validating the chain, and a list of name constraints. The function to copy a chain would allocate a new chain using x509_verify_chain_new() and then clobber its members by copies of the old chain. Fix this by replacing x509_verify_chain_new() with calloc(). Found by review while investigating the report by Hanno Zysik who found the same leak using valgrind. This is a cleaner version of my initial fix from jsing. ok jsing
* Plug a big memory leak in the new validatortb2020-11-181-1/+6
| | | | | | | | | | | | | | | | | | The legacy validator would only call x509_vfy_check_policy() once at the very end after cobbling together a chain. Therefore it didn't matter that X509_policy_check() always allocates a new tree on top of the one that might have been passed in. This is in stark contrast to other, similar APIs in this code base. The new validator calls this function several times over while building its chains. This adds up to a sizable leak in the new validator. Reported with a reproducer by Hanno Zysik on github, who also bisected this to the commit enabling the new validator. Narrowed down to x509_vfy_check_policy() by jsing. We simultaenously came up with a functionally identical fix. ok jsing
* zap ugly empty line before closing bracetb2020-11-181-2/+1
|
* Move freeing of the verify context to its natural place instead oftb2020-11-181-2/+2
| | | | | | a few lines after. stylistic nit from jsing
* KNF (whitespace)tb2020-11-184-13/+13
|
* bump to 3.3.0bcook2020-11-181-3/+3
|
* Don't leak verify and store contexts.tb2020-11-181-1/+3
|
* typo & punctuation in commenttb2020-11-171-3/+3
|
* Implement exporter for TLSv1.3.jsing2020-11-164-8/+121
| | | | | | | | | This implements the key material exporter for TLSv1.3, as defined in RFC8446 section 7.5. Issue reported by nmathewson on github. ok inoguchi@ tb@
* Use X509_V_OK instead of 0.jsing2020-11-161-4/+3
| | | | ok beck@ tb@
* Add back an X509_STORE_CTX error code assignment.jsing2020-11-161-2/+3
| | | | | | | | This was inadvertently removed in r1.19. Spotted by tb@ ok beck@ tb@
* Return the specific failure for a "self signed certificate" in the chainbeck2020-11-151-1/+14
| | | | | | | | | in order to be compatible with the openssl error craziness in the legacy verifier case. This will fix a regress problem noticed by znc ok tb@
* Handle additional certificate error cases in new X.509 verifier.jsing2020-11-112-12/+79
| | | | | | | | | | | | | | | | | | | | | | | With the old verifier, the verify callback can always return 1 instructing the verifier to simply continue regardless of a certificate verification failure (e.g. the certificate is expired or revoked). This would result in a chain being built, however the first error encountered would be persisted, which allows the caller to build the chain, have the verification process succeed, yet upon inspecting the error code note that the chain is not valid for some reason. Mimic this behaviour by keeping track of certificate errors while building chains - when we finish verification, find the certificate error closest to the leaf certificate and expose that via the X509_STORE_CTX. There are various corner cases that we also have to handle, like the fact that we keep an certificate error until we find the issuer, at which point we have to clear it. Issue reported by Ilya Shipitcin due to failing haproxy regression tests. With much discussion and input from beck@ and tb@! ok beck@ tb@
* Implement auto chain for the TLSv1.3 server.jsing2020-11-111-1/+23
| | | | | | | | | Apparently OpenLDAP relies on this craziness to provide intermediates, rather than specifying the chain directly like a normal TLS server would. Issue noted by sthen@ and Bernard Spil, who both also tested this diff. ok tb@
* Use size_t for key_block_len.jsing2020-11-112-9/+7
| | | | | | | This allows us to remove a check and will make future changes simpler. Use suitable names for tls1_generate_key_block() arguments while here. ok inoguchi@ tb@
* Run the atf cleanup block after each test. This makes more testsbluhm2020-11-111-9/+11
| | | | pass when run as non root.
* Update getentropy on Windows to use Cryptography Next Generation (CNG).bcook2020-11-111-18/+9
| | | | | wincrypt is deprecated and no longer works with newer Windows environments, such as in Windows Store apps.
* Declare prototype of __syscall locally. Fixes t_syscall test.bluhm2020-11-102-3/+7
|
* Sync libc syscall tests with changes in upstream NetBSD. Use #ifdefbluhm2020-11-0920-283/+212
| | | | | | | to document differences to NetBSD behaviour, this helps to track upstream. Mark currently failing test as expected failures. So test programs get compiled and executed, but it shows that further investigation is necceassry.
* Skip test if web server cannot be pinged.bluhm2020-11-051-6/+14
|
* Wrap remaining overlong lines.tb2020-11-031-7/+7
|
* garbage collect an essentially unused variable and wrap some overlongtb2020-11-031-8/+10
| | | | lines
* * ptr -> *ptrtb2020-11-031-5/+5
|
* X509_verify_cert()'s return value is not reliable if the callbacktb2020-11-031-20/+22
| | | | | | | | | | | | | returns 1. verify.c's cb() ignores a bunch of things to display as much info as possible. Thus, check the error code on the store ctx as well, similar to OpenSSL commit d9e309a6 (old licence). This makes openssl verify error on expired certs, at least with the legacy verify code. While here, fix a number of style issues, simplify and plug a leak. ok inoguchi
* Fix bad indent.jsing2020-11-031-7/+6
|
* Only check BIO_should_read() on read and BIO_should_write() on write.jsing2020-11-031-5/+1
| | | | | | | | | | | | | | | | | | The TLSv1.3 code that drives a BIO currently checks BIO_should_read() after BIO_write() and BIO_should_write() after BIO_read(), which was modelled on SSL_get_error(). However, there are certain cases where this can confuse the caller - primarily where the same BIO is being used for both read and write and the caller is manipulating the retry flags. SSL_get_error() tends avoids this issue by relying on another layer of state tracking. Unfortunately haproxy hits this situation - it has its own BIO_METHOD, the same BIO is used for both read and write and it manipulates the retry flags - resulting in it stalling. Issued noted by Thorsten Lockert <tholo@tzecmaun.org> ok beck@ tb@
* Hook X509_STORE_CTX get_issuer() callback from new X509 verifier.jsing2020-11-031-3/+17
| | | | | | | | | | | If we fail to find a parent certificate from either the supplied roots or intermediates and we have a X509_STORE_CTX, call its get_issuer() callback to see if it can supply a suitable certificate. This makes things like certificates by directory (aka by_dir) work correctly. Issue noted by Uwe Werler <uwe@werler.is> ok beck@ tb@
* typo: ASN1_parse_time -> ASN1_time_parsetb2020-11-021-3/+3
|
* some comma fixes; from varik valeforjmc2020-11-011-12/+12
| | | | (audio.4 tweaked from that submitted)
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 05:36:21 +0000