Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38
-0800:> On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote:
> > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at
23:03 +0000:
> > > versions included in FreeBSD 12.x. This vulnerability is also
known to
> > > affect OpenSSL versions included in FreeBSD 11.4. However, the
OpenSSL
> > > project is only giving patches for that version to premium
support contract
> > > holders. The FreeBSD project does not have access to these
patches and
> > > recommends FreeBSD 11.4 users to either upgrade to FreeBSD 12.x
or leverage
> > > up to date versions of OpenSSL in the ports/pkg system. The
FreeBSD Project
> > > may update this advisory to include FreeBSD 11.4 should patches
become
> > > publicly available.
> >
> > FreeBSD needs to reevaluate the continued reliance on OpenSSL for our
> > crypto/TLS library. 1.0.2 which is in 11-stable has not had support
> > for almost a year, and 11 is going to have almost another year of
> > support during which time if there's another vuln, we'll again
be
> > leaving the users in a bad place.
>
> To be blunt: didn't we try reevaluating already, and come up empty?
Software is not a stand still, just because in the past we didn't find
anything, doesn't mean we won't find something this time.
> OpenSSL's 5-year support lifetime is quite generous, in my experience,
and
> we are suffering more of a clash of release dates than a fundamental
> support-lifetime mismatch.
>
> > I have not heard if OpenSSL has bother to address the breakage of
> > /dev/crypto that also recently came up, but it does appear that they
> > are no longer a good fit for FreeBSD.
>
> I'm not sure why you leap from issues with the devcrypto engine to a
> broader "no longer a good fit" conclusion. The devcrypto engine
is hardly
> a core piece of functionality, and jhb has
No, but it demonstrates the amount of work that the OpenSSL devs are
putting in to supporting FreeBSD. It's one thing to say, we're not
going to support /dev/crypto anymore and stop compiling it on FreeBSD,
it's another to take known working software and intentionally break it
w/o evaluating it's impact upon their "supported" platforms.
OpenSSL
chose to do the later...
> https://github.com/openssl/openssl/pull/13468 up waiting for review.
Why is FreeBSD reacting to these problems? Why didn't OpenSSL devs drop
a mail to FreeBSD -security saying, btw, we've changed X, and we know
it'll break your code, so heads up if anyone wants to fix it, please
submit patches, otherwise in a few weeks we'll disable building support
for it on FreeBSD. If they're not regularly running and testing code
on FreeBSD (or is actively working w/ a person to do such a thing), can
we really say that OpenSSL supports FreeBSD?
> I regularly commit to openssl from my FreeBSD system, including the
> build+test cycle; the core functionality remains well-supported. To be
> honest, I didn't bother caring about devcrypto because I didn't
expect it
> to be widely used, given that you have to have special hardware to overcome
> the hit of syscall context switching.
Sounds like you need to get a QAT system or other accelerator board
for testing then. There are a new class of crypto accelerators that
make this a viable option again, so I dispute your definition of
devcrypto not being useful.
> > Even as it stands, FreeBSD has committed to supporting 12 for close
> > to a year longer than OpenSSL has for 1.1.1 meaning we will be in the
> > same situation we are w/ 11 in a few years.
> >
> > Assuming 13 releases w/ OpenSSL, we'll be even in a worse
situation
> > than we are now. OpenSSL 3.0.0 has no support commitment announced
> > yet, and sticking with 1.1.1 for 13 will put us even in a worse
> > situation than we are today.
>
> OpenSSL 3.0.0 is not going to be LTS; I expect it to go EoL before 1.1.1
> does. (And I expect 1.1.1 to be supported past 2023-09-11, though of
> course I do not speak for the project.) I also think that 3.0.0 is not the
Until the OpenSSL project changes it, we have to operate under the
assumption that the date will not change, and make plans to deal w/
OpenSSL 1.1.1 on 13-current for years after OpenSSL stops supporting
it.
> recommended relase for anyone who doesn't need the FIPS compatibility;
> there's been a substantial rearchitecture and will likely be growing
pains
> as tend to accompany dot-zero releases.
>
> > What are peoples thoughts on how to address the support mismatch
between
> > FreeBSD and OpenSSL? And how to address it?
> >
> > IMO, FreeBSD does need to do something, and staying w/ OpenSSL does
> > not look like a viable option.
>
> IMO OpenSSL 1.1.1 is generally in pretty good shape and much easier to
> maintain than 1.0.2 was. I have yet to see an alternative suitable for
> inclusion in the base system that would be more viable.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."