TLS v1.0 deadline by pci!

Richard G

Verified User
Joined
Jul 6, 2008
Messages
12,504
Location
Maastricht
I would like to ask if it's not better to disable TLSv1.0 in Apache by default?

Because The Payment Card Industry Security Standards Council (PCI SSC) has set june 30th as the deadline for this TLS version.
https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls

I know I can disable it by using a custom http-ssl.conf but if well-known standards are not using it anymore, wouldn't it be better to disable it by default?
This prevents the need of the custom file.

Same goes for SSL 1.0 but that was already disabled earlier if I'm not mistaken.
 
Since one year my server is TLS 1.2 only. I never got even a single compaint and nobody ever noticed that I disabled TLS 1.0 and 1.1. It pretty compatible with everything recent - both desktop browsers and mobile phones. It's extremely rare to find a computer with Windows XP nowadays and even then it's completely rare to see the person using Internet Explorer. It's even more rare to find Android phones with software older than 4.4. I also disabled all outdated ciphersuites as well.

Here is what I use:

SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
 
Last edited:
If you wish, you can look at the browser compatibility table for my personal domain on SSLLabs here:

https://www.ssllabs.com/ssltest/analyze.html?d=www.cphpvb.net&latest

You'll see that the browsers that does not support the server configuration are ancient:

Android 2.3.7 Protocol mismatch (not simulated)
Android 4.0.4 Protocol mismatch (not simulated)
Android 4.1.1 Protocol mismatch (not simulated)
Android 4.2.2 Protocol mismatch (not simulated)
Android 4.3 Protocol mismatch (not simulated)
Baidu Jan 2015 Protocol mismatch (not simulated)
IE 6 / XP No FS 1 No SNI 2 Protocol mismatch (not simulated)
IE 7 / Vista Protocol mismatch (not simulated)
IE 8 / XP No FS 1 No SNI 2 Protocol mismatch (not simulated)
IE 8-10 / Win 7 R Protocol mismatch (not simulated)
IE 10 / Win Phone 8.0 Protocol mismatch (not simulated)
Java 6u45 No SNI 2 Protocol mismatch (not simulated)
Java 7u25 Protocol mismatch (not simulated)
OpenSSL 0.9.8y Protocol mismatch (not simulated)
Safari 5.1.9 / OS X 10.6.8 Protocol mismatch (not simulated)
Safari 6.0.4 / OS X 10.8.4 R Protocol mismatch (not simulated)


P.S. SSL 3.0 was disabled earlier because of a serious security flaw discovered.

TLS 1.0 is not hacked yet. It's just considered less secure than 1.2 for various technical reasons. Soon people will be pushed to even more secure 1.3 (it drops supports for outdated ciphersuites and speed the things a bit).
 
Last edited:
You'll see that the browsers that does not support the server configuration are ancient:
Well I wouldn't want to block IE10 yet, even if it's ancient. It's default on fresh Win 7 installations or after the first few updates. People must be able to visit my site until all updates have run (which are massive). But that's a personal choice.

Indeed you made things safer which is good. But my intention is to have at least part of this default in Directadmin by having DA team disable TLS v1 by default, which would be good case around now. Not only because of the end of life, but also because only ancient stuff uses it.
 
1. TLS 1.0 is not end of life. It's still secure enough and browsers did not drop support for it (for the "still secure" - read the next reply).

2. TLS 1.1 and 1.2 in Internet Explorer 10 are disabled by default. So disabling TLS 1.0 kills the default IE10 anyway.

3. TLS 1.1 was relatively short lived - two years only and 1.2 appeared. And when released, TLS 1.2 was adopted almost immediately by every browser anyway (you can check the browser compatibility list in Wikipedia). On the opposite side, when TLS 1.1 appeared everything was still good with SSL 3.0 and server people were not in rush to upgrade. Therefore:
- the adoption rate of TLS 1.1 was not high on the server level.
- nowadays there should be rare to non-existing cases of browsers who supports TLS 1.1 and not TLS 1.2.

These may be people who updated their browsers back in 2007 lets say and turned off their autoupdates, etc; however I highly doubt it.

4. TLS 1.2 is much better than everything before it mainly because it supports SHA2 for signing. Despite that, it really depends on your configuration what ciphersuites you will support. You can have insecure TLS 1.2 with weak ciphers and you can have secure TLS 1.0 when using secure ciphers. So just the version is not enough - the algorithms below it is the important thing.

So my verdict is that disabling TLS 1.0 and not disabling TLS 1.1 is pointless. You should either disable both or not disable anything.
 
Last edited:
P.S. Not to be misunderstood - there are attacks (BEAST) against TLS 1.0; however they are just theoretical - not a single case is reported yet. Still there is no good reason to keep it enabled except if you expect 12+ years old unupdated computers still live in the internet. Yeah, there may be someone... but it's highly unlikely - better make them at least install an update.

People are regularly showing some stats of browser usage and still showing ancient browsers out there. But you miss an important point - there are lots of bots too which fake their headers. So really - the real amount of users with ancient browsers is too low nowadays. Everything is on autoupdate from ages.
 
TLS 1.0 has been disabled by default in CB 2.0 rev. 1886.
 
TLS 1.0 is not end of life. It's still secure enough and browsers did not drop support for it (for the "still secure" - read the next reply).
Well. You might have a look on the internet Wattie, because in spite of the fact that it might still be secure when patched good enough, everybody is declaring it end of life.
Not only the PCI Council, which is the most important, but Microsoft declared end of support and even Adobe declared end of life for 1.0, well... end of support but their title says end of life.
https://blogs.adobe.com/connectsupport/adobe-connect-end-of-life-for-tls-1-0/
I don't know who is really entitled to declare it end of life, but if these major company's are declaring it and declaring end of support, it's end of life to me. :) Doesn't matter if it's unsafe or not.

@Martinas: Only in new installations or apache updates correct?
Or will it be automatically disabled too when I do a ./build udpate_versions too next time?
 
It's not EOL if browsers like Chrome and Firefox are still supporting it by default.

By the way you should have noticed that I vote for disabling it - I did it long ago.

And I will repeat myself - if you disable TLS 1.0 there's no reason to keep TLS 1.1. Just go straight to TLS 1.2 and that's it.
 
@Martinas: Only in new installations or apache updates correct?
Or will it be automatically disabled too when I do a ./build udpate_versions too next time?

"./build rewrite_confs" is enough for that.
 
And what about the introduction of TLS v1.3, hopefully DA will also introduce that soon without having to do any custom configs.
 
TLS v1.3 should be supported without any additional modifications if your version of openssl supports it.
 
@wattie:
It's not EOL if browsers like Chrome and Firefox are still supporting it by default.
They also support PHP 5.2 by default, so that's no argument to me. So again my question, who (or which organisation) has the right to declare SSL end of life? Looks to me the PCI Council can do that, because every company is follow their line, and stating they pushed the EOL to juni 2018.
So unless you can provide a link that declares it's not end of life, I can't believe you, because all major company's are declaring it end of life and/or declaring end of support.

@Smtalk: Thank you!
 
Browsers have nothing to do with PHP. They present HTML and related content no matter what is serving it on the other end.

PHP 5.2 is EOL because the developers said so.

So again my question, who (or which organisation) has the right to declare SSL end of life?!

TLS 1.0 is not dead as the standards organization - Internet Engineering Task Force (IETF) - did not deprecate it yet. And that's why all browsers continue to support it BTW.
 
@Wattie: Thank you, that was an argument and answer I was looking for. Because if I google, it looks like PCI had the right to declare it end of life.
It won't take long anymore then, even for TLS v1.1 which (if I understand this memo correctly) will also be declared EOL en of this year and it's said in this memo not to use TLSv1.0 anymore.
https://tools.ietf.org/id/draft-moriarty-tls-oldversions-diediedie-00.html

@JohnyByk:
Yes you can, the same way we disabled TLS 1.0 before.
Go to /etc/dovecot/conf and edit SSL.conf.
change:
Code:
ssl_min_protocol = TLSv1.1
to
Code:
ssl_min_protocol = TLSv1.0
The copy /etc/dovecot/conf/ssl.conf to /usr/local/directadmin/custombuild/custom/dovecot/conf/ssl.conf
restart dovecot.
And then TLS v1.0 should be working again.
The custom file takes care of the fact that on a new dovecot configuration, the ssl stays to what you changed.
 
It won't take long anymore then, even for TLS v1.1 which (if I understand this memo correctly) will also be declared EOL en of this year and it's said in this memo not to use TLSv1.0 anymore.

Correct. Both 1.0 and 1.1 will be deprecated.

The emails are a bigger issue than the HTTP. Outlook for example uses the default Internet Explorer configuration via the WinHTTP protocol. So imagine Windows 7 or Windows 8 user without updated machine - he can use Firefox/Chrome and enjoy security; however his Outlook program will still use the old protocol. So if I disable TLS 1.0 suddenly some users start to complain. Microsoft released update for WinHTTP to allow it to connect with TLS 1.1 and 1.2 in March 2016 - that's not too long ago. And they not only need to install an update but they also need to make registry edits to fix the issue. That's a disaster for shared hosting support.

From the MS world only Windows 8.1 and Windows 10 enable TLS 1.1 and 1.2 for WinHTTP. All older versions need a hack. Windows Vista is out of the game - no 1.1 or 1.2 possible at all, so no secure mail there.

That's the reason why I still support TLS 1.0 for mail. I disabled 1.0 and 1.1 for Apache only.

Outlook on Mac is even bigger hassle. There are live configurations with version 2011 that use SSL 2.0 only. What a disgrace Microsoft. It's good that we don't care about them.
 
Last edited:
@Wattie: Thank you, that was an argument and answer I was looking for. Because if I google, it looks like PCI had the right to declare it end of life.
It won't take long anymore then, even for TLS v1.1 which (if I understand this memo correctly) will also be declared EOL en of this year and it's said in this memo not to use TLSv1.0 anymore.
https://tools.ietf.org/id/draft-moriarty-tls-oldversions-diediedie-00.html

@JohnyByk:
Yes you can, the same way we disabled TLS 1.0 before.
Go to /etc/dovecot/conf and edit SSL.conf.
change:
Code:
ssl_min_protocol = TLSv1.1
to
Code:
ssl_min_protocol = TLSv1.0
The copy /etc/dovecot/conf/ssl.conf to /usr/local/directadmin/custombuild/custom/dovecot/conf/ssl.conf
restart dovecot.
And then TLS v1.0 should be working again.
The custom file takes care of the fact that on a new dovecot configuration, the ssl stays to what you changed.


I need enable TLS 1.0 for apache_nginx. Dovecot can be running on TLS 1.2.
This setting work for both (httpd, dovecot) or only for dovecot?

Regards
 
Correct. Both 1.0 and 1.1 will be deprecated.

The emails are a bigger issue than the HTTP. Outlook for example uses the default Internet Explorer configuration via the WinHTTP protocol. So imagine Windows 7 or Windows 8 user without updated machine - he can use Firefox/Chrome and enjoy security; however his Outlook program will still use the old protocol. So if I disable TLS 1.0 suddenly some users start to complain. Microsoft released update for WinHTTP to allow it to connect with TLS 1.1 and 1.2 in March 2016 - that's not too long ago. And they not only need to install an update but they also need to make registry edits to fix the issue. That's a disaster for shared hosting support.

From the MS world only Windows 8.1 and Windows 10 enable TLS 1.1 and 1.2 for WinHTTP. All older versions need a hack. Windows Vista is out of the game - no 1.1 or 1.2 possible at all, so no secure mail there.

That's the reason why I still support TLS 1.0 for mail. I disabled 1.0 and 1.1 for Apache only.

Outlook on Mac is even bigger hassle. There are live configurations with version 2011 that use SSL 2.0 only. What a disgrace Microsoft. It's good that we don't care about them.

If I understand you correct, then it should not cause any problems for web pages when TLS 1.0 is disabled, but all users running Outlook on Windows 7 or older will have broken email? Is that correct? If so, DirectAdmin should by default enable TLS 1.0 in /etc/dovecot/conf/ssl.conf so that it is only disabled for other services.
 
I need enable TLS 1.0 for apache_nginx. Dovecot can be running on TLS 1.2.
This setting work for both (httpd, dovecot) or only for dovecot?

That's only for dovecot. For Apache you must edit /etc/httpd/conf/extra/httpd-ssl.conf. For nginx I don't know.

If so, DirectAdmin should by default enable TLS 1.0 in /etc/dovecot/conf/ssl.conf so that it is only disabled for other services.

It does.

But disabling older TLS is still not catastrophic. Some users will have to start using unencrypted mail. Or upgrade their mail clients (hopefully!).
 
Back
Top