summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_ciph.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Update for OPENSSL_cpu_caps() now being machine independent.jsing2024-08-311-6/+2
| | | | ok tb@
* Remove SSL_add_compression_methodtb2024-08-311-8/+1
|
* Remove get_cipher from SSL_METHOD.jsing2024-07-231-25/+22
| | | | | | | | | | | | | | | Inline the get_cipher implementation (including the special handling for DTLS) in ssl_cipher_collect_ciphers() (the only consumer), remove the get_cipher member of SSL_METHOD and mop up dtls1_get_cipher(). ssl3_get_cipher() has always had a strange property of being a reverse index, which is relied on by the cipher list ordering code, since it currently assumes that high cipher suite values are preferable. Rather than complicating ssl3_get_cipher() (and regress), change the iteration order in ssl_cipher_collect_ciphers() to match what it requires. Lastly, rename ssl3_get_cipher() to be more descriptive. ok tb@
* Use cipher suite values instead of IDs.jsing2024-07-221-30/+26
| | | | | | | | | | | | | | | | OpenSSL has had the concept of cipher IDs, which were a way of working around overlapping cipher suite values between SSLv2 and SSLv3. Given that we no longer have to deal with this issue, replace the use of IDs with cipher suite values. In particular, this means that we can stop mapping back and forth between the two, simplifying things considerably. While here, remove the 'valid' member of the SSL_CIPHER. The ssl3_ciphers[] table is no longer mutable, meaning that ciphers cannot be disabled at runtime (and we have `#if 0' if we want to do it at compile time). Clean up the comments and add/update RFC references for cipher suites. ok tb@
* Remove cipher from SSL_SESSION.jsing2024-07-201-13/+19
| | | | | | | | | | | | | | | | 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@
* Clean up SSL_HANDSHAKE_MAC_DEFAULT.jsing2024-07-161-15/+2
| | | | | | | | | | The handshake MAC needs to be upgraded when TLSv1.0 and TLSv1.1 ciphersuites are used with TLSv1.2. Since we no longer support TLSv1.0 and TLSv1.1, we can simply upgrade the handshake MAC in the ciphersuite table and remove the various defines/macros/code that existed to handle the upgrade. ok tb@
* Prepare to provide SSL_CIPHER_get_handshake_digest()tb2024-07-141-1/+17
| | | | | | | Needed by newer freeradius. This is a straightforward implementation that essentially duplicates tls13_cipher_hash(). ok jsing
* 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
* Remove SSL_CIPHER_get_by_{id,value}()tb2024-03-021-15/+1
| | | | | | | | | 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
* Remove GOST and STREEBOG support from libssl.beck2024-02-031-101/+6
| | | | | | | | | | | | | | | | | | 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@
* 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
* Unifdef OPENSSL_NO_ENGINE in libssltb2023-11-191-5/+1
| | | | | | As usual, a few manual fixes to avoid duplicate lines. ok jsing
* Hide all public symbols in libsslbeck2023-07-081-7/+32
| | | | | | With the guentherizer 9000 ok tb@
* 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
* ssl_cipher_process_rulestr: return early if a cipher command is invalidmillert2022-09-081-5/+2
| | | | | This is a safer fix for the bug where we might read outside rule_str buffer and is how BoringSSL fixed it. OK tb@
* ssl_cipher_process_rulestr: don't read outside rule_str buffermillert2022-09-071-2/+3
| | | | | | If rule_str ended in a "-", "l" was incremented one byte past the end of the buffer. This resulted in an out-of-bounds read when "l" is dereferenced at the end of the loop. OK tb@
* Make ssl_create_cipher_list() have a single exittb2022-09-041-23/+23
| | | | | | | | | | This simplifies memory management and makes it easier to see the leak that were introduced in the previous commit. Sprinkle a few malloc errors for consistency. CID 278396 with/ok jsing
* Check sk_SSL_CIPHER_push() return valuetb2022-09-011-4/+11
| | | | | | CID 24797 ok jsing
* Remove a commented-out sk_push that has been hanging around for > 20 yearstb2022-08-301-4/+1
|
* Remove a confusing commenttb2022-06-291-7/+2
| | | | discussed with jsing
* Parse the @SECLEVEL=n annotation in cipher stringstb2022-06-291-8/+20
| | | | | | | To this end, hand the SSL_CERT through about 5 levels of indirection to set an integer on it. ok beck jsing
* Fix typo in commentbket2022-03-051-2/+2
| | | | OK tb@
* Bye bye S3I.jsing2022-02-051-3/+3
| | | | | | | | 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@
* Transform a mangled comment into something intelligible.tb2021-11-231-2/+5
| | | | from beck
* Do a first pass clean up of SSL_METHOD.jsing2021-07-031-3/+11
| | | | | | | | | The num_ciphers, get_cipher_by_char and put_cipher_by_char function pointers use the same function for all methods - call ssl3_num_ciphers() directly, absorb ssl3_get_cipher_by_char() into SSL_CIPHER_find() and remove the unused ssl3_put_cipher_by_char() code. ok inoguchi@ tb@
* Explicitly include <openssl/opensslconf.h> in files using OPENSSL_NO_*jsing2021-05-161-1/+2
| | | | | | Where a file references to OPENSSL_NO_* conditions, ensure that we explicitly include <openssl/opensslconf.h> before any references, rather than relying on another header to pull this in.
* Provide SSL_CIPHER_find(3)tb2021-05-101-1/+7
| | | | ok jsing
* Rename new_cipher to cipher.jsing2021-03-241-3/+3
| | | | | | | | This is in the SSL_HANDSHAKE struct and is what we're currently negotiating, so there is really nothing more "new" about the cipher than there is the key block or other parts of the handshake data. ok inoguchi@ tb@
* Absorb ssl3_get_algorithm2() into ssl_get_handshake_evp_md().jsing2021-02-071-2/+14
| | | | | | | | The mess that is ssl_get_algorithm2() only exists to upgrade the handshake MAC of a pre-TLSv1.2 cipher suite to SHA256 when used with TLSv1.2. We can readily do this in ssl_get_handshake_evp_md(), which is far more readable. ok tb@
* Implement SSL_{CTX_,}set_ciphersuites().jsing2020-09-131-2/+15
| | | | | | | | | | OpenSSL added a separate API for configuring TLSv1.3 ciphersuites. Provide this API, while retaining the current behaviour of being able to configure TLSv1.3 via the existing interface. Note that this is not currently exposed in the headers/exported symbols. ok beck@ inoguchi@ tb@
* Remove cipher_list_by_id.jsing2020-09-111-14/+3
| | | | | | | | | | | | | | | | | When parsing a cipher string, a cipher list is created, before being duplicated and sorted - the second copy being stored as cipher_list_by_id. This is done only so that a client can ensure that the cipher selected by a server is in the cipher list. This is pretty pointless given that most clients are short-lived and that we already had to iterate over the cipher list in order to build the client hello. Additionally, any update to the cipher list requires that cipher_list_by_id also be updated and kept in sync. Remove all of this and replace it with a simple linear scan - the overhead of duplicating and sorting the cipher list likely exceeds that of a simple linear scan over the cipher list (64 maximum, more typically ~9 or so). ok beck@ tb@
* 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
|
* 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@
* 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@
* Include TLSv1.3 cipher suites unless cipher string references TLSv1.3.jsing2020-04-091-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL has always taken the approach of enabling almost everything by default. As a result, if you wanted to run a secure TLS client/server you had to specify your own "secure" cipher string, rather than being able to trust the defaults as being sensible and secure. The problem is that with the introduction of TLSv1.3, most of these "secure" cipher strings result in the new TLSv1.3 cipher suites being excluded. The "work around" for this issue in OpenSSL was to add a new TLSv1.3 API (SSL_CTX_set_ciphersuites(), SSL_set_ciphersuites()) and have separate knobs for the pre-TLSv1.3 and TLSv1.3 cipher suites. This of course means that every application now needs to call two APIs, but it does mean that applications that only call SSL_CTX_set_cipher_list()/SSL_set_cipher_list() cannot remove TLSv1.3 cipher suites and prevent TLSv1.3 from working. We've taken a different approach and have allowed TLSv1.3 cipher suites to be manipulated via the existing SSL_set_cipher_list() API. However, in order to avoid problems with hardcoded cipher strings, change this behaviour so that we always include TLSv1.3 cipher suites unless the cipher string has a specific reference to the TLSv1.3 protocol or a TLSv1.3 cipher suite. This means that: $ openssl ciphers -v TLSv1.2:!TLSv1.3 still gives TLSv1.2 only cipher suites and: $ openssl ciphers -v AEAD-CHACHA20-POLY1305-SHA256 only lists a single TLSv1.3 cipher, however: $ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 now includes both TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 and all TLSv1.3 cipher suites (which also matches OpenSSL's openssl(1) behaviour). Issue encountered by kn@ with mumble. ok tb@
* Tidy line wrapping and remove an extra blank line.jsing2020-04-091-4/+3
|
* ssl_aes_is_accelerated() returns a boolean - treat it as such, rather thanjsing2020-04-091-2/+2
| | | | explicitly comparing against a value.
* Fix SSL_CIPHER_descriptioninoguchi2020-01-261-2/+2
| | | | ok jsing@
* Add strings for SSL_aTLS1_3 and SSL_kTLS1_3 to SSL_CIPHER_description().jsing2020-01-241-1/+7
| | | | | | | Mkaes `openssl ciphers -v` print au and kx values for TLSv1.3 cipher suites. ok beck@ tb@
* Clean up the cipher/digest table mess.jsing2019-04-041-174/+42
| | | | | | | | | | The original implementation allows for libcrypto to be compiled without a given algorithm and libssl then detects that ciphers or digests are unavailable so that it can disable the associated cipher suites. This is unnecessary since we do not compile out algorithms. ok beck@, tb@ (a while back)
* If ssl_cipher_apply_rule() is given a specific cipher suite, match on it.jsing2019-03-241-3/+4
| | | | | | | | | | Otherwise matching a specific cipher is performed by matching against its characteristics, which can result in multiple rather than a single match. Found by bluhm@'s regress tests. ok bluhm@ tb@
* Add TLSv1.3 cipher suites (with appropriate guards).jsing2018-11-071-3/+12
| | | | ok beck@ tb@
* Remove now unused code for EVP_CIPH_FLAG_AEAD_CIPHER and EVP_CIPH_GCM_MODE.jsing2018-09-081-6/+14
| | | | ok inoguchi@ tb@
* SSL_MAX_DIGEST is no longer needed.jsing2018-09-081-12/+9
|
* Drop SSL_CIPHER_ALGORITHM2_AEAD flag.jsing2018-09-061-5/+3
| | | | | | | All of our algorithm_mac == SSL_AEAD cipher suites use EVP_AEAD, so we can condition on that rather than having a separate redundant flag. ok tb@
* Stop using composite EVP_CIPHER AEADs.jsing2018-09-031-25/+7
| | | | | | | | | | | The composite AEADs are "stitched" mode ciphers, that are only supported on some architectures/CPUs and are designed to be faster than a separate EVP_CIPHER and EVP_MD implementation. The three AEADs are used for less than ideal cipher suites (if you have hardware support that these use there are better cipher suite options), plus continuing to support AEADs via EVP_CIPHER is creating additional code complexity. ok inoguchi@ tb@
* Stop handling AES-GCM via ssl_cipher_get_evp().jsing2018-09-031-20/+3
| | | | | | | All of the AES-GCM ciphersuites use the EVP_AEAD interface, so there is no need to support them via EVP_CIPHER. ok inoguchi@ tb@
* Clean up SSL_DES and SSL_IDEA remnants.jsing2018-09-031-41/+13
| | | | | | | All ciphersuites that used these encryption algorithms were removed some time ago. ok bcook@ inoguchi@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 03:52:22 +0000