freebsd security - Dec 2020 - FreeBSD Security Advisory FreeBSD-SA-20:33.openssl

On 12/12/20 4:57 PM, John-Mark Gurney wrote:
> John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800:
>> On 12/10/20 10:46 PM, John-Mark Gurney wrote:
>>> 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 think I can't disagree more.  In terms of /dev/crypto, see here:
>>
>> https://github.com/openssl/openssl/pull/13468
> 
> I went back to the original PR that rewrote /dev/crypto:
> https://github.com/openssl/openssl/pull/3744
> 
> The PR was submitted in June 2017, and they tested on FreeBSD 8.4-R,
> which had support end on June 2015.  Even back in 2017, it was easy
> enough w/ VMs and cloud compute to spin up a modern, supported
> FreeBSD box.
> 
> Yes, it's good that it's now getting fixed, 3 years after it was
broken.
> 
> If FreeBSD is going to continue to use OpenSSL, better testing needs to
> be done to figure out such breakage earliers, and how to not have them
> go undetected for so long.
At some point the onus is also on FreeBSD to keep things working as
well.  In practice, our kernel crypto interface is pretty crappy
(hopefully less crappy in 13, but there is still room for improvement).
Also, when I have tested it with actual offload hardware, it doesn't
really compete with native AES instructions on the CPU running in
userland.  KTLS does help because you can use sendfile, but
/dev/crypto is not a win in my testing.  I had to make additional
changes to teach the engine in 1.0.2 to use AES-GCM with the
extensions needed for TLS as well as wire the user buffers to avoid
copies, and with that I got a hardware co-processor to break even in
with AES-NI in userland in terms of both throughput and CPU usage
for HTTPS.  sendfile-enabled KTLS, OTOH, is able to achieve
significantly higher throughput.
>> Also, OpenSSL has been perfectly fine to work with in terms of
>> upstreaming KTLS.  kaduk@ is an OpenSSL committer and has been
>> helpful with helping me find reviewers for patches when needed
>> as well.
>>
>> In terms of OpenSSL vs other SSL libraries, I'll defer to this:
>>
>> https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html
> 
> I'll note that this article is more for a developer than the maintainer
> of an OS.  When FreeBSD has 5 year support cycles, things are slightly
> different, otherwise I agree that the article is good advice (from my
> brief reading/looking over).
While it's true it is tailored for a developer, I think it is still
relevant in its discussion of alternative SSL library implementations.
I agree with Gordon's assessment that there aren't really other viable
alternatives.
 
>>> 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.
>>>
>>> What are peoples thoughts on how to address the support mismatch
between
>>> FreeBSD and OpenSSL?  And how to address it?
>>
>> I do think the support mismatch questions are still real, and I'm
not
>> sure what the best answer is.  My guess is that the the delay of
>> 3.0.0 (which I had hoped would ship in 13.0) will mean that 1.1.1's
>> lifetime will get extended, but probably not enough to cover 13.x
>> for 5 years.  One option may be that we provide a compat openssl for
>> 13.x that is 1.1.1 for things built on the head of the branch but
>> actually import OpenSSL 3.0.0 into stable/13 at some point.  You could
>> do this with a shlib major version bump.  It won't solve all
problems
>> if some shared library linked against 1.1.1 returns some object
>> allocated by libssl that the application tries to use directly (and
>> the application is linked against 3.0.0), but I'm not sure how
common
>> that situation will be in practice.  OpenSSL isn't libc where you
have
>> issues with malloc/free crossing this sort of boundary.
> 
> In the case of mixed 1.1.1 and 3.0.0, that should just be disallowed.
> 
> Though importing 3.0.0 doesn't solve the issue if 1.1.1 has a security
> problem...  Because the security problem in 1.1.1 will still need to be
> addressed to deal w/ all the applications that are linked against it..
If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are
no longer having to maintain 1.1.1 in 13.  If people want to keep older
applications built on unsupported releases still working without
recompiling, etc. they will have to manage that themselves.  Currently
we don't support 12.0 on the 12.x branch for example.

-- 
John Baldwin

As a party with a vested interest in FIPS, you can guess were I stand on
replacing OpenSSL with some other crypto engine in FreeBSD.? ;)
We are currently building FreeBSD 11.4 against a copy of the latest OpenSSL
1.0.2 release by diverting the build to a separate part of our source tree in
secure/lib/Makefile.? This has been working quite well for us.? We'll see
what happens with our ongoing 12.2 upgrade.

Not really the point of this email though.  Regarding
/dev/crypto:
> Also, when I have tested it with actual offload hardware, it doesn't
> really compete with native AES instructions on the CPU running in
> userland.
Here you're really comparing two hardware accelerators, one with extra
kernel overhead, so it's not really fair.
Have you compared RSA or EC signing and verifying between libcrypto and
/dev/crypto?? This would give you a better idea of /dev/crypto performance
improvement.? (I'll say that /dev/crypto is not really of interest to me
professionally, because FIPS)
> KTLS does help because you can use sendfile, but
> /dev/crypto is not a win in my testing.? I had to make additional
> changes to teach the engine in 1.0.2 to use AES-GCM with the
> extensions needed for TLS as well as wire the user buffers to avoid
> copies, and with that I got a hardware co-processor to break even
> with AES-NI in userland in terms of both throughput and CPU usage
> for HTTPS.? sendfile-enabled KTLS, OTOH, is able to achieve
> significantly higher throughput.
I don't know anything about KTLS - is that using OpenSSL for it's
crypto?? If so, can it load a FIPS canister/provider?  If not, then FIPS may be
an issue for us (and other commercial users of FreeBSD), I hope it's
something we can disable...  Is there some documentation about this someone can
point me to?

- Steve Wall

On Mon, Dec 14, 2020 at 11:44:27AM -0800, John Baldwin
wrote:
> If we import 3.0.0 into, say, 13.2, then when 13.0/13.1 are EOLd we are
> no longer having to maintain 1.1.1 in 13.  If people want to keep older
> applications built on unsupported releases still working without
> recompiling, etc. they will have to manage that themselves.  Currently
> we don't support 12.0 on the 12.x branch for example.
What do you mean by 'not supported'?  Don't we put large efforts
into
keeping ABI backward compatible to allow to run _any_ binary built early ?
The only exception I can think of is that we allow ABI mistakes on HEAD
to be fixed in non-backward compatible way.

But for 12.0-built binaries, we offer full support.  In fact it is the easiest
case, if comparing e.g. with binaries built against older branches.

It is possible to bump dso version on stable branch, which I believe was
already done several times.  In this case, we provided compatXx-<arch>
for stable/X branch, which contiained shared objects with previous versions.