summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bump minor after symbol additiontb2024-08-121-1/+1
|
* Add SSL_CTX_set1_cert_store() and SSL_CIPHER_get_handshake_digest() totb2024-08-121-0/+2
| | | | Symbols.list
* Expose SSL_CTX_set1_cert_store() and SSL_CIPHER_get_handshake_digest()tb2024-08-121-5/+1
|
* Add include path for crypto_arch.h.jsing2024-08-111-1/+2
|
* Document SSL_CTX_set_cert_storetb2024-08-031-2/+18
| | | | From Kenjiro Nakayama
* Prepare to provide SSL_CTX_set1_cert_store()tb2024-08-033-3/+17
| | | | | | | | | | | | | | | | 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 get_cipher from SSL_METHOD.jsing2024-07-235-73/+32
| | | | | | | | | | | | | | | 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-2212-392/+179
| | | | | | | | | | | | | | | | 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-2013-73/+70
| | | | | | | | | | | | | | | | 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@
* Annotate issues with tls_session_secret_cb() related code.jsing2024-07-192-2/+15
|
* Move client ciphers from SSL_SESSION to SSL_HANDSHAKE.jsing2024-07-196-28/+26
| | | | | | | | 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@
* Clean up SSL_HANDSHAKE_MAC_DEFAULT.jsing2024-07-163-63/+39
| | | | | | | | | | 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@
* Fix .Ox for SSL_CIPHER_get_handshake_digest()tb2024-07-161-3/+3
|
* Mop up TLS1_PRF* defines.jsing2024-07-152-76/+67
| | | | | | | | These have not been used for a long time, however SSL_CIPHER was not opaque at the time, hence they had to stick around. Now that SSL_CIPHER is opaque we can simply mop them up. ok tb@
* ocurred -> occurredjsg2024-07-151-3/+3
|
* Forgot to annotate the TMP UGLY CAST[S] as requested by jsingtb2024-07-141-1/+2
| | | | h/t to levitte
* Document SSL_CIPHER_get_handshake_digest(3)tb2024-07-141-2/+22
|
* Prepare to provide SSL_CIPHER_get_handshake_digest()tb2024-07-143-3/+23
| | | | | | | Needed by newer freeradius. This is a straightforward implementation that essentially duplicates tls13_cipher_hash(). ok jsing
* ssl2.h and ssl23.h join the party in the attictb2024-07-135-257/+11
| | | | | | | Now that the SSL2 client hello support is gone, nothing uses this anymore, except that a few ports still need SSL2_VERSION. ok beck
* Make error constants const in libssltb2024-07-131-5/+5
| | | | | | | | This could be made cleaner if we expose ERR_load_const_strings(), but for now this hackier version with casts achieves the same and removes the last unprotected modifiable globals in this library. ok jsing
* Despite being an ELF citizen, hppa is its own special snowflake and requiresmiod2024-07-121-1/+5
| | | | | | different asm stanzas to produce strong aliases. This unbreaks libssl on hppa after the recent switch to LIBRESSL_NAMESPACE.
* Adjust documentation for SSL_select_next_proto()tb2024-07-111-30/+48
| | | | | | | | Use better argument names, add a link to the relevant standards and add CAVEATS and BUGS sections pointing out a few pitfalls. discussed with davidben ok beck
* 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
* Don't push the error stack in ssl_sigalg_select()beck2024-07-091-2/+1
| | | | | | | Doing so breaks certificate selection if a TLS 1.3 client does not support EC certs, and needs to fall back to RSA. ok tb@
* 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@
* Actually enable namespaced builds in both libcrypto and libsslbeck2024-07-091-3/+3
| | | | (instead of commiting only one part)
* fix typotb2024-06-291-2/+2
|
* The ALPN callback should really ignore the out parameter if there'stb2024-06-281-3/+13
| | | | | | | no overlap. Document that explicitly. Also make it more explicit that that the caller must work with a copy of out. ok jsing
* 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
* Remove handling of SSLv2 client hello messages.jsing2024-06-281-205/+1
| | | | | | | | | This code was only previously enabled if the minimum enabled version was TLSv1.0 and a non-version locked method is in use. Since TLSv1.0 and TLSv1.1 were disabled nearly a year ago, this code is no longer ever being used. 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
* Implement RSA key exchange in constant time.jsing2024-06-253-63/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | RSA key exchange is known to have multiple security weaknesses, including being potentially susceptible to padding oracle and timing attacks. The RSA key exchange code that we inherited from OpenSSL was riddled with timing leaks, many of which we fixed (or minimised) early on. However, a number of issues still remained, particularly those related to libcrypto's RSA decryption and padding checks. Rework the RSA key exchange code such that we decrypt with RSA_NO_PADDING and then check the padding ourselves in constant time. In this case, the pre-master secret is of a known length, hence the padding is also a known length based on the size of the RSA key. This makes it easy to implement a check that is much safer than having RSA_private_decrypt() depad for us. Regardless, we still strongly recommend disabling RSA key exchange and using other key exchange methods that provide perfect forward secrecy and do not depend on client generated keys. Thanks to Marcel Maehren, Nurullah Erinola, Robert Merget, Juraj Somorovsky, Joerg Schwenk and Hubert Kario for raising these issues with us at various points in time. ok tb@
* 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_err: KNF tweaktb2024-06-241-2/+2
|
* ssl_err: fix whitespacetb2024-06-241-13/+13
|
* Provide CBB_add_u32_length_prefixed().jsing2024-06-222-2/+15
| | | | | | This is needed for an upcoming change in libcrypto. ok tb@
* 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
* remove unused typedefs with structs that were removedjsg2024-05-271-6/+1
| | | | | | | ENGINE, SSL and SSL_CTX remain even though the structs in the typedefs don't exist as they are used as incomplete types. feedback, ports bulk build and ok tb@
* sync inclusion of <stdlib.h> from libcryptotb2024-05-253-3/+6
|
* Make signature of SSL_COMP_add_compression_method(3) match realitytb2024-05-231-3/+3
|
* remove prototypes with no matching functionjsg2024-05-191-2/+1
| | | | feedback and ok tb@
* SSL_CTX_set_keylog_callback: copy-paste error _set_ -> _get_tb2024-05-161-3/+3
|
* 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
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-05-10 06:51:11 +0000