Bug 1388456 - Disable TLSv1.0 in Apache SSL configuration
Summary: Disable TLSv1.0 in Apache SSL configuration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Services
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.1.1
: 4.1.1.3
Assignee: Lev Veyde
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On: 1387996
Blocks: RHV_TLS_1_2_SUPPORT
TreeView+ depends on / blocked
 
Reported: 2016-10-25 12:03 UTC by Martin Perina
Modified: 2019-04-28 13:40 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-04-21 09:30:43 UTC
oVirt Team: Integration
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: exception+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 67831 0 master MERGED packaging: setup: Change the SSL protocols supported by Apache 2017-03-01 09:27:33 UTC
oVirt gerrit 73359 0 ovirt-engine-4.1 MERGED packaging: setup: Change the SSL protocols supported by Apache 2017-03-01 16:36:07 UTC
oVirt gerrit 73360 0 ovirt-engine-4.1.1.z MERGED packaging: setup: Change the SSL protocols supported by Apache 2017-03-01 16:36:35 UTC

Description Martin Perina 2016-10-25 12:03:41 UTC
Description of problem:

Currently we support TLSv1.0+ protocols in Apache configuration for engine. As TLSv1.0 is not considered to be secure according to [1] since June 30th 2016, we should allow only TLSv1.1 and TLSv1.2 protocols.


[1] https://blog.varonis.com/ssl-and-tls-1-0-no-longer-acceptable-for-pci-compliance/

Version-Release number of selected component (if applicable):

4.0

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Lev Veyde 2016-11-28 16:05:06 UTC
(In reply to Martin Perina from comment #0)
> Description of problem:
> 
> Currently we support TLSv1.0+ protocols in Apache configuration for engine.
> As TLSv1.0 is not considered to be secure according to [1] since June 30th
> 2016, we should allow only TLSv1.1 and TLSv1.2 protocols.
> 
> 
> [1]
> https://blog.varonis.com/ssl-and-tls-1-0-no-longer-acceptable-for-pci-
> compliance/
> 
> Version-Release number of selected component (if applicable):
> 
> 4.0
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

I think that in that case we should also disable SSLv3, which is the predecessor to TLSv1.

We must take into consideration though, that disabling SSLv3 and TLSv1 support may cause the admin to be unable to connect using some of the older web browsers/tools (mostly for API usage), so this change should be clearly documented, along with the instructions to override it back to the default behaviour.

Comment 2 Martin Perina 2016-12-08 16:03:46 UTC
> 
> I think that in that case we should also disable SSLv3, which is the
> predecessor to TLSv1.

Correct, IMO we should allow only TLS1.1 and TLS1.2

> 
> We must take into consideration though, that disabling SSLv3 and TLSv1
> support may cause the admin to be unable to connect using some of the older
> web browsers/tools (mostly for API usage), so this change should be clearly
> documented, along with the instructions to override it back to the default
> behaviour.

I think that most modern browser supports TLS1.1+ [1], but to be sure, Vojtech ,do we have a list of supported browsers?

[1] https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers#cite_note-Win7TLS1.1-90

Comment 3 Martin Perina 2016-12-08 16:13:01 UTC
So according to Vojtech we support latest Firefox ESR on RHEL and as a best effort latest Firefox and Chrome on any OS and IE10+. So we should be OK, as all those browsers supports TLS1.1+

Comment 4 Vojtech Szocs 2016-12-08 16:24:39 UTC
(In reply to Martin Perina from comment #3)
> So according to Vojtech we support latest Firefox ESR on RHEL and as a best
> effort latest Firefox and Chrome on any OS and IE10+. So we should be OK, as
> all those browsers supports TLS1.1+

Ack.

Please note that according to [1], "only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates" [from Microsoft].

[1] https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support

Most current IE version today is IE 11, so that should be our (oVirt/RHV) only supported IE version.

Comment 5 Yaniv Kaul 2017-02-12 09:13:50 UTC
Can we revive this? Seems to be stuck on code review?

Comment 6 Lev Veyde 2017-02-12 10:34:36 UTC
(In reply to Yaniv Kaul from comment #5)
> Can we revive this? Seems to be stuck on code review?

Yes, sure. Fixed the few small issues and rebased the patch.
Now need to verify it.

Comment 7 Yedidyah Bar David 2017-02-12 11:15:08 UTC
Do we want to do this also on upgrades?

Current pending patch is for clean installs.

If we want to make it change the conf during upgrade, we probably want to also ask the user again, to prevent unintended overwriting of manual changes.

Comment 8 Yaniv Kaul 2017-02-13 07:58:04 UTC
(In reply to Yedidyah Bar David from comment #7)
> Do we want to do this also on upgrades?
> 
> Current pending patch is for clean installs.
> 
> If we want to make it change the conf during upgrade, we probably want to
> also ask the user again, to prevent unintended overwriting of manual changes.

We should not overwrite manual changes. I'm not sure the code to only change this settings is worth it - we can probably have a KB documenting how to perform most changes manually. In any case - separate bug.

Comment 9 Martin Perina 2017-02-13 09:00:47 UTC
(In reply to Yaniv Kaul from comment #8)
> (In reply to Yedidyah Bar David from comment #7)
> > Do we want to do this also on upgrades?
> > 
> > Current pending patch is for clean installs.
> > 
> > If we want to make it change the conf during upgrade, we probably want to
> > also ask the user again, to prevent unintended overwriting of manual changes.
> 
> We should not overwrite manual changes. I'm not sure the code to only change
> this settings is worth it - we can probably have a KB documenting how to
> perform most changes manually. In any case - separate bug.

I'm not sure we can reliably say that /etc/httpd/conf.d/ssl.conf was manually changed, so we may overwrite custom changes even for new installations (although it's not too much probable).

So for new installation I'd always change SSLProtocols (as current patch does) and for updates/upgrades I would just print a warning that ssl.conf should be updated not to allow unsecure protocols and show our suggested configuration "SSLProtocols all -SSLv3 -TLSv1".

Comment 10 Yedidyah Bar David 2017-02-13 09:11:32 UTC
(In reply to Martin Perina from comment #9)
> (In reply to Yaniv Kaul from comment #8)
> > (In reply to Yedidyah Bar David from comment #7)
> > > Do we want to do this also on upgrades?
> > > 
> > > Current pending patch is for clean installs.
> > > 
> > > If we want to make it change the conf during upgrade, we probably want to
> > > also ask the user again, to prevent unintended overwriting of manual changes.
> > 
> > We should not overwrite manual changes. I'm not sure the code to only change
> > this settings is worth it - we can probably have a KB documenting how to
> > perform most changes manually. In any case - separate bug.
> 
> I'm not sure we can reliably say that /etc/httpd/conf.d/ssl.conf was
> manually changed, so we may overwrite custom changes even for new
> installations (although it's not too much probable).

Indeed, but for new installations we ask:

    Setup can configure apache to use SSL using a certificate issued from the internal CA.
    Do you wish Setup to configure that, or prefer to perform that manually? (@VALUES@) [@DEFAULT@]:

> 
> So for new installation I'd always change SSLProtocols (as current patch
> does) and for updates/upgrades I would just print a warning that ssl.conf
> should be updated not to allow unsecure protocols and show our suggested
> configuration "SSLProtocols all -SSLv3 -TLSv1".

Users might not notice the warning. If that's enough, fine.

Comment 11 Jiri Belka 2017-04-05 08:30:12 UTC
ok, ovirt-engine-setup-4.1.1.7-0.1.el7.noarch

- upgrade, it doesn't change current settings (eg. SSLProtocol all -SSLv2)
- new deployment, SSLProtocol all -SSLv3 -TLSv1

tested with FF and IE11


Note You need to log in before you can comment on or make changes to this bug.