Page MenuHomeFreeBSD

Turn off SSLv3.
ClosedPublic

Authored by gordon on May 21 2020, 4:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 21 2024, 9:00 AM
Unknown Object (File)
Feb 21 2024, 8:59 AM
Unknown Object (File)
Feb 21 2024, 8:59 AM
Unknown Object (File)
Feb 21 2024, 1:54 AM
Unknown Object (File)
Feb 12 2024, 7:54 AM
Unknown Object (File)
Feb 11 2024, 3:10 PM
Unknown Object (File)
Dec 22 2023, 11:24 PM
Unknown Object (File)
Dec 3 2023, 5:39 PM
Subscribers

Details

Summary

Turn off SSLv3 in OpenSSL build.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

gordon added a subscriber: jmg.

Secteam and jkim to review. Per a comment from jmg. we should turn of SSLv3 in the OpenSSL build. I did a quick build test with this an confirmed the symbols related to SSLv3 are not in the resulting libssl library.

cem added a subscriber: cem.

We should also disable SSL2, if we do not already. And perhaps TLS 1.0?

I'm surprised the OpenSSL build has SSL3 enabled in 2020.

This revision is now accepted and ready to land.May 21 2020, 5:07 PM
In D24945#549197, @cem wrote:

We should also disable SSL2, if we do not already. And perhaps TLS 1.0?

SSLv2 already doesn't exist, so no problem there.

TLSv1.0 is still widely deployed. I think removing support entirely is premature.

I'm surprised the OpenSSL build has SSL3 enabled in 2020.

That's just our OpenSSL build. The out of the box OpenSSL build has SSLv3 compiled out by default. Not sure if it was an explicit decision to leave SSLv3 in the build or an artifact of the bmake process to get it hooked into our buildworld process.

In D24945#549197, @cem wrote:

We should also disable SSL2, if we do not already. And perhaps TLS 1.0?

TLSv1.0 is still widely deployed. I think removing support entirely is premature.

Do you have some data around "still widely deployed?" For example, this study seems to contradict that claim: https://arxiv.org/pdf/1907.12762

See figure 1 on page 8; TLS1.1 has essentially zero deployment since 2013 (everyone who bothers to update moved to 1.2) and 1.0 has been dropping off over time, dropping below 10% in ~2016 and somewhere in the single-digit percent range as of 2019.

TLS 1.0 been known-broken since (?)2006. NIST has recommended not using it since 2014, if not earlier (https://www.nist.gov/news-events/news/2014/04/nist-revises-guide-use-transport-layer-security-tls-networks) and has recommended not using TLS 1.1 more recently (https://doi.org/10.6028/NIST.SP.800-52r2 published 2019).

Qualys claim major browsers have deprecated TLS 1.0 and 1.1 as of January of this year (https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices):

However, you should plan to retire TLS v1.0 and TLS v1.1 in the near future. For example, the PCI DSS standard will require all sites that accept credit card payments to remove support for TLS v1.0 by June 2018. Similarly, modern browsers will remove the support for TLS v1.0 and TLS v1.1 by January 2020.

Anyway, TLS 1.0/1.1 discussion is somewhat orthogonal to SSL3 — we should definitely remove SSL3! — but I think it is a reasonable time to finally retire TLS1.0 and 1.1 as well, and this was a good reminder.

It's okay but we need to disable SSLv3 from fetch(3) first. Please see D24947.

In D24945#549309, @jkim wrote:

It's okay but we need to disable SSLv3 from fetch(3) first. Please see D24947.

I don't think it's a hard dependency as the code still compiles either way. Of course the option won't do anything. Either way, I'll commit in the next day or so.

In D24945#549197, @cem wrote:

We should also disable SSL2, if we do not already. And perhaps TLS 1.0?

SSLv2 already doesn't exist, so no problem there.

TLSv1.0 is still widely deployed. I think removing support entirely is premature.

Yeah, when I "disabled" some ciphers, it killed 1.0 and 1.1, and prevented a LOT of mail servers from connecting.

If you want to test, you generate a self sign cert:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

combine them together:
cat cert.pem key.pem > server.pem

run the server:
/usr/bin/openssl s_server

check out testssl.sh:
git clone --depth 1 https://github.com/drwetter/testssl.sh.git

and run it against the server:
cd testssl.sh
./testssl.sh 127.0.0.1:4433

and examine the output to verify the SSLv2 and SSLv3 are not offered.

In D24945#549333, @jmg wrote:

If you want to test, you generate a self sign cert:

We(tm) should really have a test that runs these steps and verifies the output.

This revision was automatically updated to reflect the committed changes.