Should I disable TLS 1.0 and TLS 1.1. support and get an A at SSL Labs?

My site

https://www.kirkbymicrowave.co.uk/

gets its SSL rated a “B” at

https://www.ssllabs.com/ssltest/analyze.html?d=www.kirkbymicrowave.co.uk

I assumed that this “B” capping was a result of the Let’s Encrypt certificate, but I see another domain

https://rsgb.org/

which also uses Let’s Encrypt, gets an A.

https://www.ssllabs.com/ssltest/analyze.html?d=rsgb.org

The difference seems to be I’m supporting TLS 1.0 and TLS 1.1. It is worth disabling TLS 1.0 and TLS 1.1.?

I looked at what I believe is the Apache SSL configuration file

/etc/apache2/mods-enabled/ssl.conf

and see this.

	#   The protocols to enable.
	#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
	#   SSL v2  is no longer supported
	SSLProtocol all -SSLv3
1 Like

It all depends on how much backwards compatibility you require. You can use your sites statistics to figure out how many customers/visitors you’ll be loosing when you disable TLSv1.0 and TLSv1.1. If that’s acceptable, it would be best to disable those indeed.

And why did you think the grade B was being caused by the Let’s Encrypt certificate? Did you think a Let’s Encrypt was less secure or something? Why do people still think that? Sigh…

4 Likes

Hi @drkirkby

that’s wrong. Letsencrypt certificates are from a well-known CA, so all browsers and tools accept Letsencrypt certificates.

Tls.1.0 + 1.1 active -> Grade B

I’m sure you have read the link you can find in your result:

2 Likes

[quote=“Osiris, post:2, topic:131796, full:true”]
It all depends on how much backwards compatibility you require. You can use your sites statistics to figure out how many customers/visitors you’ll be loosing when you disable TLSv1.0 and TLSv1.1. If that’s acceptable, it would be best to disable those indeed.[/quote]

where do I find that information? I am using Apache on Debian

I never gave it much thought to be honest.

I can’t seem to disable TLS 1.0 and 1.1 despite trying. I changed

#SSLProtocol all -SSLv3

to
SSLProtocol all -SSLv3 -TLSv1.1 TLSv1

but still https://www.ssllabs.com reports the site is supporting TLS 1.0 and 1.1/.

I tried reloading the configuration, then when that did not work, I stoped the server and started it again. Still it seems TLS 1.0 and 1.1 and being supported.

In the statistics you can gather from your Apache logs? There’s probably plenty of Apache log parsers out there.

Isn’t there a minus sign missing before TLSv1? You need to reload Apache before any changes become apparent.

Oops, I now have

SSLProtocol all -SSLv3 -TLSv1.1 -TLSv1

but still it supporting 1.0 and 1.1, after reloading Apache.

Then you have edited the wrong place.

Check

apachectl -S

to find your active vHosts.

2 Likes

It’s weird, as I purposely mis-typed a command in the ssl configuration file, and when I tried to reload Apache it reported an error.

root@NEW:/etc/apache2/mods-available# /etc/init.d/apache2 reload
[....] Reloading apache2 configuration (via systemctl): apache2.serviceJob for apache2.service failed.
See "systemctl status apache2.service" and "journalctl -xe" for details.
 failed!

So Apache must be reading the file.

I typed the command suggested, and it would indicate that the virtual host is being read. Note there are some files with similar names, like kirkby and kirby, and the .com and .co.uk. Also with and without www - I suspect there’s a way around that, but I’m not sure how, so I have them in separate files.

root@NEW:/etc/apache2/mods-available# /usr/sbin/apachectl -S
AH00557: apache2: apr_sockaddr_info_get() failed for NEW
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk-le-ssl.conf:2)
         port 443 namevhost dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk-le-ssl.conf:2)
         port 443 namevhost g8wrb.co.uk (/etc/apache2/sites-enabled/g8wrb.co.uk-le-ssl.conf:2)
         port 443 namevhost kirbymicrowave.co.uk (/etc/apache2/sites-enabled/kirbymicrowave.co.uk-le-ssl.conf:2)
         port 443 namevhost kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/kirkbymicrowave.co.uk-le-ssl.conf:2)
         port 443 namevhost www.dhars.org.uk (/etc/apache2/sites-enabled/www.dhars.org.uk-le-ssl.conf:2)
         port 443 namevhost www.g8wrb.co.uk (/etc/apache2/sites-enabled/www.g8wrb.co.uk-le-ssl.conf:2)
         port 443 namevhost www.kirbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirbymicrowave.co.uk-le-ssl.conf:2)
         port 443 namevhost www.kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirkbymicrowave.co.uk-le-ssl.conf:2)
*:80                   is a NameVirtualHost
         default server dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk.conf:1)
         port 80 namevhost dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk.conf:1)
         port 80 namevhost g8wrb.co.uk (/etc/apache2/sites-enabled/g8wrb.co.uk.conf:1)
         port 80 namevhost kirbymicrowave.co.uk (/etc/apache2/sites-enabled/kirbymicrowave.co.uk.conf:1)
         port 80 namevhost kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/kirkbymicrowave.co.uk.conf:1)
         port 80 namevhost kirkbymicrowave.com (/etc/apache2/sites-enabled/kirkbymicrowave.com.conf:1)
         port 80 namevhost www.dhars.org.uk (/etc/apache2/sites-enabled/www.dhars.org.uk.conf:1)
         port 80 namevhost www.g8wrb.co.uk (/etc/apache2/sites-enabled/www.g8wrb.co.uk.conf:1)
         port 80 namevhost www.kirbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirbymicrowave.co.uk.conf:1)
         port 80 namevhost www.kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirkbymicrowave.co.uk.conf:1)
         port 80 namevhost www.kirkbymicrowave.com (/etc/apache2/sites-enabled/www.kirkbymicrowave.com.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default 
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
1 Like

Yes but Apache is notorious for running at all cost.
Which means that there may be multiple SSLProtocol statements.
And even though they all will be processed and must by syntaxically correct, the last one is the one that will eventually be used.

So technically that amounts to a parameter/statement overlap/overwrite - but Apache says nothing to you about it.

If I had to guess, I would say that you are modifying one in the default file or main config file and there exists another via an include statement.

Try:
grep -Ri SSLProtocol /etc/apache2/

1 Like

This link

which is about disabling TLS 1.0 and 1.1 on Ubuntu, not Debian, mentions a Let’s Encrypt file.

/etc/letsencrypt/options-ssl-apache.conf

That has the line

SSLProtocol all -SSLv2 -SSLv3

so I’m guessing that I probably need to edit that file too.

Dave

1 Like

Yes but you also need to consider proper programming.
If you will be using that one (recommended), then you should remove the other - as it serves no purpose (other than to confuse future editors)

1 Like

might be in here too.
/etc/letsencrypt/options-ssl-apache.conf:10:SSLProtocol +TLSv1.2 +TLSv1.3

1 Like

I’m confused now, as the directory

/etc/apache2/mods-enabled

has two ssl related links.

root@NEW:/etc/apache2/mods-enabled# ls -l *ssl*
lrwxrwxrwx 1 root root 26 Aug 14 14:07 ssl.conf -> ../mods-available/ssl.conf
lrwxrwxrwx 1 root root 26 Aug 14 14:07 ssl.load -> ../mods-available/ssl.load

but Let’s Encrypt only has one file,

/etc/letsencrypt/options-ssl-apache.conf

so it begs the obvious question, if I remove ssl.conf, should I remove ssl.load? Also, the Let’s Encrypt file has warnings about editing the file manually

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.

Anyway, editing the Let’s Encrypt file, to

# SSLProtocol             all -SSLv2 -SSLv3
SSLProtocol             all -SSLv2 -SSLv3  -TLSv1.1 -TLSv1

does disable TLS 1.0 and 1.1, so my website gets an A from SSL Labs.

https://www.ssllabs.com/ssltest/analyze.html?d=www.kirkbymicrowave.co.uk

Finally I got the older protocols disabled, but I do agree having two files that are setting the same parameter is not good.

1 Like

SSLProtocol can be used per VirtualHost, perhaps for having backwards compatibility for some VirtualHosts, but not for others. Therefore, I wouldn’t recommend removing all other SSLProtocol directives, unless you’re absolutely certain it won’t break anything.

1 Like

All the TLS enabled virtual host files end with le-ssl.conf
It is pretty safe to say that they all have an include for SSLProtocol.
So I don’t see anything else left to break.

As for the two enabled mods, we should have a look at the full contents of those files before delete/removing/disabling either of them (completely).

1 Like

No, they do different things.

1 Like

It seems poor to me that certbot has added a configuration file for Let’s Encrypt, which includes

SSLProtocol

when there’s already an Apache configuration file for it.

Then you are misunderstanding their implementation.
They include that file only within the vhost config they modify - so it has zero effect on anything else you may be doing within your config.
But in this case, as you are not doing anything else, you really don’t need both.

1 Like

If you can fully support newer clients then there is no reason not to only have TLS 1.2 enabled (and TLS 1.3 if possible)

is the Qualys SSL test for one of my sites

1 Like

The files ssl.load and ssl.conf are not specific to any one virtual host. The ssl.conf is a global configuration file.

1 Like