> On 7 May 2025, at 06:34, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.mu...@gmail.com> writes: >> On Wed, May 7, 2025 at 1:18 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Anyone know anything about where to submit LibreSSL bugs? > >> I think it's done with sendbug on an OpenBSD box, or perhaps you can >> just write a normal email to the b...@openbsd.org or >> libre...@openbsd.org list, based on: >> https://www.openbsd.org/mail.html
Bugs are frequently reported, and dealt with, on the libressl mailing list. > Thanks, I'll look into reporting it tomorrow. In the meantime, > I couldn't help noticing that the backtraces went through > lib/libssl/tls13_legacy.c, which doesn't give a warm feeling > about how supported they think our usage is (and perhaps also > explains why they didn't detect this bug themselves). This is > evidently because we set up the SSL context with SSLv23_method(), > per this comment in be_tls_init(): > > * We use SSLv23_method() because it can negotiate use of the highest > * mutually supported protocol version, while alternatives like > * TLSv1_2_method() permit only one specific version. Note that we don't > * actually allow SSL v2 or v3, only TLS protocols (see below). > > This choice seems to be more than 20 years old, though the above > comment defending it dates only to 2014. I wonder if it's time to > revisit that idea. The use of SSLv23_method() comes from us supporting 1.0.2, the replacement TLS_method() was introduced in 1.1.0 and SSLv23_method() was turned into an alias of TLS_method() in OpenSSL commit 32ec41539b5. Since we no longer support 1.0.2 we can apply something like the (lightly tested) attached which should be a no-op as we already use TLS_method() but via an alias. There's likely more OpenSSL code we can modernize, hopefully we can make some progress on that during the v19 cycle. -- Daniel Gustafsson
tls_method.diff
Description: Binary data
