summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Fix a NULL dereference in GENERAL_NAME_cmp()libressl-v3.1.5OPENBSD_6_7tb2020-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 this is errata/6.7/031_asn1.patch.sig
* Unbreak bidirectional SSL_shutdown for TLSv1.3libressl-v3.1.4tb2020-08-171-1/+2
| | | | | | | | | | | The previous errata patch 019_libssl broke bidirectional SSL_shutdown. This can cause a hang in some software that calls SSL_shutdown in a loop. Problem reported and fix tested by Predrag Punosevac. Thanks to Steffen Nurpmeso who independently found that this was due to an SSL_shutdown loop. ok jsing This is errata/6.7/020_libssl.patch.sig
* LibreSSL 3.1.4 - Interoperability and bug fixes for the TLSv1.3 client:tb2020-08-1010-96/+221
| | | | | | | | | | | | | | | | | | | | | | | | | | | * Improve client certificate selection to allow EC certificates instead of only RSA certificates. * Do not error out if a TLSv1.3 server requests an OCSP response as part of a certificate request. * Fix SSL_shutdown behavior to match the legacy stack. The previous behaviour could cause a hang. * Fix a memory leak and add a missing error check in the handling of the key update message. * Fix a memory leak in tls13_record_layer_set_traffic_key. * Avoid calling freezero with a negative size if a server sends a malformed plaintext of all zeroes. * Ensure that only PSS may be used with RSA in TLSv1.3 in order to avoid using PKCS1-based signatures. * Add the P-521 curve to the list of curves supported by default in the client. This is errata/6.7/019_libssl.patch.sig
* OpenBSD 6.7 errata 010, June 11, 2020 (6.7/010_x509.patch.sig)libressl-v3.1.3tb2020-06-101-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | original commit: CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/31 11:23:39 Modified files: lib/libcrypto/x509: x509_vfy.c Log message: When building a chain look for non-expired certificates first. Currently, when building a certificate chain we look up an issuer and if it is the only issuer certificate available we still use it even if it has expired. When X509_V_FLAG_TRUSTED_FIRST is not in use, untrusted certificates are processed first and if one of these happens to be expired it will be used to build the chain, even if there is another non-expired option in the trusted store. Rework this code so that we first look for a non-expired untrusted certificate. If one does not exist then we take a look in the trusted store to see if we would be able to build the chain and only if there is not, do we then look for an expired untrusted certificate. This makes certificate validation possible for various sites that are serving expired AddTrust certificates. Issue reported by Christian Heimes via GitHub. ok beck@ tb@
* LibreSSL 3.1.2bcook2020-05-211-3/+3
|
* OpenBSD 6.7 errata 004 6.7/004_libssl.patch.siglibressl-v3.1.2tb2020-05-193-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | original commits: CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/16 08:44:55 Modified files: lib/libssl : tls13_client.c Log message: Ensure that a TLSv1.3 server has provided a certificate. The RFC requires that a server always provide a certificate for authentication. Ensure that this is the case, rather than proceeding and attempting validation. In the case where validation was disabled and the server returned an empty certificate list, this would have previously resulted in a NULL pointer deference. Issue reported by otto@ ok inoguchi@ tb@ CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/17 08:26:15 Modified files: lib/libssl : tls13_client.c Log message: Send a decode error alert if a server provides an empty certificate list. According to RFC 8446 section 4.4.2.4, a client receiving an empty certificate list must abort the handshake with a decode error alert. ok beck@ inoguchi@ tb@ ('it rarely is the alert you'd expect it to be...')
* This commit was manufactured by cvs2git to create branch 'OPENBSD_6_7'.libressl-v3.1.1cvs2svn2020-05-060-0/+0
|
* Bump LibreSSL version to 3.1.1tb2020-05-061-3/+3
| | | | ok bcook inoguchi deraadt
* Use a larger (2048 bit) RSA test key.jsing2020-05-041-1/+63
| | | | Otherwise we fail to do PSS signatures since the key size is too small.
* Fix out-of-bounds access in tables[][] that was exposed in bluhm'stb2020-05-041-6/+8
| | | | | | regress on i386 after inoguchi moved some symbols to const. ok inoguchi jsing deraadt
* Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.jsing2020-05-031-3/+3
| | | | | | | | | | | | | | | | | | | | | In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@
* Add const to TLS1.3 internal vectorsinoguchi2020-05-022-14/+14
| | | | ok tb@
* Disallow setting the AES-GCM IV length to 0tb2020-04-301-1/+5
| | | | | | | It is possible to do this by abusing the EVP_CTRL_INIT API. Pointed out by jsing. ok inoguchi jsing (as part of a larger diff)
* tls13_record_layer internal functions to static in libsslinoguchi2020-04-291-4/+4
| | | | | | | We might remove static again for further regress around record layer in the future. ok jsing@ tb@
* tls13_handshake internal functions to static in libsslinoguchi2020-04-291-11/+12
| | | | ok jsing@ tb@
* Move legacy stack interfacing functions into tls13_legacy.c.jsing2020-04-284-199/+206
| | | | | | No functional change. ok inoguchi@ tb@
* Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c.jsing2020-04-283-47/+48
| | | | | | | | The server-side will need to use the same function. No functional change. ok inoguchi@ tb@
* Shuffle some functions around.jsing2020-04-272-329/+328
| | | | | | | | | | Move functions so that they are in the order that the TLSv1.3 messages are processed. While here, also move tls13_client_end_of_early_data_send() from tls13_client.c to tls13_server.c. No functional change. ok beck@ tb@
* Fix two bugs in the AES-CBC-PKCS5 tests that didn't hide failing tests:tb2020-04-271-3/+3
| | | | | 1. Use the correct slice for comparing the cipher output 2. Fix logic error similar to the one in AES-GCM in the previous commit
* Fix a logic error that hid the failing ZeroLengthIv tests.tb2020-04-271-3/+3
| | | | This issue was fixed in lib/libcrypto/evp/e_aes.c r1.40.
* Disallow the use of zero length IVs in AES-GCM viatb2020-04-273-3/+15
| | | | | | | | | | | EVP_AEAD_CTX_{open,seal}, as this leaks the authentication key. Issue reported and fix tested by Guido Vranken. ok beck, jsing This commit adds a constant to a public header despite library lock, as discussed with deraadt and sthen.
* Minimal maintenance to make this mess slightly less confusing:schwarze2020-04-261-10/+10
| | | | | | | queue -> list; mention "intrusive"; element -> member at one place; delete a bogus remark that maybe referred to a long-gone implementation in VAX assembly code. Much more could be improved, but i don't want to waste too much time here.
* fix the description; from andras farkasjmc2020-04-261-5/+4
| | | | | | ok schwarze kill a Tn while here...
* Display TLSv1.3 extension type with openssl(1) -tlsextdebuginoguchi2020-04-261-7/+49
| | | | | | | | Add TLSv1.3 extension type, and sort by the definition order in tls1.h. This helps that openssl(1) s_server and s_client with -tlsextdebug displays the TLS extension type instead of "unknown". ok beck@ jsing@ tb@
* s_client: fix use of possibly uninitialized valuesinoguchi2020-04-261-2/+2
| | | | | | | | | | Set initial value to variable 'p' and 'pending'. Reported and fix requested from leonklingele by GitHub pull request. https://github.com/libressl-portable/portable/issues/577 https://github.com/libressl-portable/openbsd/pull/114 ok bcook@ jsing@ tb@
* A comma is not appropriate here, use a semicolonjca2020-04-251-2/+2
| | | | Suggested by Evan Silberman, confirmed by jmc@
* In s_server.c rev. 1.33, jsing added support for "openssl s_server -groups";schwarze2020-04-251-6/+18
| | | | | | | | document it and deprecate "openssl s_server -named_curve". While here, fix the error in the synopsis for "openssl s_client -groups" and use unified argument naming and similar wording like in SSL_CTX_set1_groups_list(3). OK jsing@
* Switch to NEGOTIATED when using WITHOUT_HRR.jsing2020-04-251-4/+9
| | | | | | | | | | This ensures that we remain in a valid handshake state in the TLSv1.3 server. Ideally we would not switch to NEGOTIATED until after record protection has been enabled, but we'll revisit this later. Issue noted by inoguchi@ ok tb@
* Discourage use of RES_USE_INET6jca2020-04-251-1/+5
| | | | Suggested by eric@, input from deraadt@, ok deraadt@ eric@
* Fix RES_USE_INET6 descriptionjca2020-04-251-7/+9
| | | | | | | | | | The previous wording implied this option does nothing, which is wrong. This option does affect the way gethostbyname(3) works on OpenBSD (return IPv6 addresses if available). On some systems, it also introduces IPv4-mapped IPv6 addresses, a "feature" that we don't support. ok deraadt@ eric@
* Move unsupported, obsolete ciphers and deprecated aliases out ofschwarze2020-04-251-31/+29
| | | | | | | | | | | the main list of words to make it more readable, even though it remains long. Avoid using deprecated aliases in explanations what other words mean. Stop documenting aDSS because it is *both* a deprecated alias *and* no longer matches anything at all. General direction discussed with jsing@ some time ago.
* tweak the wording to make it clearer under which conditions exactlyschwarze2020-04-251-4/+4
| | | | | the TLSv1.3 cipher suites are made available, too; related to ssl_ciph.c rev. 1.115
* Revise regress to match state transition changes.jsing2020-04-221-11/+13
|
* Improve TLSv1.3 state machine for HelloRetryRequest handling.jsing2020-04-225-66/+104
| | | | | | | | | | | | | | | | | | | The state machine currently handles the HelloRetryRequest case by using WITH_HRR - in other words, we're explicitly indicating when we transition to the alternate path. The problem here is that we do not know if we're going to receive a ServerHello or a HelloRetryRequest until we process the message. This means that the ServerHello processing code has to handle both types of messages. The state machine and associated processing code becomes cleaner if we flip this around so that we assume we are going to receive a HelloRetryRequest and upon discovering that it is not, trigger WITHOUT_HRR and hand off to the ServerHello processing function. In particular, this makes the logic much more straight forward on the server side, when adding support for HRR. With feedback from tb@ ok tb@
* Handle TLSv1.3 key shares other than X25519 on the server side.jsing2020-04-212-16/+34
| | | | | | | | Previously we would only select an X25519 key share from the client, ignoring any others. Change this so that we will select the first of the key shares that matches one of our supported groups. ok beck@ inoguchi@ tb@
* Consolidate TLSv1.3 constants.jsing2020-04-213-40/+47
| | | | | | | Move all of the TLSv1.3 constants to the top of tls13_lib.c. Also mark these all as const so that they end up in .rodata rather than .data. ok tb@
* Add -groups option to openssl(1) s_server.jsing2020-04-192-35/+31
| | | | | | | | | | This allows supported EC groups to be configured, which will also control which TLSv1.3 key shares we'll accept. While here, deprecate the rather useless -named_curve option, which is effectively the same as -groups with a single group. Also stop setting a single default group of P-256 via SSL_CTX_set_tmp_ecdh() - use the library defaults instead. ok beck@ inoguchi@
* Provide TLSv1.3 cipher suite aliases to match the names used in RFC 8446.jsing2020-04-191-2/+25
| | | | ok beck@ inoguchi@ tb@
* Fix wrapping/indentation.jsing2020-04-181-4/+3
|
* Expose the peer ephemeral public key used for TLSv1.3 key exchange.jsing2020-04-185-36/+79
| | | | | | | | | SSL_get_server_tmp_key() provides the peer ephemeral public key used for key exchange. In the case of TLSv1.3 this is essentially the peer public key from the key share used for TLSv1.3 key exchange, hence make it availaable via SSL_get_server_tmp_key(). ok inoguchi@ tb@
* Tweak previous active cipher suite code.jsing2020-04-181-6/+5
| | | | | | | Use a boolean value rather than using a counter, as suggested by tb@ during the previous review. ok tb@
* Allow more key share groups for TLSv1.3.jsing2020-04-181-21/+12
| | | | | | | | The key share code previously only allowed for key shares to be generated using one of the groups in our default list (X25519, secp256r1, secp384r1). Relax this and allow key shares using any of the groups in our NID list. ok inoguchi@ tb@
* Only include TLSv1.3 cipher suites if there are active cipher suites.jsing2020-04-171-2/+10
| | | | | | | | | | Revise the previous so that we only include TLSv1.3 cipher suites if the cipher rule string resulted in at least one active cipher suite. This more closely matches OpenSSL behaviour. Noted and fix tested by schwarze@ ok beck@ tb@
* Update key share regress to match previous change.jsing2020-04-171-4/+4
|
* Generate client key share using our preferred group.jsing2020-04-174-25/+37
| | | | | | | | Generate a client key share using our preferred group, rather than always using X25519. This means that the key share group can be controlled via SSL{_CTX,}_set1_groups() and SSL{_CTX,}_set1_groups_list(). ok beck@
* Remove AUTHORS section. This follows what is done in strstr.3claudio2020-04-161-4/+2
|
* Replace the simple memmem() implementation with a version that is O(n)claudio2020-04-161-47/+167
| | | | | based on code from musl and now similar to our strstr(). OK tb@ millert@
* Resync our strstr.c with the musl version. Removes some debug code andclaudio2020-04-161-11/+3
| | | | | optimizes one statement in two-way string compare. OK tb@ millert@
* Update in several respects:schwarze2020-04-141-13/+11
| | | | | | | | * mention TLSv1.3 * remove DSS, DES(56), RC4(64), and IDEA(128), which are no longer supported * remove ChaCha20-Poly1305-Old and STREEBOG512 which don't exist in LibreSSL * correct the instruction for printing the complete list OK jsing@
* add the missing sentence "LibreSSL no longer provides any suchschwarze2020-04-141-2/+3
| | | | | cipher suites" to the DES entry and use the same wording for DSS; OK jsing@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-15 21:32:26 +0000