summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_lib.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Provide SSL_OP_NO_RENEGOTIATION and SSL_OP_ALLOW_CLIENT_RENEGOTIATION.jsing5 days1-1/+11
| | | | | | | | | | | | | | | | | | | | | | In January 2017 we added SSL_OP_NO_CLIENT_RENEGOTIATION, which results in a SSL_AD_NO_RENEGOTIATION fatal alert if a ClientHello message is seen on an active connection (client initiated renegotation). Then in May 2017 OpenSSL added SSL_OP_NO_RENEGOTIATION, which results in a SSL_AD_NO_RENEGOTIATION warning alert if a server receives a ClientHello on an active connection (client initiated renegotation), or a client receives a HelloRequest (server requested renegotation). This option also causes calls to SSL_renegotiate() and SSL_renegotiate_abbreviated() to fail. Then in 2021, OpenSSL also added SSL_OP_ALLOW_CLIENT_RENEGOTIATION, which trumps SSL_OP_NO_RENEGOTIATION but only for incoming ClientHello messages (apparently unsetting SSL_OP_NO_RENEGOTIATION is too hard). Provide SSL_OP_NO_RENEGOTIATION and SSL_OP_ALLOW_CLIENT_RENEGOTIATION, primarily to make life easier for ports. If SSL_OP_NO_CLIENT_RENEGOTIATION is set it will take precedence and render SSL_OP_ALLOW_CLIENT_RENEGOTIATION ineffective. The rest of the behaviour should match OpenSSL, with the exception of ClientHellos triggering fatal alerts instead of warnings. ok tb@
* Reinstate bounds check accidentally disabled when defining OPENSSL_NO_DTLS1tb2024-09-221-3/+1
| | | | | From Kenjiro Nakayama Closes https://github.com/libressl/portable/issues/1097
* Prepare to provide SSL_CTX_set1_cert_store()tb2024-08-031-1/+11
| | | | | | | | | | | | | | | | SSL_CTX_set_cert_store() should have been called SSL_CTX_set0_cert_store() since it takes ownership of the store argument. Apparently a few people ran into the issue of not bumping the refcount themselves, leading to use after frees about 10 years ago. This is a quite rarely used API and there are no misuses in the ports tree, but since someone did the work of writing a diff, we can still add it. Needless to say that SSL_CTX_get_cert_store() obviously has the exact same issue and nobody seems to have thought of adding a get0 or get1 version to match... Fixes https://github.com/libressl/openbsd/issues/71 From Kenjiro Nakayama
* Remove cipher from SSL_SESSION.jsing2024-07-201-4/+3
| | | | | | | | | | | | | | | | For a long time SSL_SESSION has had both a cipher ID and a pointer to an SSL_CIPHER (and not both are guaranteed to be populated). There is also a pointer to an SSL_CIPHER in the SSL_HANDSHAKE that denotes the cipher being used for this connection. Some code has been using the cipher from SSL_SESSION and some code has been using the cipher from SSL_HANDSHAKE. Remove cipher from SSL_SESSION and use the version in SSL_HANDSHAKE everywhere. If resuming from a session then we need to use the SSL_SESSION cipher ID to set the SSL_HANDSHAKE cipher. And we still need to ensure that we update the cipher ID in the SSL_SESSION whenever the SSL_HANDSHAKE cipher changes (this only occurs in a few places). ok tb@
* Move client ciphers from SSL_SESSION to SSL_HANDSHAKE.jsing2024-07-191-5/+5
| | | | | | | | SSL_SESSION has a 'ciphers' member which contains a list of ciphers that were advertised by the client. Move this from SSL_SESSION to SSL_HANDSHAKE and rename it to match reality. ok tb@
* Follow BoringSSL's nomenclature in SSL_select_next_proto()tb2024-07-111-28/+30
| | | | | | | | | | | | | | | | | | | SSL_select_next_poto() was written with NPN in mind. NPN has a weird fallback mechanism which is baked into the API. This is makes no sense for ALPN, where the API behavior is undesirable since it a server should not end up choosing a protocol it doesn't (want to) support. Arguably, ALPN should simply have had its own API for protocol selection supporting the proper semantics, instead of shoehorning an NPN API into working for ALPN. Commit https://boringssl-review.googlesource.com/c/boringssl/+/17206/ renamed the arguments to work for both NPN and ALPN, with the slight downside of honoring client preference instead of the SHOULD in RFC 7301, section 3.2. This grates for most consumers in the wild, but so be it. The behavior is saner and safer. discussed with davidben ok beck
* fix typotb2024-06-291-2/+2
|
* Fix SSL_select_next_proto()tb2024-06-281-29/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SSL_select_next_proto() is already quite broken by its design: const in, non-const out, with the intention of pointing somewhere inside of the two input pointers. A length returned in an unsigned char (because, you know, the individual protocols are encoded in Pascal strings). Can't signal uailure either. It also has an unreachable public return code. Also, due to originally catering to NPN, this function opportunistically selects a protocol from the second input (client) parameters, which makes little sense for ALPN since that means the server falls back to a protocol it doesn't (want to) support. If there's no overlap, it's the callback's job to signal error to its caller for ALPN. As if that wasn't enough misdesign and bugs, the one we're concerned with here wasn't reported to us twice in ten years is that if you pass this API a zero-length (or a sufficiently malformed client protocol list), it would return a pointer pointing somewhere into the heap instead into one of the two input pointers. This pointer could then be interpreted as a Pascal string, resulting in an information disclosure of up to 255 bytes from the heap to the peer, or a crash. This can only happen for NPN (where it does happen in old python and node). A long time ago jsing removed NPN support from LibreSSL, because it had an utter garbage implementation and because it was practically unused. First it was already replaced by the somewhat less bad ALPN, and the only users were the always same language bindings that tend to use every feature they shouldn't use. There were a lot of complaints due to failing test cases in there, but in the end the decision turned out to be the right one: the consequence is that LibreSSL isn't vulnerable to CVE-2024-5535. Still, there is a bug here to fix. It is completely straightforward to do so. Rewrite this mess using CBS, preserving the current behavior. Also, we do not follow BoringSSL's renaming of the variables. It would result in confusing code in almost all alpn callbacks I've seen in the wild. The only exception is the accidental example of Qt. ok jsing
* Unexport SSL_version_strtb2024-04-151-3/+1
| | | | ok jsing
* Unify up_ref implementations in libssltb2024-03-271-5/+3
| | | | ok jsing
* Remove SSL_debugtb2024-03-021-8/+1
| | | | | | | The garbage truck is quite full by now. Collect the last symbol straggler for this bump. ok jsing
* Of course libssl also has a few missing voidtb2024-02-041-2/+2
| | | | From Christian Andersen
* Remove GOST and STREEBOG support from libssl.beck2024-02-031-9/+1
| | | | | | | | | | | | | | | | | | This version of GOST is old and not anywhere close to compliant with modern GOST standards. It is also very intrusive in libssl and makes a mess everywhere. Efforts to entice a suitably minded anyone to care about it have been unsuccessful. At this point it is probably best to remove this, and if someone ever showed up who truly needed a working version, it should be a clean implementation from scratch, and have it use something closer to the typical API in libcrypto so it would integrate less painfully here. This removes it from libssl in preparation for it's removal from libcrypto with a future major bump ok tb@
* Neuter the SSL_set_debug(3) APItb2023-12-291-4/+2
| | | | | | | | | | | The TLSv1.3 stack didn't support this in the first place, and in the legacy stack it only added some dubious BIO_flush(3) calls. The sleep call between SSL_read(3) and SSL_write(3) advertised in the comment next to the flag has been a sleep call in the s_server since time immemorial, nota bene between calls to BIO_gets(3). Anyway. This can all go and what remains will go with the next major bump. ok jsing
* Convert ssl3_cipher_by_id() to bsearch()tb2023-11-291-28/+1
| | | | | | | | | | | | | | | | | This was previously the only user of OBJ_bsearch_ssl_cipher_id(), which in turn is the one remaining user of OBJ_bsearch_() outside of libcrypto. OBJ_bsearch_() is OpenSSL's idiosyncratic reimplementation of ANSI C89's bsearch(). Since this used to be hidden behind macro insanity, the result was three inscrutable layers of comparison functions. It is much simpler and cleaner to use the standard API. Move all the code to s3_lib.c, since it's ony used there. In a few further diffs, OBJ_bsearch_() will be removed from libcrypto. Unfortunately, we'll need to keep OBJ_bsearch_ex(), because it is exposed via sk_find_ex(), which is exposed by M2Crypto... ok jsing
* Move ssl_cipher_id_cmp() next to its only callertb2023-11-251-13/+13
| | | | | | It was left alone and forlorn in the middle of other nonsense. Since there is only one caller (the OBJ_bsearch_ stupidity), it can be static and there is no need to prototype it in ssl_local.h.
* Unifdef OPENSSL_NO_ENGINE in libssltb2023-11-191-29/+1
| | | | | | As usual, a few manual fixes to avoid duplicate lines. ok jsing
* More 0/NULL confusions in SSL_CTX_new()tb2023-09-191-8/+8
|
* Fix some NULL/0 misspellings in SSL_CTX_new()tb2023-09-191-5/+5
|
* Fix two aliases in libcrypto spotted by the new symbols testtb2023-07-191-1/+2
| | | | ok jsing
* Hide all public symbols in libsslbeck2023-07-081-1/+196
| | | | | | With the guentherizer 9000 ok tb@
* Move verified_chain from SSL to SSL_HANDSHAKEtb2023-05-261-2/+4
| | | | | | | | This is a better version of the fix for the missing pointer invalidation but a bit larger, so errata got the minimal fix. tested by jcs ok jsing
* Randomize the order of TLS extensionstb2023-04-231-1/+6
| | | | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | | | 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
* Rewrite TLSv1.2 key exporter.jsing2022-11-071-10/+11
| | | | | | | Replace the grotty TLSv1.2 key exporter with a cleaner version that uses CBB and CBS. ok tb@
* Get rid of SSL_CTX_INTERNAL and SSL_INTERNAL.jsing2022-10-021-340/+331
| | | | | | | | 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@
* Provide a version of ssl_msg_callback() that takes a CBS.jsing2022-09-101-4/+12
| | | | | | Use this from the TLSv1.3 code. ok tb@
* Provide the remaining QUIC API.jsing2022-08-211-1/+106
| | | | | | | While more work is still required, this is sufficient to get ngtcp2 to compile with QUIC and for curl to be able to make HTTP/3 requests. ok tb@
* Provide SSL_QUIC_METHOD.jsing2022-08-211-1/+24
| | | | | | | | | | | | | | | | | | | This provides SSL_QUIC_METHOD (aka ssl_quic_method_st), which allows for QUIC callback hooks to be passed to an SSL_CTX or SSL. This is largely ported/adapted from BoringSSL. It is worth noting that this struct is not opaque and the original interface exposed by BoringSSL differs to the one they now use. The original interface was copied by quictls and it appears that this API will not be updated to match BoringSSL. To make things even more challenging, at least one consumer does not use named initialisers, making code completely dependent on the order in which the function pointers are defined as struct members. In order to try to support both variants, the set_read_secret/set_write_secret functions are included, however they have to go at the end. ok tb@
* Ensure that SSL_{peek,read,write}() are not called if QUIC is in use.jsing2022-08-211-1/+16
| | | | ok tb@
* Deduplicate peer certificate chain processing code.jsing2022-08-171-5/+8
| | | | | | | | | | | | | | Rather than reimplement this in each TLS client and server, deduplicate it into a single function. Furthermore, rather than dealing with the API hazard that is SSL_get_peer_cert_chain() in this code, simply produce two chains - one that has the leaf and one that does not. SSL_get_peer_cert_chain() can then return the appropriate one. This also moves the peer cert chain from the SSL_SESSION to the SSL_HANDSHAKE, which makes more sense since it is not available on resumption. ok tb@
* Move cipher_id bsearch functions back to the bottom of the file.jsing2022-07-241-16/+16
|
* Copy alpn_client_proto_list using CBS in SSL_new()tb2022-07-201-12/+7
| | | | | | | This makes the code both shorter and safer since freeing, allocation, and copying are handled by CBS_stow() internally. ok jsing
* Validate protocols in SSL{_CTX,}_set_alpn_protos()tb2022-07-201-1/+12
| | | | | | | | | | | This wonderful API requires users to pass the protocol list in wire format. This list is then sent as part of the ClientHello. Validate it to be of the correct form. This reuses tlsext_alpn_check_format() that was split out of tlsext_alpn_server_parse(). Similar checks were introduced in OpenSSL 86a90dc7 ok jsing
* Rewrite SSL{_CTX,}_set_alpn_protos() using CBStb2022-07-201-23/+15
| | | | | | | | | This simplifies the freeing, assigning and copying of the passed protocols by replacing all that code with a pair of CBS_init() and CBS_stow(). In addition, this aligns the behavior with OpenSSL, which no longer errors on NULL proto or 0 proto_len since 86a90dc7. ok jsing
* Provide SSL_is_quic()jsing2022-07-171-1/+7
| | | | | | | | This function will allow code to know if the SSL connection is configured for use with QUIC or not. Also move existing SSL_.*quic.* functions under LIBRESSL_HAS_QUIC to prevent exposing them prematurely. ok beck@ tb@
* Stop using ssl{_ctx,}_security() outside of ssl_seclevel.ctb2022-07-021-3/+2
| | | | | | | | | 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
* Parse the @SECLEVEL=n annotation in cipher stringstb2022-06-291-5/+6
| | | | | | | To this end, hand the SSL_CERT through about 5 levels of indirection to set an integer on it. ok beck jsing
* Add support for sending QUIC transport parametersbeck2022-06-291-1/+29
| | | | | | | | | | 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@
* Also check the security level in SSL_get1_supported_cipherstb2022-06-291-2/+5
| | | | ok beck jsing
* Implement SSL_{CTX_}_{g,s}et_security_level(3)tb2022-06-281-1/+25
| | | | ok beck jsing sthen
* Simplify SSL_do_handshake().jsing2022-03-181-7/+5
| | | | ok inoguchi@ tb@
* Remove i <= 0 checks from SSL_get_error()jsing2022-02-061-15/+16
| | | | | | | | | | | In order for SSL_get_error() to work with SSL_read_ex() and SSL_write_ex() the error handling needs to be performed without checking i <= 0. This is effectively part of OpenSSL 8051ab2b6f8 and should bring the behaviour of SSL_get_error() largely inline with OpenSSL 1.1. Issue reported by Johannes Nixdorf. ok inoguchi@ tb@
* Bye bye S3I.jsing2022-02-051-23/+23
| | | | | | | | 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@
* Use BIO_next/BIO_set_next in ssl_lib.ctb2022-01-141-3/+3
| | | | Trivial conversion to cope with opaque BIO.
* Simplify SSL_get_peer_certificate()jsing2022-01-111-10/+8
| | | | ok inoguchi@ tb@
* Rename 'peer' to 'peer_cert' in SSL_SESSION.jsing2022-01-111-2/+2
| | | | | | | The 'peer' member of SSL_SESSION is the leaf/end-entity certificate provided by our peer. Rename it since 'peer' on its own is unhelpful. ok inoguchi@ tb@
* Swap arguments to ssl_check_srvr_ecc_cert_and_alg()jsing2022-01-091-4/+4
| | | | | If a libssl function takes an SSL *, it should normally be the first argument.
* Merge SESS_CERT into SSL_SESSION.jsing2022-01-081-11/+5
| | | | | | | There is no reason for SESS_CERT to exist - remove it and merge its members into SSL_SESSION for the time being. More clean up to follow. ok inoguchi@ tb@
* Rename CERT to SSL_CERT and CERT_PKEY to SSL_CERT_PKEY.jsing2022-01-081-13/+13
| | | | | | | Nearly all structs in libssl start with an SSL_ suffix, rename CERT and CERT_PKEY for consistency. ok inoguchi@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-17 08:37:05 +0000