summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix TLS key share check to not fire when using < TLS 1.3beck2024-07-091-7/+6
| | | | | | | | | | | | The check was being too aggressive and was catching us when the extension was being sent by a client which supports tls 1.3 but the server was capped at TLS 1.2. This moves the check after the max version check, so we won't error out if we do not support TLS 1.3 Reported by obsd@bartula.de ok tb@
* remove psk_idx from tlsext_randomize_build_order()tb2024-06-261-3/+3
| | | | ok jsing
* tls_extension_find(): make output index optionaltb2024-06-261-2/+3
| | | | suggested by jsing
* Fix TLS extension shufflingtb2024-06-251-2/+2
| | | | | | | The diff decoupling the shuffle from the table order still relied on PSK being last because it failed to adjust the upper bound in the for loop. ok jsing
* ssl_tlsext: fix uninitialized variable warning with gcctb2024-06-061-2/+3
| | | | | | | | This is a false positive but as is well-known, gcc is terrible at understanding conditionally initialized variables and it is tedious to explain this to downstream maintainers who look at warnings. ok miod
* Fix key share negotiation in HRR casetb2024-04-161-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | In the ClientHello retrying the handshake after a HelloRetryRequest, the client must send a single key share matching the group selected by the server in the HRR. This is not necessarily the mutually preferred group. Incorrect logic added in ssl_tlsect.c r1.134 would potentially reject such a key share because of that. Instead, add logic to ensure on the server side that there is a single share matching the group we selected in the HRR. Fixes a regress test in p5-IO-Socket-SSL where server is configured with P-521:P-384 and the client with P-256:P-384:P-521. Since the client sends an initial P-256 key share, a HRR is triggered which the faulty logic rejected because it was not the mutually preferred P-384 but rather matching the server-selected P-521. This will need some deduplication in subsequent commits. We may also want to consider honoring the mutual preference and request a key accordingly in the HRR. reported by bluhm, fix suggested by jsing ok beck jsing
* Recommit a better version of the removal of the F5 workaroundtb2024-04-041-9/+12
| | | | | | | | | | | | | | | | Unlike for previous TLS versions, TLSv1.3 servers can send the supported groups extension to inform a client of the server's preferences. The intention is that a client can adapt for subsequent commits. We ignore this info for now, but sthen ran into java-based servers that do this. Thus, rejecting the extension outright was incorrect. Instead, only allow the extension in TLSv1.3 encrypted extensions. This way the F5 workaround is also disabled, but we continue to interoperate with TLSv1.3 servers that do follow the last paragraph of RFC 8446, section 4.2.7. This mostly adjusts outdated/misleading comments. ok jsing sthen
* Backout previous commit (intending that libressl client rejects a supportedsthen2024-04-021-3/+17
| | | | | | | | groups extension from the server). It triggers 'CONNECT_CR_SRVR_HELLO:tlsv1 alert decode error' when connecting to a (modern) java server (tomcat 10.1.18 on openjdk 17.0.10). "please revert" tb@
* Stop pandering to the loadbalancer industrial complex.beck2024-03-281-17/+3
| | | | | | | | | | | | | | | | | So we initially kept this hack around for f5 boxes that should have been patched in 2014, and were not as of 2017. The f5 article for the bug archived on their web site, and any of these devices on the public internet will have since been upgraded to deal with a host of record layer, TLS, and other bugs, or they likely won't be talking to modern stacks, since as of this point the software with the bug would not have been updated in 10 years. So just make this spec compliant and reject a supported groups extension that should not have been sent by a server. ok tb@ jsing@
* Fix up server processing of key shares.beck2024-03-271-8/+77
| | | | | | | | | | | | | | | | | | | Ensure that the client can not provide a duplicate key share for any group, or send more key shares than groups they support. Ensure that the key shares must be provided in the same order as the client preference order specified in supported_groups. Ensure we only will choose to use a key share that is for the most preferred group by the client that we also support, to avoid the client being downgraded by sending a less preferred key share. If we do not end up with a key share for the most preferred mutually supported group, will then do a hello retry request selecting that group. Add regress for this to regress/tlsext/tlsexttest.c ok jsing@
* Do not allow duplicate groups in supported groups.beck2024-03-271-18/+39
| | | | | | While we are here refactor this to single return. ok jsing@ tb@
* Add an indicator that an extension has been processed.beck2024-03-261-1/+15
| | | | ok jsing@
* Process supported groups before key share.beck2024-03-261-15/+15
| | | | | | | This will allow us to know the client preferences for an upcoming change to key share processing. ok jsing@
* Simplify TLS extension parsing and processing.jsing2024-03-251-155/+98
| | | | | | | | | Rather than having a separate parse and process step for each TLS extension, do a first pass that parses all of the TLS outer extensions and retains the extension data, before running a second pass that calls the TLS extension processing code. ok beck@ tb@
* Fix typo msg_types -> msg_typetb2024-03-251-2/+2
| | | | from jsing
* Split TLS extension parsing from processing.jsing2024-03-251-55/+190
| | | | | | | | | | | | | The TLS extension parsing and processing order is currently dependent on the order of the extensions in the handshake message. This means that the processing order (and callback order) is not under our control. Split the parsing from the processing such that the processing (and callbacks) are run in a defined order. Convert ALPN to the new model - other extensions will be split into separate parse/process in following diffs. ok beck@ tb@
* Decouple TLS extension table order from tlsext_randomize_build_order()jsing2024-03-251-6/+7
| | | | | | | | | The PSK extension must be the last extension in the client hello. This is currently implemented by relying on the fact that it is the last extension in the TLS extension table. Remove this dependency so that we can reorder the table as needed. ok tb@
* Too many stupid things whine about these being used uninitializedtb2023-04-281-2/+2
| | | | (which they aren't), so appease them.
* ssl_tlsext.c: Add an accessor for the tls extension type.tb2023-04-271-1/+7
| | | | | | Needed for the tlsexttest.c ok jsing
* Fix allocation sizetb2023-04-251-3/+3
| | | | Reported by anton
* Free and calloc() the tlsext_build_order and remember its lengthtb2023-04-241-2/+14
| | | | | | | Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order() and will help regression testing. ok jsing
* Use TLSEXT_TYPE_alpn instead of the stupid long onetb2023-04-241-2/+2
|
* Randomize the order of TLS extensionstb2023-04-231-2/+61
| | | | | | | | | | | | | | | | | | | | | On creation of an SSL using SSL_new(), randomize the order in which the extensions will be sent. There are several constraints: the PSK extension must always come last. The order cannot be randomized on a per-message basis as the strict interpretation of the standard chosen in the CH hashing doesn't allow changing the order between first and second ClientHello. Another constraint is that the current code calls callbacks directly on parsing an extension, which means that the order callbacks are called depends on the order in which the peer sent the extensions. This results in breaking apache-httpd setups using virtual hosts with full ranomization because virtual hosts don't work if the SNI is unknown at the time the ALPN callback is called. So for the time being, we ensure that SNI always precedes ALPN to avoid issues until this issue is fixed. This is based on an idea by David Benjamin https://boringssl-review.googlesource.com/c/boringssl/+/48045 Input & ok jsing
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.jsing2022-10-021-66/+66
| | | | | | | | These are no longer necessary due to SSL_CTX and SSL now being fully opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back into SSL. Prompted by tb@
* Avoid shadowing the cbs function parameter in tlsext_alpn_server_parse()tb2022-08-151-6/+4
| | | | ok jsing
* Make tlsext_*_{build,needs,parse}() functions statictb2022-08-041-93/+92
| | | | | | | | | None of these functions are used outside of ssl_tlsext.c. The only reason they are prototyped in the header is for the use of tlsexttest.c. Rather than having a big pile of useless copy-paste in the header, we can adapt the test to avoid using these functions directly. ok jsing
* Rely on tlsext_parse() to set a decode_error alerttb2022-07-241-79/+47
| | | | | | | | Instead of setting the alert manually in various parse handlers, we can make use of the fact that tlsext_parse() sets the alert to decode_error by default. This simplifies the code quite a bit. ok jsing
* Remove redundant length checks in parse functionstb2022-07-221-21/+1
| | | | | | | | | | | The main parsing function already checks that the entire extension data was consumed, so the length checks inside some of the parse handlers are redundant. They were also not done everywhere, so this makes the parse handlers more consistent. Similar diff was sent by jsing a long while back ok jsing
* Simplify tlsext_supported_groups_server_parsetb2022-07-201-45/+31
| | | | | | | | | Add an early return in the s->internal->hit case so that we can unindent a lot of this code. In the HRR case, we do not need to check that the list of supported groups is unmodified from the first CH. The CH extension hashing already does that for us. ok jsing
* Drop some unnecessary parentheses.tb2022-07-201-3/+2
| | | | ok jsing
* Copy alpn_selected using CBStb2022-07-201-6/+7
| | | | ok jsing
* Factor out ALPN extension format checktb2022-07-201-13/+25
| | | | | | | | The ALPN extension must contain a non-empty list of protocol names. Split a check of this out of tlsext_alpn_server_parse() so that it can be reused elsewhere in the library. ok jsing
* Correct handling of QUIC transport parameters extension.jsing2022-07-171-48/+16
| | | | | | | | | | | Remove duplicate U16 length prefix, since tlsext_build() already adds this for us. Condition on SSL_is_quic() rather than TLS version - RFC 9001 is clear that this extension is only permitted on QUIC transport and an fatal unsupported extension alert is required if used elsewhere. Additionally, at the point where extensions are parsed, we do not necessarily know what TLS version has been negotiated. ok beck@ tb@
* Correct TLSEXT_TYPE_quic_transport_parameters message types.jsing2022-07-171-2/+2
| | | | | | | Per RFC 9001, TLSEXT_TYPE_quic_transport_parameters may only appear in ClientHello and EncryptedExtensions (not ServerHello). ok beck@ tb@
* Stop using ssl{_ctx,}_security() outside of ssl_seclevel.ctb2022-07-021-3/+3
| | | | | | | | | The API is ugly and we can easily abstract it away. The SSL_SECOP_* stuff is now confined into ssl_seclevel.c and the rest of the library can make use of the more straightforward wrappers, which makes it a lot easier on the eyes. ok beck jsing
* Rename uses 'curve' to 'group' and rework tls1 group API.tb2022-07-021-2/+2
| | | | | | | | | | This reworks various tls1_ curve APIs to indicate success via a boolean return value and move the output to an out parameter. This makes the caller code easier and more consistent. Based on a suggestion by jsing ok jsing
* Check security level for supported groups.tb2022-06-301-1/+3
| | | | ok jsing
* Check whether the security level allows session tickets.tb2022-06-301-2/+6
| | | | ok beck jsing
* Add support for sending QUIC transport parametersbeck2022-06-291-1/+121
| | | | | | | | | | This is the start of adding the boringssl API for QUIC support, and the TLS extensions necessary to send and receive QUIC transport data. Inspired by boringssl's https://boringssl-review.googlesource.com/24464 ok jsing@ tb@
* Check the security level when building sigalgstb2022-06-291-3/+4
| | | | ok beck jsing
* The parse stubs need to skip over the extension data.tb2022-06-041-3/+3
| | | | | | Found by anton with tlsfuzzer ok anton
* Add stubbed out handlers for the pre_shared_key extensiontb2022-06-031-1/+57
| | | | ok jsing
* Implement handlers for the psk_key_exchange_modes extensions.tb2022-06-031-2/+86
| | | | ok jsing
* Bye bye S3I.jsing2022-02-051-100/+100
| | | | | | | | S3I has served us well, however now that libssl is fully opaque it is time to say goodbye. Aside from removing the calloc/free/memset, the rest is mechanical sed. ok inoguchi@ tb@
* Avoid use of uninitialized in tlsext_sni_server_parse()tb2022-01-241-1/+3
| | | | | | | | | If the hostname is too long, tlsext_sni_is_valid_hostname() will fail without having initialized *is_ip. As a result, the garbage value could lead to accepting (but otherwise ignoring) overlong and possibly invalid hostnames without erroring in tlsext_sni_server_parse(). ok inoguchi jsing
* Plumb decode errors through key share parsing code.jsing2022-01-111-3/+11
| | | | | | | | | | | | Distinguish between decode errors and other errors, so that we can send a SSL_AD_DECODE_ERROR alert when appropriate. Fixes a tlsfuzzer failure, due to it expecting a decode error alert and not receiving one. Prompted by anton@ ok tb@
* Use SSL_AD_INTERNAL_ERROR for non-decoding alerts when parsing keyshares.jsing2022-01-111-4/+10
| | | | ok tb@
* Simplify tlsext_keyshare_server_parse()jsing2022-01-111-9/+5
| | | | | | | SSL_AD_DECODE_ERROR is the default alert for a TLS extension parsing failure - remove the various gotos and simply return 0 instead. ok tb@
* Convert legacy TLS client to tls_key_share.jsing2022-01-061-12/+8
| | | | | | | | | This requires adding DHE support to tls_key_share. In doing so, tls_key_share_peer_public() has to lose the group argument and gains an invalid_key argument. The one place that actually needs the group check is tlsext_keyshare_client_parse(), so add code to do this. ok inoguchi@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 16:48:37 +0000