summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-30 04:28:19 +0000