summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Switch TLSv1.3 cipher names from AEAD- to OpenSSL's TLS_tb2022-02-053-16/+22
| | | | | | | | | | | | | | | | | | OpenSSL chose to break the previous naming convention for ciphers and to adopt TLS_* "RFC" names instead. Unfortunately, these names are exposed in several APIs and some language bindings test for these non-standard names instead of cipher values, which is ... unfortunate (others would say "plain crazy"). We currently have to maintain patches in regress and ports (p5-Net-SSLeay, openssl-ruby-tests - which means that Ruby will pick this up at some point) to work around this difference and that's just not worth the effort. The old AEAD- names will become aliases and continue to work, but in openssl ciphers and netcat output the TLS_* names will now be displayed. "I would be very happy if this gets committed" bluhm ok beck inoguchi, begrudgingly ok jsing
* Bye bye S3I.jsing2022-02-0523-772/+755
| | | | | | | | 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@
* Bump libressl's version in pkgconfig to 2.0.0tb2022-02-041-2/+3
| | | | | | | | | | | | | LibreSSL's pc files effectively hardcode the version to 1.0.0 since LibreSSL exists. That probably never made much sense. This causes some pain for ports that "need 'openssl' ['>= +1.1.0'] found '1.0.0'" or similar while they would build perfectly fine with LibreSSL. This only affects OpenBSD. We do not put the actual LibreSSL version in there since it may cause trouble Discussed with sthen, millert, inoguchi, beck over the past year. Diff from/ok sthen
* Cleanup/simplify ssl_cert_type()jsing2022-02-036-34/+24
| | | | | | | | Remove the X509 argument as it is unused - this was passed so that ssl_cert_type() can get the public key from the X509 object if the EVP_PKEY argument is NULL, however this is never the case. ok tb@
* Error check for sk_push in libsslinoguchi2022-01-281-4/+7
| | | | | | CID 118976 118979 ok tb@
* Error check for sk_push in libsslinoguchi2022-01-281-2/+5
| | | | | | CID 24838 comment and ok tb@
* whitespacetb2022-01-261-4/+4
|
* Rewrite paragraph to refer to EVP_CIPHER_CTX_new() and HMAC_CTX_new()tb2022-01-251-6/+6
| | | | | | to match reality. spotted by/ok jmc
* Fix another return 0 bug in SSL_shutdown()tb2022-01-251-6/+8
| | | | | | | | | | | If tls13_recod_layer_send_pending() returns TLS13_IO_EOF, we will bubble this up to the caller via tls13_legacy_return_code(), which translates TLS13_IO_EOF to 0. This can happen if we have pending post handshake-handshake data and the peer closes the pipe. Presumably tls13_legacy_shutdown() should be rewritten yet again. ok jsing
* Avoid an infinite loop in SSL_shutdown()tb2022-01-251-2/+4
| | | | | | | | | | | | | | | | | | | | | If the peer closed the write side of the connection and we have not yet received the close_notify, SSL_shutdown() makes an extra read to try and read the peer's close_notify from the pipe. In that situation, we receive EOF. The legacy stack will return -1 while the TLSv1.3 stack will end up returning 0. Since the documentation is not super explicit about what should be done if SSL_shutdown() returns 0, some applications will enter an infinite loop. The code and documentation indicate that SSL_shutdown() should only be called once more if it returned 0. Newer versions of the OpenSSL documentation explicitly say that one should call SSL_read() if SSL_shutdown() returns 0 in order to retrieve the close_notify. Doing this would also have avoided this infinite loop. Reported by Carsten Arzig and bluhm with a test case extracted from the syslogd tests using IO::Socket::SSL, which has such an infinite loop. ok bluhm jsing
* Garbage collect unused ret in ssl3_get_new_session_ticket()tb2022-01-241-5/+4
| | | | | | | ret is used to bubble up an error from ssl3_get_message() and is unused otherwise. Zap dead store and silly ret = 1; return ret; ok inoguchi jsing
* In ssl3_get_server_key_exchange() switch a 'goto err' totb2022-01-241-2/+2
| | | | | | | 'goto fatal_err' so that the illegal_parameter alert is actually sent in case of X509_get0_pubkey() failure. ok inoguchi jsing
* Avoid use of uninitialized in tlsext_sni_server_parse()tb2022-01-241-1/+3
| | | | | | | | | If the hostname is too long, tlsext_sni_is_valid_hostname() will fail without having initialized *is_ip. As a result, the garbage value could lead to accepting (but otherwise ignoring) overlong and possibly invalid hostnames without erroring in tlsext_sni_server_parse(). ok inoguchi jsing
* Garbage collect the unused rv in tls1_check_ec_server_key() andtb2022-01-241-3/+2
| | | | | | convert to usual form of error checking. ok inoguchi jsing
* Remove the remaining three parens in return statements.tb2022-01-201-4/+4
|
* Use correct spelling of NULL.tb2022-01-201-2/+2
|
* spellingjsg2022-01-152-6/+6
| | | | ok tb@
* bump libcrypto, libssl, libtls majors after struct visibility changestb2022-01-141-1/+1
| | | | and Symbol addition and removal in libcrypto.
* Use the correct type for ssl_callback_ctrl()tb2022-01-141-3/+3
|
* Convert the new record layers to opaque EVP_AEAD_CTXtb2022-01-142-12/+6
| | | | ok jsing
* Convert ssl_kex.c to opaque DHtb2022-01-141-11/+11
| | | | | | Stop reaching into DH internals and use the new API functions instead. ok inoguchi jsing
* Use BIO_next/BIO_set_next in ssl_lib.ctb2022-01-141-3/+3
| | | | Trivial conversion to cope with opaque BIO.
* bio_ssl.c needs to peek into bio_local.htb2022-01-142-2/+4
|
* Garbage collect last use of EVP_ecdsa()tb2022-01-141-2/+1
| | | | ok inoguchi jsing
* Remove peer_pkeys from SSL_SESSION.jsing2022-01-116-96/+58
| | | | | | | | | | peer_pkeys comes from some world where peers can send multiple certificates - in fact, one of each known type. Since we do not live in such a world, get rid of peer_pkeys and simply use peer_cert instead (in both TLSv1.2 and TLSv1.3, both clients and servers can only send a single leaf (aka end-entity) certificate). ok inoguchi@ tb@
* Simplify SSL_get_peer_certificate()jsing2022-01-111-10/+8
| | | | ok inoguchi@ tb@
* Rename 'peer' to 'peer_cert' in SSL_SESSION.jsing2022-01-118-37/+37
| | | | | | | 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@
* Plumb decode errors through key share parsing code.jsing2022-01-117-48/+106
| | | | | | | | | | | | Distinguish between decode errors and other errors, so that we can send a SSL_AD_DECODE_ERROR alert when appropriate. Fixes a tlsfuzzer failure, due to it expecting a decode error alert and not receiving one. Prompted by anton@ ok tb@
* Use SSL_AD_INTERNAL_ERROR for non-decoding alerts when parsing keyshares.jsing2022-01-111-4/+10
| | | | ok tb@
* Simplify tlsext_keyshare_server_parse()jsing2022-01-111-9/+5
| | | | | | | SSL_AD_DECODE_ERROR is the default alert for a TLS extension parsing failure - remove the various gotos and simply return 0 instead. ok tb@
* ssl_check_srvr_ecc_cert_and_alg() only returns 0/1 - test accordingly.jsing2022-01-091-3/+3
|
* Swap arguments to ssl_check_srvr_ecc_cert_and_alg()jsing2022-01-093-9/+9
| | | | | If a libssl function takes an SSL *, it should normally be the first argument.
* Clean up ssl3_{send,get}_client_kex_gost()jsing2022-01-092-41/+46
| | | | | | | | Fix leaks, use sizeof() instead of hardcoded sizes, actually check return codes, explicit_bzero() the premaster secret on the server side and generally try to kick the GOST kex code into some sort of shape. ok inoguchi@ tb@
* Return 0/1 from ssl3_{send,get}_client_kex_gost()jsing2022-01-092-7/+7
| | | | | | | Like other KEX handling functions, there is no need to return anything other than failure/success here. ok inoguchi@ tb@
* Remove a comment from Captain Obvious.jsing2022-01-091-4/+2
|
* Fix GOST skip certificate verify handling.jsing2022-01-091-19/+11
| | | | | | | | | | | GOST skip certificate verify handling got broken in r1.132 of s3_srvr.c circa 2016. Prior to this, ssl3_get_client_key_exchange() returned an 'extra special' value to indicate that the state machine should skip certificate verify. Fix this by setting and checking the TLS1_FLAGS_SKIP_CERT_VERIFY flag, which is the same as is done in the client. ok inoguchi@ tb@
* Clean up pkey handling in ssl3_get_server_key_exchange()jsing2022-01-091-42/+22
| | | | | | | | | | With TLSv1.2 and earlier, the authentication algorithm used to sign the ServerKeyExchange message is dependent on the cipher suite in use and has nothing to do with the key exchange algorithm. As such, check the authentication algorithm based on the cipher suite in ssl3_get_server_key_exchange() and handle things accordingly. ok inoguchi@ tb@
* Merge SESS_CERT into SSL_SESSION.jsing2022-01-088-171/+76
| | | | | | | 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@
* Remove commented out CERT_* defines.jsing2022-01-081-7/+1
|
* Rename CERT to SSL_CERT and CERT_PKEY to SSL_CERT_PKEY.jsing2022-01-0810-101/+101
| | | | | | | Nearly all structs in libssl start with an SSL_ suffix, rename CERT and CERT_PKEY for consistency. ok inoguchi@ tb@
* Rename dh_tmp to dhe_params.jsing2022-01-075-33/+39
| | | | | | | | Support for non-ephemeral DH was removed a long time ago - as such, the dh_tmp and dh_tmp_cb are used for DHE parameters. Rename them to reflect reality. ok inoguchi@ tb@
* Stop attempting to duplicate the public and private key of dh_tmp.jsing2022-01-071-17/+1
| | | | | | | | Support for non-ephemeral DH was removed a very long time ago - the only way that dh_tmp is set is via DHparams_dup(), hence the public and private keys are always going to be NULL. ok inoguchi@ tb@
* Convert legacy server to tls_key_share.jsing2022-01-076-233/+115
| | | | | | | | | | | This requires a few more additions to the DHE key share code - we need to be able to either set the DHE parameters or specify the number of key bits for use with auto DHE parameters. Additionally, we need to be able to serialise the DHE parameters to send to the client. This removes the infamous 'tmp' struct from ssl3_state_internal_st. ok inoguchi@ tb@
* Convert legacy TLS client to tls_key_share.jsing2022-01-067-256/+181
| | | | | | | | | This requires adding DHE support to tls_key_share. In doing so, tls_key_share_peer_public() has to lose the group argument and gains an invalid_key argument. The one place that actually needs the group check is tlsext_keyshare_client_parse(), so add code to do this. ok inoguchi@ tb@
* Allocate and free the EVP_AEAD_CTX struct in tls13_record_protection.jsing2022-01-061-7/+13
| | | | | | | This brings the code more in line with the tls12_record_layer and reduces the effort needed to make EVP_AEAD_CTX opaque. Prompted by and ok tb@
* Provide CBB_add_u64()jsing2022-01-062-2/+21
| | | | Prompted by and ok tb@
* Rename tls13_key_share to tls_key_share.jsing2022-01-059-91/+97
| | | | | | | | | In preparation to use the key share code in both the TLSv1.3 and legacy stacks, rename tls13_key_share to tls_key_share, moving it into the shared handshake struct. Further changes will then allow the legacy stack to make use of the same code for ephemeral key exchange. ok inoguchi@ tb@
* Return 0 on failure from send/get kex functions in the legacy stack.jsing2022-01-042-43/+43
| | | | | | | | | | | | | In the legacy stack, a message handling function returns -1 for failure, 0 for need more data and 1 for success (although in extra special cases 2 may also be used). However, the various send/get kex functions only need to indicate success or failure - switch these to return 0 on failure (rather than -1) and use normal result testing. This leaves GOST unchanged for now, as that code is special and needs extra work. ok inoguchi@ tb@
* Use normal result testing for tls1_check_curve().jsing2022-01-041-2/+2
|
* Refactor ssl3_get_server_kex_ecdhe() to separate parsing and validation.jsing2022-01-041-20/+18
| | | | | | | | | If we receive something other than a "named curve", send a handshake failure alert as we're unable to complete the handshake with the given parameters. If the server responded with a curve that we did not advertise send an illegal parameter alert. ok inoguchi@ tb@