Bug 60739 - SSLProtocol settings seem to have no effect
Summary: SSLProtocol settings seem to have no effect
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.25
Hardware: All Linux
: P2 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-16 15:15 UTC by David Favor
Modified: 2019-12-10 08:10 UTC (History)
4 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Favor 2017-02-16 15:15:34 UTC
Changes in SSLProtocol seem to be ignored.

This can be observed in all SSL testers I've used.

The testssl script provides an easy way to check this, without having to wait for minutes (like SSLLabs) for output.

Problem can be shown via...

testssl --protocols https://davidfavor.com/

Environment - Apache-4.2.5 + OpenSSL 1.0.2k + Ubuntu Yakkety.

My goal == disable TLS 1.0 for some of my hosting clients who have PCI requirements for this level of TLS to be disabled.

None of these permutations work. In fact, I can't find any SSLProtocol setting which changes protocols at all. In all cases SSL2 + SSL3 are disabled + all TLS versions are enabled.

Settings tried, that fail to disable TLSv1...

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

# SSLProtocol all -SSLv2 -SSLv3 -TLSv1
# SSLProtocol -all +TLSv1.2
# SSLProtocol TLSv1.2 -TLSv1
# SSLProtocol TLSv1.2
# SLProtocol -All +TLSv1.1 +TLSv1.2

SSLProtocol all -SSLv2 -SSLv3 -TLSv1
Comment 1 David Favor 2017-02-16 15:41:44 UTC
Setting SSLProtocols to -all produces expected behavior, which is an error about no protocols.

This suggests the problem relates to setting TLSv1.2, which incorrectly seems to also enable TLSv1.1 + TLSv1.0 so maybe this is the real problem.

The following also fail disabling TLSv1.

# SSLProtocol all -SSLv2 -SSLv3 +TLSv1.2 -TLSv1
# SSLProtocol -all +TLSv1.2 -TLSv1
Comment 2 David Favor 2017-02-16 15:43:48 UTC
The following also works oddly.

SSLProtocol -all +TLSv1

This enables TLS 1.0 + 1.1 + 1.2 rather than just 1.0 as expected.
Comment 3 David Favor 2017-02-26 15:56:08 UTC
This seem to have changed somewhere between 2.4.18 + 2.4.23 as setting SSLProtocol use to be honored.
Comment 4 David Favor 2017-02-27 15:04:56 UTC
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1665151 - related Ubuntu bug ticket.
Comment 5 Michael Kaufmann 2017-03-14 17:23:49 UTC
I have tested this with Apache 2.4.25 and OpenSSL 1.0.2k, with global settings and also with virtual host settings.

It works for me. For example, with "SSLProtocol -All +TLSv1.1 +TLSv1.2", TLS 1.0 is not possible, TLS 1.1 and TLS 1.2 are possible.

Could you please provide a minimal, stand-alone Apache configuration that shows the problem?
Comment 6 David Favor 2017-03-16 11:36:54 UTC
The problem seems to be an interaction between the Cipher List + SSLProtocol.

Depending on setting of Cipher List SSLProtocol seems to work or be ignored.

These settings disable TLSv1.0

# support old Android phones
SSLProtocol All -SSLv2 -SSLv3 -TLSv1

# Force using custom cipher list
SSLHonorCipherOrder on

Define sslCiphers -ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!LOW
Define sslCiphers ${sslCiphers}:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
SSLCipherSuite ${sslCiphers}

Other sslCiphers settings cause SSLProtocol to be ignored.

I think the fix is either to have SSLProtocol cause a prune of sslCiphers settings or if there's a conflict between SSLProtocol + sslCiphers then have some sort of warning about the conflict.

All in all, the problem is far more complex than it appears on the surface.

For now, I'll resolve my situation by using the above settings.
Comment 7 Eric Covener 2017-03-16 12:48:42 UTC
(In reply to David Favor from comment #6)
> The problem seems to be an interaction between the Cipher List + SSLProtocol.
> 
> Depending on setting of Cipher List SSLProtocol seems to work or be ignored.
> 
> These settings disable TLSv1.0
> 
> # support old Android phones
> SSLProtocol All -SSLv2 -SSLv3 -TLSv1
> 
> # Force using custom cipher list
> SSLHonorCipherOrder on
> 
> Define sslCiphers
> -ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!
> LOW
> Define sslCiphers
> ${sslCiphers}:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-
> AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-
> SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
> SSLCipherSuite ${sslCiphers}
> 
> Other sslCiphers settings cause SSLProtocol to be ignored.
> 

Can you share a specific pair with unexpected results?
Comment 8 martin 2017-04-03 16:22:30 UTC
I have similar issue. Whatever I set in SSLProtocol it's ignored.

apache2ctl -v
Server version: Apache/2.4.10 (Debian)
Server built:   Feb 24 2017 18:40:28

openssl version
OpenSSL 1.0.1t  3 May 2016

If I use the settings provided by David Favor :

SSLProtocol All -SSLv2 -SSLv3 -TLSv1
SSLCipherSuite ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5:!LOW:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA

I got only TLSv1.2 enabled, not TLSv1.1.

I could find a way to activate TLSv1.1, with or without TLSv1. All the time, only TLSv1.2 (I tried a lot of different ciphers suite).

Note that if I try with the openssl s_server command, all is working as expected.
Comment 9 martin 2017-04-03 16:39:18 UTC
Fix:
> I CANNOT find a way to activate TLSv1.1, with or without TLSv1. All the time, only TLSv1.2 (I tried a lot of different ciphers suite).
Comment 10 David Favor 2017-04-03 16:52:57 UTC
Per my other comment above, it appears SSLProtocol is strongly effected by SSLCipherSuite list.

This means SSLProtocol may or may not have any effect, based on SSLCipherSuite list.

Likely this is a complex fix, which might be accomplished by...

1) process SSLCipherSuite

2) then removed any SSLCipherSuite ciphers based on SSLProtocol setting

Simple to describe. Complex to implement.

Another solution might be to just deprecate the SSLProtocol setting.

This would mean SSLCipherSuite determines protocol selection, which appears to be what's actually occurring.

This would involve, removing all code related to SSLProtocol processing + updating documentation for SSLCipherSuite saying, protocols set derive from SSLCipherSuite list provided.
Comment 11 martin 2017-04-03 17:06:44 UTC
The SSLCipherSuite seems has no effect on the protocol my side.
Whatever I put :

SSLCipherSuite ALL:!ADH:!aNULL:!EXP:!EXPORT40:!EXPORT56:!3DES:!eNULL:!NULL:!RC4:!DES:!MD5
or
SSLCipherSuite ALL
or
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP

I got no changes in protocol, only TLSv1.2 is enabled.
Comment 12 Jacob Champion 2017-04-03 18:46:54 UTC
I'm also unable to reproduce. httpd 2.4.25, OpenSSL 1.0.2g -- the protocols are honored correctly with the example ciphersuite lines that have been given in this bug.

For those who can repro: can you please provide the exact set of configuration directives that reproduces the issue?
Comment 13 martin 2017-04-04 17:35:31 UTC
Well, my bad... After trying to reproduce it on a dockerized version, I found I add a false config hidden.....

I confirm that I can use TLSv1.1 as well as TLSv1.2 with this simple config :
SSLProtocol all -SSLv3 -TLSv1
SSLCipherSuite HIGH:!aNULL

Server version: Apache/2.4.10 (Debian)
Server built:   Feb 24 2017 18:40:28
OpenSSL 1.0.1t  3 May 2016

@David Favor : I'm not able to reproduce the issue (having TLS activated depends of ciphers). If you have a ciphers list with which you seen some protocols disabled, share us and I will try.
Comment 14 Brad Lanam 2018-05-15 15:10:00 UTC
The letsencrypt setup process adds the following line, which
includes SSLProtocol and SSLCipherSuite setup.
Quite annoying as a grep for SSLProtocol will not find it.

    Include /etc/letsencrypt/options-ssl-apache.conf
Comment 15 William A. Rowe Jr. 2018-05-15 17:09:49 UTC
The ASF HTTP Server project has nothing to do with letencrypt distributed solutions. Comment #14 does not enhance this report.

(This is distinct from mod_md, which is httpd's response for users to provision letsencrypt certs.)
Comment 16 Brad Lanam 2018-05-16 14:38:06 UTC
I was not entirely clear.
The letsencrypt configuration that gets installed will override any
SSLProtocol and SSLCipherSuite commands with their config.

I tried to get TLSv1 to turn off for a day before noticing the
additional configuration.

It is likely that other followers of this bug are having issues
configuring TLSv1 due to the letencrypt override.
Comment 17 A.Sklepas 2018-08-23 07:36:35 UTC
Hi, i can confirm the issue.
I have searched all configs and VHosts no overides are made it should work but 
nmap --script ssl-enum-ciphers -p 443 IP | grep TLSv
returns TLS1.0,  TLSv1.1

I also investigated the claims about letsencrypt:
Read this topic: https://community.letsencrypt.org/t/how-to-disable-tlsv1/49117/4
On some systems the options-ssl-apache.conf seems to be included in the virtual hosts.
"Include /etc/letsencrypt/options-ssl-apache.conf"

Anyway not in my case plus i have disabled the options in that file to be certain.
PS. Why are we waiting to fix this one? I do see servers that have disabled TLS1 btw...


My info: Apache/2.4.33
Comment 18 Eric Covener 2018-08-23 11:39:29 UTC
(In reply to A.Sklepas from comment #17)
> Hi, i can confirm the issue.
> I have searched all configs and VHosts no overides are made it should work
> but 
> nmap --script ssl-enum-ciphers -p 443 IP | grep TLSv
> returns TLS1.0,  TLSv1.1
> 
> I also investigated the claims about letsencrypt:
> Read this topic:
> https://community.letsencrypt.org/t/how-to-disable-tlsv1/49117/4
> On some systems the options-ssl-apache.conf seems to be included in the
> virtual hosts.
> "Include /etc/letsencrypt/options-ssl-apache.conf"
> 
> Anyway not in my case plus i have disabled the options in that file to be
> certain.
> PS. Why are we waiting to fix this one? I do see servers that have disabled
> TLS1 btw...
> 
> 
> My info: Apache/2.4.33

Show a minimal configuration that does something unexpected if you can.
Comment 19 A.Sklepas 2018-08-24 08:58:52 UTC
Hi, unfortunately i cannot provide a minimal configuration.

I can give you more info as a run some more test in my two Centos 7 DS.


Server 1:

Apache/2.4.33 (IUS)*
latest Centos: Openssl 1.0.2k
TLS1 & 1.1 cannot be disabled

Server 2:
Server version: Apache/2.4.6 (CentOS)
latest Centos: Openssl 1.0.2k
TLS1 & 1.1 Disabled successfully.

I can understand this means an Apache issue. I am not sure if it is somehow an IUS issue, i will contact them too.
*https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/httpd24u.html
Comment 20 David Favor 2018-08-30 11:34:56 UTC
Somehow this has been fixed. Maybe a side effect of other fixes.

As of Apache-2.4.34 the following works.

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
Comment 21 Aaron C 2018-10-02 01:22:04 UTC
While not relating to the discussion of certain SSLProtocol and SSLCipherSuite combinations halting desired SSLProtocols, I did want to add that I had an issue where Let's Encrypt was holding my desired changes back.

I was attempting to use the directive:
`SSLProtocols -all +TLSv1.1 +TLSv1.2` but TLSv1 was still being used. Due to this bug report I noticed that one of my upper Virtual Hosts was indeed using a cert from LE, and in that file they had a default of
SSLProtocol all -SSLv2 -SSLv3

If I could make a suggestion, it would be that we work towards getting more explicit control over what SSLProtocol directives get inherited. It seems strange that a file in a single Virtual Host reference would take precedence over global directives in both my ssl.conf and httpd.conf files.
Comment 22 Stefan Eissing 2018-10-04 07:58:25 UTC
@Aaron C: Let's Encrypt has nothing to do with your server configuration. You probably meant a config addition by an LE client, such as certbot?
Comment 23 Aaron C 2018-10-16 15:22:47 UTC
@Stefan Yes. I'm using Certbot to manage my LE Certs, and Certbot makes those configuration changes automatically. All I'm saying is it would be really useful to have a command / flag that would simply state what directives are taking precedence for configuration, because situations like this arise where some mysterious configuration I had forgotten about took precedence over a global httpd.conf directive. If I could just run a command and it says "SSLProtocol: Inherited from line 20 in .../httpd.conf" would be the simplest way to be forwardly agnostic about where or how the server get's configured.
Comment 24 Arne K. Haaje 2019-01-04 14:54:02 UTC
I can confirm this behaviour on 2.4.37 on two servers. I'm using these directives, and TLSv1.0 is still available

SSLHonorCipherOrder on
        SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !DES !IDEA !RC2"

SSLProtocol -All +TLSv1.1 +TLSv1.2


nmap --script ssl-enum-ciphers -p 443 xxx.xxx.xxx.xxx | grep TLSv
|   TLSv1.0:
|   TLSv1.1:
|   TLSv1.2:
Comment 25 Stefan Eissing 2019-03-11 10:12:51 UTC
This is not a bucket for all possible improvement ideas about mod_ssl configurations. That is better discussed on the user/dev mailing lists.

As to the original report, I read the history of this as:
- not able to reproduce in a minimal set
- the effect of nested include files, some added maybe by a 3rd party tool, e.g. certbot that were not immediately obvious

We have no reproducible setup for the title of this ticket, " SSLProtocol settings seem to have no effect". Otherwise, it would be helpful to provide a minimum example setup.

Otherwise we will close this ticket. We are open to discussions and improvement proposals for making better server configurations. But those should take place on the mailing lists.

Thank you.
Comment 26 Stefan Eissing 2019-03-19 10:23:43 UTC
@David: going through this again, this looks like some intermittent issue with changes ported to ubuntu. And it seems to be fixed now?

Can we close this or what shall we look at? Thanks for your help!
Comment 27 thomas.knaller 2019-03-19 15:38:13 UTC
I have the ame issue on Debian 9.8 with apache2 2.4.25-3+deb9u6
Comment 28 Dirk 2019-04-12 14:59:44 UTC
I have a similar problem with Ubuntu 18.04 (Apache 2.4.39 + openssl 1.1.0g) and it maybe sheds some light into this.

Protocol is always 

SSLProtocol             -All +TLSv1.2


SSLCipherSuite

1) 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:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256

2) 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

Diff is ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-GCM-SHA256.

I played a bit around with those three (using testssl.sh) and looked to me when I enable ECDHE-RSA-AES128-SHA I have TLS 1.0 + 1.1. Which seems strange to me but it's is what I found.

What is going on here?

Dirk
Comment 29 Dirk 2019-04-12 16:08:13 UTC
... same if I add ECDHE-RSA-AES256-SHA (c014 instead if c013).
Comment 30 Dirk 2019-04-12 18:34:36 UTC
... and two more ciphers which "break the TLS 1.2-only" syntax for me:

DHE-RSA-AES128-SHA 0x33
DHE-RSA-AES256-SHA 0x39
Comment 31 thomas.knaller 2019-05-10 07:54:57 UTC
I found something in   /etc/letsencrypt/options-ssl-apache.conf ...
Comment 32 Matt Walsh 2019-12-10 08:10:18 UTC
I can confirm I also experienced this issue on the same versions as reported using Ubuntu 18.04 Server (Bionic)

In my instance I was using the a single virtual host with pre-defined certificate and there was no level of SSLProtocol setup vs SSLCipherSuite setting combination (described above) that would disable TLSv1 TLSv1.1, which are my (and probably many other peoples) security requirements.

I tried combinations of general SSL settings and down to virtual host level.  No settings appeared to be honored regardless

In terms of 'what to fix'.  Well I think there is enough information in the comments here to determine there is an issue between SSLProtocol and SSLCipherSuite, particularly as previous versions have been noted as working successfully.

I would also note that this relationship is NOT documented (that I can find) and if this is determined to be configuration related, then clearer documentation and examples need to be provided.

Clearly people are spending time on this issue, a quick google indicates this is a wide issue.

Unfortunately in my case I don't have any more time to spend working out what should be a 15 minute SSL setup on a web servers.  I will be switching to using NGINX and this will be my preferred setup until this issue can be resolved either in fix or documentation.