disabling TLS 1.0 and 1.1

[MercSec]

Related to the latest scienetific publications TLS 1.0 and 1.1 are also brocken.
I would like to recomment to remove those protocols completly from the LibreSSL-Codebase.

What might happen? Browsers like Firefox will keep using NSS.
Other applications like wget might use TLS 1.0 if the other Server provides just TLS 1.0.
If TLS 1.0 and 1.1 would get removed such connections might not work anymore.

But consider the risk of providing brocken cryptographic protocols to everybody else.
This would be a major step ahead to provide a "secure" protocol (the only one left...).

OpenSource-Projects like wget, lynx and others could get contacted about this matter (of course this would be a bigger effort). The impact on the Client wich manadges for example SAN Storages is low and the effect by providing TLS 1.2 only at the Server side enforces companies to let IE6 rotten in the dust.

All modern Browsers are capable to provide TLS 1.2 and because of the OpenBSD development circle such Changes could get "tested" between releases to see how many applications have Issues.

I consider this Request an "Issue" because TLS 1.0 and 1.1 are brocken and it would be kind if you might could consider to adopt the idea to provide just TLS 1.2.

[busterb]

Thank you for your comments. Feel free to disable these protocols in your own software using: SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1);

[MercSec]

That implies rebuilding many Daemons from the OpenBSD-base system because Daemons like httpd/opensmtpd/relayd do not allow a user to select a specific protocol (in this case: a secure protocol).

Since TLS 1.0 and 1.1 are brocken I like to know if your advice is realy the official answer?
Please take a look at the examples I listed because I requested this Change not for people who can modify the Source Code of the Daemons they do use.

Also I like to know about the concerns of dropping the protocol support for 1.0 and 1.1 completly.
It will become inevitable anyway and it complies with the "secure by default" dogma...

[4a6f656c]

In summary, the goal of LibreSSL is to provide a SSL/TLS library that is backwards compatible with OpenSSL. While increasing security and disabling broken protocols is one of our aims, only around 50% of websites currently support TLSv1.2:

https://www.trustworthyinternet.org/ssl-pulse/

Additionally, there are still a large number of active SSL/TLS clients that only support TLSv1.0 and do not support TLSv1.2. As such, it is a fine line to walk and we're not in a position where we can make the call to make ~50% of websites inaccessible for all users, or make your website inaccessible to, for example, mobile users with Android 4.3. This also does not consider other TLS use cases such as SMTPS/STARTSSL where there is a huge range of legacy clients/servers. In many cases TLSv1.0 is still significantly better than being forced to use clear text HTTP or SMTP since one end does not support TLSv1.2.

In short, while in an ideal world we would make LibreSSL TLSv1.2 only, we are not there yet - the best we can do is continue to set reasonable defaults and encourage system administrators to use appropriate configuration. Current relayd definitely has the ability to disable/enable SSL/TLS protocols on a fine grained level and httpd is likely to gain the same soon. In the mean time, explicitly limiting the cipher suites to TLSv1.2 will prevent earlier protocol versions from being used.

And to make the situation even clearer, TLSv1.2 is also broken unless you are using an AEAD cipher suite:

"everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken"

https://www.imperialviolet.org/2014/12/08/poodleagain.html

Disabling TLSv1.0 and TLSv1.1 will not help here - as the system administrator you need to take this into consideration and choose appropriate protocol and cipher suite configuration based on your users and how many people you are willing to prevent from accessing your site.

[MercSec]

That are indeed strong arguments and I noticed such problems myself related to the last Client we worked for (jdk 1.6.. + massively outdated Linuxfarm). So I am aware of "enterprise" installations wich do have such Issues...

What I would recomment to consider is to disable the old Protocols and unsecure Ciphers-Suites between releases to see the Fallout and allow users to enable them again via a configuration file. Also it would be possible to restore the "backward compatibility" with an Option in a configuration file (/etc/openssl.conf).

People sometimes need to get enforced to update their infrastructure. An always patched Server (be it Debian, Redhat whatever) is capable to talk TLS 1.2 (+AEAD) but a "never touched" SLES 9 wich has never seen any patches has a lot of other security related Issues... (and yes I saw such installations recently...).

Such a configuration option could assist Administrators by breacking their Setups ("Oh there's something in the backend wich needs to get fixed.." or "We need to contact our Software Vendor to get something fixed!") but allowing them to restore the functionality with an Option in a configuration file. JDK7 for example is not worth (even if widely deployed) to get considered because it's EOL in ~6 months ( http://www.oracle.com/technetwork/java/eol-135779.html ) and JDK8 uses TLS 1.2 by default.
Windows Server 2008 is EOL (Mainstream) in Jan 2015 and if you own large Installatiosn you should talk to Microsoft to provide TLS 1.2 there as well. All Recent OS Versions from MS support TLS 1.2 in all Servers (Exchange, IIS ...).

I think both argumentations are valid but my suggestion is far more agressive (I would likely break some SetUps but allow users to restore the old behavior VERSUS There are so many outdated Servers/Installations out there and we won't break anything). What about such a configuration option in the openssl.conf?

You could also do it vice versa and provide an Option wich allows JUST secure Protocols/CipherSuites.
If set in /etc/openssl.conf just secure stuff gets used and if the option is not set (or the file is missing) it works like it does now. But this way a user would have a Choice....

You don't exspect that Users, Administrators or even Developers do realy know about a SetUp if it's old and unsupported for years, or? :-)

I found configuration/programming Issues in Java-Backends and third party (developed) Software by just enforcing TLS 1.0 in the Network of the Client I worked for but I had LoadBallancers wich allowed me to disable exactly some protocols/ciphers. TLS 1.0 because they use still JDK 1.6....

p.s.
I ment TLS 1.2 + AEAD but thank you very much to point it out as well!