summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* LibreSSL 3.1.4 - Interoperability and bug fixes for the TLSv1.3 client:tb2020-08-101-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Handle TLSv1.3 key shares other than X25519 on the server side.jsing2020-04-211-5/+19
| | | | | | | | 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@
* drop unused include <openssl/curve25519.h>tb2020-02-181-2/+1
| | | | ok inoguchi jsing
* Avoid potential NULL dereference when parsing a server keyshare extension.jsing2020-02-161-1/+4
| | | | | | | | | | | | It is currently possible for key_share to be NULL when a TLS client receives a keyshare extension. However, for this to occur the client has to be doing TLS 1.2 or earlier, which means that it was invalid for the server to send the extension. As such, check for NULL and treat it as an invalid extension. Found by oss-fuzz (#20741 and #20745). ok inoguchi@ tb@
* Correctly handle key share extensions in a hello retry request.jsing2020-02-061-3/+9
| | | | | | | | In a hello retry request the server will only send the selected group and not actually provide a key exchange. In this case we need to store the server selected group for further processing. ok tb@
* Correctly unpack client key shares.jsing2020-02-011-4/+9
| | | | | | | | Even if we're not processing/using the peer public key from the key share, we still need to unpack it in order to parse the TLS extension correctly. Resolves issues with TLSv1.3 clients talking to TLSv1.2 server. ok tb@
* Provide struct/functions for handling TLSv1.3 key shares.jsing2020-01-301-92/+17
| | | | | | | Pull out the key share handling code and provide a clean/self contained interface. This will make it easier to support groups other than X25519. ok beck@ inoguchi@ tb@
* Add sigalgs for server side to enable client certificate processingbeck2020-01-261-5/+34
| | | | | | | | in tls 1.3 Will be used in a follow on commit to enable tls1.3 client certificates ok jsing@
* Only discard the extension block for client hello and server hellojsing2020-01-251-2/+3
| | | | | | | | | messages. TLSv1.3 messages that include extensions need a length prefixed field with zero bytes, rather than no data at all. ok beck@ tb@
* Only send an RI extension for pre-TLSv1.3 versions.jsing2020-01-251-2/+2
| | | | ok beck@
* Rename failure into alert_desc in tlsext_ocsp_server_parse().tb2020-01-221-5/+5
|
* fix previous: alert_desc needs to be an int.tb2020-01-221-2/+2
|
* Avoid modifying alert in the success path.tb2020-01-221-11/+17
| | | | ok beck jsing
* Revert previous deduplication diff, I broke portable in a strange way.beck2019-11-161-47/+58
| | | | | I'll figure it out a bit later. Found and diagnosed by inoguchi@
* Deduplicate some extension processing code.beck2019-11-151-58/+47
| | | | ok tb@ inoguchi@
* Relax parsing of TLS key share extensions on the server.jsing2019-05-291-5/+2
| | | | | | | | | | | The RFC does not require X25519 and it also allows clients to send an empty key share when the want the server to select a group. The current behaviour results in handshake failures where the client supports TLS 1.3 and sends a TLS key share extension that does not contain X25519. Issue reported by Hubert Kario via github. ok tb@
* Do not send an SNI extension when resuming a session that contains a serverjsing2019-05-291-1/+4
| | | | | | | | name (which means the client sent SNI during the initial handshake). Issue reported by Renaud Allard. ok tb@
* Fix typo and label indent.jsing2019-05-281-3/+3
|
* Tidy up some names/structures following the renaming of TLS extensionjsing2019-05-281-35/+35
| | | | | | | | | functions based on message type (clienthello/serverhello), to which side is handling the processing. No intended functional change. ok beck@
* In DTLS, use_srtp is part of the extended server hello while in TLSv1.3,tb2019-05-081-2/+3
| | | | | | | | | | it is an encrypted extension. Include it in the server hello for now. This will have to be revisited once TLSv1.3 gets there. Fixes SRTP negotiation. Problem found by two rust-openssl regress failures reported by mikeb. with & ok beck
* Defer sigalgs selection until the certificate is known.jsing2019-03-251-9/+6
| | | | | | | | | | | | | Previously the signature algorithm was selected when the TLS extension was parsed (or the client received a certificate request), however the actual certificate to be used is not known at this stage. This leads to various problems, including the selection of a signature algorithm that cannot be used with the certificate key size (as found by jeremy@ via ruby regress). Instead, store the signature algorithms list and only select a signature algorithm when we're ready to do signature generation. Joint work with beck@.
* Revert TLS1_get{,_client}_version simplification because DTLS.jsing2019-03-191-5/+5
|
* Partially clean up the TLS1_get_{,client}_version macros.jsing2019-03-171-5/+5
| | | | | | | | | LibreSSL only supports TLSv1.0 and above, hence the checks the macros are performing are useless. Simplify them to their effective code. Also place both under #ifndef LIBRESSL_INTERNAL and use the variables directly in our code, which improves readability. ok tb@
* Revert r1.38 as it introduces use of a stack value post function return.jsing2019-02-031-50/+86
| | | | | The deduplication is also not quite right - this will be revisited in due course.
* unwrap a line introduced in previous.tb2019-01-311-3/+2
|
* Correct handling of TLS sigalgs extension for TLSv1.0/TLSv1.1.jsing2019-01-301-33/+19
| | | | | | | | | | | | | When operating as a TLSv1.0 or TLSv1.1 server, we still have to parse the TLS sigalgs extension if presented by the client (which might be TLSv1.2 capable), rather than treating its presence as an error. While here, remove future version dependence issues by avoiding explicit version equality checks. Issue reported by bluhm@. ok bluhm@ tb@
* Deduplicate a bunch of replicated code in the extension handlingbeck2019-01-281-86/+50
| | | | ok tb@
* Add tls_extension_seen(), a utility to know if a particular extensionbeck2019-01-281-8/+13
| | | | | has been seen in the handshake so far. Use it for keyshare. ok tb@
* Add server side of versions, keyshare, and client and server of cookiebeck2019-01-241-19/+289
| | | | | | | | extensions for tls1.3. versions is currently defanged to ignore its result until tls13 server side wired in full, so that server side code still works today when we only support tls 1.2 ok bcook@ tb@ jsing@
* move the extensions_seen into the handshake structbeck2019-01-241-4/+5
| | | | ok jsing@
* Modify sigalgs extension processing to accomodate TLS 1.3.beck2019-01-231-3/+33
| | | | | | | | | | - Make a separate sigalgs list for TLS 1.3 including only modern algorithm choices which we use when the handshake will not negotiate TLS 1.2. - Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2 from a 1.3 handshake. ok jsing@ tb@
* revert previous, accidentally contained another diff in additionbeck2019-01-231-326/+22
| | | | to the one I intended to commit
* Modify sigalgs extension processing for TLS 1.3.beck2019-01-231-22/+326
| | | | | | | | | - Make a separate sigalgs list for TLS 1.3 including only modern algorithm choices which we use when the handshake will not negotiate TLS 1.2 - Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2 ok jsing@ tb@
* TLS 1.3 clients always need to send the supported groups extension.jsing2019-01-201-4/+5
| | | | | | A couple of cleanup/style tweaks while here. ok tb@
* bump copyright years appopriatelybeck2019-01-181-3/+3
|
* Add client side of supported versions and keyshare extensions with basic regressbeck2019-01-181-1/+222
| | | | ok jsing@
* Add support for RFC 8446 section 4.2 enforcing which extensions maybeck2019-01-181-8/+43
| | | | | appear with which messages. ok jsing@
* Rename TLS extension handling to use less "hello".jsing2019-01-181-148/+147
| | | | | | | | | | | | | | | | | | | | | | | When the TLS extension code was rewritten, TLS extensions could only exist in ClientHello and ServerHello messages - as such, they were named in pairs of *_clienthello_{needs,build} which would be called by the client and *_clienthello_parse. Likewise for *_serverhello_{needs,build} which would be called by a server and *_serverhello_parse, which would be called by a client. Enter TLSv1.3 - TLS extensions can now exist in one of seven messages, with only certain types being allowed to appear in each, meaning the naming scheme no longer works. Instead, rename them to indicate the caller rather than the message type - this effectively means: clienthello_needs -> client_needs clienthello_build -> client_build clienthello_parse -> server_parse serverhello_needs -> server_needs serverhello_build -> server_build serverhello_parse -> client_parse ok beck@ tb@
* Add the ability to have a separate priority list for sigalgs.beck2018-11-091-2/+2
| | | | | Add a priority list for tls 1.2 ok jsing@
* Reimplement the sigalgs processing code into a new implementationbeck2018-11-091-6/+5
| | | | | that will be usable with TLS 1.3 with less eye bleed. ok jsing@ tb@
* Rename the TLS Supported Elliptic Curves extension to Supported Groups.jsing2018-11-051-39/+38
| | | | | | | | | RFC 7919 renamed the Supported Elliptic Curves TLS extension to Supported Groups and redefined it to include finite field DH (FFDH) in addition to elliptic curve DH (ECDH). As such, rename the TLS extension and change the associated code to refer to groups rather than curves. ok beck@ tb@
* Rework the TLS extension handling code to improve readability/flexibility,jsing2018-11-051-89/+112
| | | | | | by moving the needs/build/parse functions into their own struct. ok beck@ tb@
* If we fail to decode an EC point format extension, send a decode_errorjsing2018-05-121-4/+6
| | | | | | | | alert rather than an internal_error alert. Issue found by Simon Friedberger, Robert Merget and Juraj Somorovsky. ok beck@ inoguchi@
* Complete the TLS extension rewrite on the client-side.jsing2018-02-081-69/+72
| | | | | | | | | | | The RI logic gets pulled up into ssl3_get_server_hello() and ssl_parse_serverhello_tlsext() gets replaced by tlsext_client_parse(), which allows a CBS to be passed all the way down. This also deduplicates the tlsext_client_build() and tlsext_server_build() code. ok beck@
* Complete the TLS extension handling rewrite for the server-side.jsing2018-01-271-13/+69
| | | | | | | | | | | | | This removes ssl_parse_clienthello_tlsext() and allows the CBS to be passed all the way through from ssl3_get_client_hello(). The renegotation check gets pulled up into ssl3_get_client_hello() which is where other such checks exist. The TLS extension parsing now also ensures that we do not get duplicates of any known extensions (the old pre-rewrite code only did this for some extensions). ok inoguchi@
* Clarify the comment re the F5 EC curves extension bug.jsing2018-01-271-5/+6
| | | | Also reference the knowledge base article instead of a discussion thread.
* Correct TLS extensions handling when no extensions are present.jsing2017-11-281-1/+13
| | | | | | | | If no TLS extensions are present in a client hello or server hello, omit the entire extensions block, rather than including it with a length of zero. ok beck@ inoguchi@
* Fix various issues in the OCSP extension parsing code:jsing2017-09-251-20/+14
| | | | | | | | | | | | | | | | | | - When parsing the OCSP extension we can have multiple responder IDs - pull these out correctly. - Stop using CBS_stow() - it's unnecessary since we just need access to the data and length (which we can get via CBS_data() and CBS_len()). - Use a temporary pointer when calling d2i_*() functions, since it will increment the pointer by the number of bytes it consumed when decoding. The original code incorrectly passes the pointer allocated via CBS_stow() (using malloc()) to a d2i_*() function and then calls free() on the now incremented pointer, most likely resulting in a crash. This issue was reported by Robert Swiecki who found the issue using honggfuzz. ok beck@
* When building the OCSP extension, only add the length prefixed extensionsjsing2017-09-251-6/+6
| | | | | | | after we finish building the responder ID list. Otherwise adding to the responder ID list fails. ok beck@
* Move the full extension building into tlsext_{client,server}hello_build(),jsing2017-08-301-13/+17
| | | | | | leaving ssl_add_{client,server}hello_tlsext() as pointer to CBB wrappers. ok doug@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 16:44:39 +0000