summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Ensure that a client who sent a PSK extension has also sent a PSKtb2022-06-031-4/+9
| | | | | | key exchange mode extension, as required by RFC 8446, 4.2.9. ok jsing
* Provide #defines for the two currently registered PskKeyExchangeModes.tb2022-06-031-1/+12
| | | | ok jsing
* Drop unused KeyUpdate from debug printftb2022-04-191-3/+1
| | | | | | | | | The handshake state machine does not handle key updates since that's a post-handshake handshake message. This is code under #ifdef TLS13_DEBUG and if it is ever to be reused in tls13_handshake_msg.c, that will have to be revisited. ok inoguchi jsing
* man pages: add missing commas between subordinate and main clausesnaddy2022-03-314-18/+18
| | | | | | | jmc@ dislikes a comma before "then" in a conditional, so leave those untouched. ok jmc@
* man pages: add missing word, The foo() ... -> The foo() function ...naddy2022-03-291-5/+6
| | | | ok jmc@ schwarze@
* man pages: add missing commas in enumerationsnaddy2022-03-291-3/+3
|
* Clean up {dtls1,ssl3}_read_bytes()jsing2022-03-262-200/+166
| | | | | | | | | | Now that {dtls1,ssl3}_read_bytes() have been refactored, do a clean up pass - this cleans up various parts of the code and reduces differences between these two functions. ok = 1; *(&(ok)) tb@ ok inoguchi@
* Remove the minimum record length checks from dtls1_read_bytes()jsing2022-03-261-32/+1
| | | | | | | | The code that handles each record type already has appropriate length checks. Furthermore, the handling of application data here is likely incorrect and bypasses the normal state checks at the end of this function. ok inoguchi@ tb@
* Remove three useless tests filestb2022-03-193-185/+0
| | | | | | | | | The asn1test depends on asn1_mac.h which had a date with the bitbucket a few years back (and the test "isn't meant to run particularly, it's just to test type checking"). methtest.c tests an API that was never present in OpenSSL's git history. r160test.c is nothing but a licence. "nuke away" jsing
* Simplify SSL_do_handshake().jsing2022-03-181-7/+5
| | | | ok inoguchi@ tb@
* Rewrite legacy DTLS unexpected handshake message handling.jsing2022-03-181-83/+139
| | | | | | | | | Rewrite the code that handles unexpected handshake messages in the legacy DTLS stack. Parse the DTLS message header up front, then process it based on the message type. Overall the code should be more strict and we should reject various invalid messages that would have previously been accepted. ok inoguchi@ tb@
* Rewrite legacy TLS unexpected handshake message handling.jsing2022-03-171-78/+114
| | | | | | | | | | | | Rewrite the code that handles unexpected handshake messages in the legacy TLS stack. Parse the TLS message header up front, then process it based on the message type. Overall the code should be more strict and we should reject various invalid messages that would have previously been accepted. I also reviewed steve's experimental code and fixed the bug that it contained. ok inoguchi@ tb@
* Clean up and simplify ssl3_renegotiate{,_check}()jsing2022-03-171-22/+15
| | | | ok inoguchi@ tb@
* Remove const from tls1_transcript_hash_value()jsing2022-03-172-5/+5
| | | | | | | This function populates the passed *out argument, hence it should not be marked const. ok tb@
* Factor out unexpected handshake message handling code in the legacy stack.jsing2022-03-142-229/+256
| | | | | | | | | | | | | | The TLS record layer has to be able to handle unexpected handshake messages that result when it has been asked to read application data. The way that this is currently done in the legacy stack is a layering violation - the record layer knows about DTLS/TLS handshake messages, parsing them and then deciding what action to take. This is further complicated by the need to handle handshake message fragments. For now, factor this code out with minimal changes - since it is a layering violation we have to retain separate code for DTLS and TLS. ok beck@ inoguchi@ tb@
* Factor out change cipher spec handing code in the legacy stack.jsing2022-03-123-65/+73
| | | | | | | | Factor out the code that handles the processing of a change cipher spec message that has been read in the legacy stack, deduplicating code in the DTLS stack. ok inoguchi@ tb@
* Fix typo in commentbket2022-03-051-2/+2
| | | | OK tb@
* Factor out alert handing code in the legacy stack.libressl-v3.5.0jsing2022-02-213-85/+77
| | | | | | | | | | | | | | | Pull out the code that processes incoming alerts - a chunk of the complexity is due to the fact that in TLSv1.2 and earlier, alerts can be fragmented across multiple records or multiple alerts can be delivered in a single record. In DTLS there is no way that we can reassemble fragmented alerts (although the RFC is silent on this), however we could have multiple alerts in the same record. This change means that we will handle this situation more appropriately and if we encounter a fragmented alert we will now treat this as a decode error (instead of silently ignoring it). ok beck@ tb@
* Avoid gendered language in man pages when not referring to a specificjsg2022-02-181-4/+4
| | | | | | | | person. Rewrite or use singular they. ok thfr@ sthen@ daniel@ ian@ job@ kmos@ jcs@ ratchov@ phessler@ and others I'm likely missing on an earlier version. feedback tj@, feedback and ok jmc@
* Remove i <= 0 checks from SSL_get_error()jsing2022-02-061-15/+16
| | | | | | | | | | | In order for SSL_get_error() to work with SSL_read_ex() and SSL_write_ex() the error handling needs to be performed without checking i <= 0. This is effectively part of OpenSSL 8051ab2b6f8 and should bring the behaviour of SSL_get_error() largely inline with OpenSSL 1.1. Issue reported by Johannes Nixdorf. ok inoguchi@ tb@
* Handle zero byte reads/writes that trigger handshakes in the TLSv1.3 stack.jsing2022-02-061-1/+5
| | | | | | | | | | | | | | | With the legaacy stack, it is possible to do a zero byte SSL_read() or SSL_write() that triggers the handshake, but then returns zero without SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE being flagged. This currently works in the TLSv1.3 stack by returning TLS_IO_WANT_POLLIN or TLS_IO_WANT_POLLOUT, which is then hidden by SSL_get_error(). However, due to upcoming changes to SSL_get_error() this will no longer be the case. In order to maintain the existing legacy behaviour, explicitly handle zero byte reads and writes in the TLSv1.3 stack, following completion of a handshake. ok inoguchi@ tb@
* remove please from manual pagesjsg2022-02-061-3/+3
| | | | ok jmc@ sthen@ millert@
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-23 04:44:43 +0000