A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.5.0 2022-02-21T18:22:20+00:00 2022-02-21T18:22:20+00:00 jsing 2022-02-21T18:22:20+00:00 urn:sha1:95e90dc06dccc0b309c252ec72524e567b7291fd 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@ 2022-02-18T23:17:15+00:00 jsg 2022-02-18T23:17:15+00:00 urn:sha1:b590ea2697783e317477d63480cdab6651a032f3 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@ 2022-02-06T16:11:58+00:00 jsing 2022-02-06T16:11:58+00:00 urn:sha1:cbae1c6b17b1dd98f4e23b27675d1f263d248353 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@ 2022-02-06T16:08:14+00:00 jsing 2022-02-06T16:08:14+00:00 urn:sha1:a57b110b583fdbdc7a174b8f593acae516c3caba 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@ 2022-02-06T00:29:02+00:00 jsg 2022-02-06T00:29:02+00:00 urn:sha1:330276f39a5e0d5b539d5e8e3e247384f82cbde2 ok jmc@ sthen@ millert@ 2022-02-05T18:18:18+00:00 tb 2022-02-05T18:18:18+00:00 urn:sha1:e5500000382c402276da7446a43a82d0153d2f1d 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 2022-02-05T14:54:10+00:00 jsing 2022-02-05T14:54:10+00:00 urn:sha1:a463011117e88ea3125fb580b8c6c60d68722651 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@ 2022-02-04T16:42:15+00:00 tb 2022-02-04T16:42:15+00:00 urn:sha1:54b37ce29213d429a1f20782418b17863e8b4b9b 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 2022-02-03T16:33:12+00:00 jsing 2022-02-03T16:33:12+00:00 urn:sha1:1797a334a41f2408c221e936472024878d34d7c6 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@ 2022-01-28T13:14:48+00:00 inoguchi 2022-01-28T13:14:48+00:00 urn:sha1:4e2f7b2d75c51fd52368a6ab05698e22b35a3ab2 CID 118976 118979 ok tb@