summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove fixed nonce length information from algorithm2tb2024-05-102-59/+15
| | | | | | | | | This information has been part of tls12_key_block_generate() for a while now. It remained in this table because at that point SSL_CIPHER was still public. Nothing can access algorithm2 anymore from the outside, so this is dead weight. ok jsing
* sync the SSL text; ok tbjmc2024-05-091-3/+3
|
* ssl_ciph.c: unwrap a linetb2024-05-091-3/+2
|
* Remove leftover logic of SSL2 supporttb2024-05-091-5/+3
| | | | | | | SSL2_CF_8_BYTE_ENC was set by things such as RC4_64_WITH_MD5, which fell victim to tedu's axe a decade ago. Zap that. ok jsing
* Plug a "leak" in ssl_security_group()tb2024-05-091-6/+13
| | | | | | | | The way the CBB API is used, CBB_add_u16() and CBB_finish() can't actually fail here, but if they could, cbb->base would leak. Rewrite this code with the proper idioms to make it look right. ok jsing
* Avoid OpenSSL SSL repetitionstb2024-05-081-7/+8
| | | | with the help of jmc
* 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
* crank libssl major after libcrypto major and symbol removaltb2024-04-151-1/+1
|
* Unexport SSL_version_strtb2024-04-152-4/+1
| | | | ok 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@
* Unify up_ref implementations in libssltb2024-03-272-8/+5
| | | | ok jsing
* Add an indicator that an extension has been processed.beck2024-03-263-3/+21
| | | | 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@
* crank libssl majortb2024-03-021-1/+1
| | | | same bump as libcrypto; symbol removal and addition
* Remove SSL_debugtb2024-03-024-13/+3
| | | | | | | The garbage truck is quite full by now. Collect the last symbol straggler for this bump. ok jsing
* Garbage collect TLS1_FLAGS_SKIP_CERT_VERIFYtb2024-03-021-2/+1
| | | | | | And here goes another weird-ass thing of dubious pedigree. ok jsing
* Make {SSL3,TLS}_CT_* internaltb2024-03-023-28/+8
| | | | | | | | And here goes a bunch of unused macros that just had to be in two headers so they could get out of sync. Three of these constants are used in a single function... ok jsing
* Remove SSL_CIPHER_get_by_{id,value}()tb2024-03-024-23/+3
| | | | | | | | | While this undocumented API would have been much nicer and saner than SSL_CIPHER_find(), nothing used this except for the exporter test. Let's get rid of it again. libssl uses ssl3_get_cipher_by_{id,value}() directly. ok jsing
* Export SSL_get_{peer_,}signature_type_nid()tb2024-03-025-8/+13
| | | | | | | | | Also move the prototypes to the correct header. Oversight reported by Frank Lichtenheld, thanks! Fixes https://github.com/libressl/openbsd/issues/147 ok jsing
* Of course libssl also has a few missing voidtb2024-02-042-4/+4
| | | | From Christian Andersen
* Rework the exit path of tls13_handshake_recv_action()tb2024-02-031-12/+14
| | | | | | | | | | | | | If an error occurs in action->recv() for a handshake that needs to downgrade to legacy TLS, the artistic exit path led to hiding the error under TLS13_IO_USE_LEGACY. Rework the exit path to be easier to follow, preserving behavior except that the error can no longer be masked. Detailed analysis and initial diff by Masaru Masuda. Fixes https://github.com/libressl/openbsd/issues/146 ok beck
* Remove last peeking at TLS1_FLAGS_SKIP_CERT_VERIFYtb2024-02-031-7/+1
| | | | | | | This was used for some GOST weirdness. The flag is unused in ports and there is no user in Debian's codesearch. ok beck
* Zap a trailing blank that snuck into ssl3_get_client_hello()tb2024-02-031-2/+2
|
* Remove GOST and STREEBOG support from libssl.beck2024-02-0316-675/+32
| | | | | | | | | | | | | | | | | | 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@
* Restore SSL_shutdown() two step sequence.jsing2024-01-301-1/+3
| | | | | | | | | | | Change SSL_shutdown() such that it will return 0 after sending a close-notify, before potentially returning 1 (indicating that a close-notify has been sent and received) on a subsequent call. Some software depends on this behaviour, even though there are cases where the first call could immediately return 1 (for example, when the peer has already sent a close-notify prior to SSL_shutdown() being called). ok tb@
* Rework tls13_legacy_shutdown() to match the legacy stack behaviour.jsing2024-01-271-18/+19
| | | | | | | | Respect the ssl->shutdown flags rather than what has actually happened, return -1 for all EOF errors and completely ignore the return value when attempting to read a close-notify from the wire. ok tb@
* Make tls13_legacy_return_code() static.jsing2024-01-272-4/+3
|
* Add message callbacks for alerts in the TLSv1.3 stack.jsing2024-01-273-10/+49
| | | | | | | | This will make it easier to regress test shutdown behaviour in the TLSv1.3 stack. Additionally, `openssl -msg` now shows alerts for TLSv1.3 connections. ok tb@
* Stop fiddling with hash table internals from lhash doall callers.jsing2024-01-241-6/+3
| | | | | | | | It is now safe to call delete from an lhash doall callback - stop fiddling wit hash table internals from lhash doall callers that previously has to workaround this themselves. ok tb@
* Switch from EVP_CIPHER_type() to EVP_CIPHER_nid()tb2024-01-181-2/+2
| | | | | | | | EVP_CIPHER_type() will never return NID_gost89_cnt since it has no associated ASN1_OBJECT. Switching to EVP_CIPHER_nid() has a slight chance of working. Do that before beck applies the flensing knife. ok beck
* Remove mention of a refcount bugtb2024-01-131-18/+1
| | | | | | Said bug was fixed in OpenSSL 1.0.0, released 14 years ago. It is of course unsurprising that you may accidentally increment the refcount if your idiom for decrementing it is CRYPTO_add(&bio-references, -1, CRYPTO_LOCK_BIO)).
* BIO_f_ssl.3: Remove explicit library initializationtb2024-01-131-8/+2
|
* Remove last external call to EVP_PKEY_meth_find()tb2024-01-041-5/+6
| | | | | | | | | In order to determine whether GOST is properly enabled, libssl has various weird dances. In this specific case, it calls EVP_PKEY_meth_find() to see whether the relevant cipher is around. Check the same thing with an #ifdef instead. ok jsing
* Fix two more unchecked EVP_PKEY_assign() callstb2023-12-301-17/+25
| | | | | | | | | In SSL{_CTX}_use_RSAPrivateKey() switch from EVP_PKEY_assign_RSA() to EVP_PKEY_set1_RSA() and hold on to the reference of the the pkey for the duration of ssl_set_pkey(). Use single exit and other minor style cleanups. ok joshua jsing
* Neuter the SSL_set_debug(3) APItb2023-12-294-21/+5
| | | | | | | | | | | 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-293-39/+19
| | | | | | | | | | | | | | | | | 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
* Use a long for id in ssl3_get_cipher_by_id()tb2023-11-292-4/+4
| | | | | | | | | While the cipher id is effectively a 32-bit value, someone decided that it should be represented by a long in various internal structs, whose mameber is passed as id. So use a long because of this and also to make an upcoming diff simpler. ok jsing
* Switch to legacy method late in tls13_use_legacy_stack()tb2023-11-281-3/+7
| | | | | | | | | | | | | | If memory allocation of s->init_buf fails in ssl3_setup_init_buffer() during downgrade to the legacy stack, the legacy state machine would resume with an incorrectly set up SSL, resulting in a NULL dereference. The fix is to switch to the legacy method only after the SSL is fully set up. There is a second part to this fix, which will be committed once we manage to agree on the color of the bikeshed. Detailed analysis and patch from Masaru Masuda, many thanks! https://github.com/libressl/openbsd/issues/146 ok jsing
* Move ssl_cipher_id_cmp() next to its only callertb2023-11-252-15/+14
| | | | | | 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.
* Unhook and remove the now even more useless ssl_algs.c than it was before.tb2023-11-222-68/+1
| | | | ok jsing
* Make SSL_library_init() a wrapper of OPENSSL_init_ssl()tb2023-11-222-61/+9
| | | | | | | | | | | This way it doesn't do nonsensical work for all those who cargo culted an init sequence. There's no point in having SSL_library_init() as a cheaper version of OPENSSL_init_ssl(): once you do crypto, you'll init crypto... Also move the now trivial implementation to ssl_init.c which has a good license. ok jsing
* Stop calling SSL_library_init() from OPENSSL_init_ssl_internal()tb2023-11-221-2/+1
| | | | | | | | It's pointless: all the ciphers and digests added by SSL_library_init() are already added by OPENSSL_init_crypto(), which was already called at that point. ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 19:38:21 +0000