Bug 1154687

Summary: POODLE: force using safe ciphers (non-SSLv3) in IPA client and server
Product: Red Hat Enterprise Linux 6 Reporter: Andrew Dingman <adingman>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.5CC: djasa, gparente, hkario, jcholast, jdennis, ksiddiqu, ldelouw, mkosek, perobins, pvoborni, rcritten, szidek
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: ipa-3.0.0-46.el6 Doc Type: Bug Fix
Doc Text:
When IdM servers were configured to require the TLS protocol version 1.1 (TLSv1.1) or later in the httpd server, the ipa utility failed. With this update, running ipa works as expected with TLSv1.1 or later.
Story Points: ---
Clone Of:
: 1156466 (view as bug list) Environment:
Last Closed: 2015-07-22 07:38:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1153739, 1154776, 1166316, 1171848    
Bug Blocks: 1057564, 1156466    

Description Andrew Dingman 2014-10-20 14:17:40 UTC
Description of problem: When the IPA servers in an infrastructure are configured to require TLS 1.1 or higher in httpd, the 'ipa' command-line tool fails.


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


How reproducible: Always


Steps to Reproduce:
1. Install IPA
2. Run "ipa user-show admin" to confirm functionality
3. Edit /etc/httpd/conf.d/nss.conf to require TLS 1.1 or 1.2 only
4. attempt "ipa user-show admin" or any other ipa subcommand.

Actual results: The ipa command fails to contact the servers


Expected results: The ipa command operates normally


Additional info: A testbed reproducer is being built in Amazon EC2. I'm happy to clone the testbed and share AMI with anyone working on the bug.

Comment 3 Andrew Dingman 2014-10-20 14:25:02 UTC
I added the link to 1057564 at hkario's request. I also believe this may be related to bug 1146905.

Comment 4 Rob Crittenden 2014-10-20 15:10:34 UTC
mod_nss upstream just added support for TLS 1.2 three days ago so I'm surprised you were even able to start Apache with this configured.

If you add -vv to ipa you'll get a more specific error. I'm seeing this against an upstream master build on Fedora 20:

$ ipa -vv user-show admin
<ship>
ipa: ERROR: cannot connect to 'https://ipa.example.comcom/ipa/json': (SSL_ERROR_PROTOCOL_VERSION_ALERT) Peer reports incompatible or unsupported protocol version.

So it appears the client isn't enabling TLS v1.1. I don't see the updated TLS range protocol in python-nss, SSL_VersionRangeSet, and I think that is the only way to enable > TLS 1.0 support in NSS.

Here is what ssltap spits out:

Connected to grindle.greyoak.com:443
Read EOF on Client socket. [Mon Oct 20 11:01:04 2014]
Read EOF on Server socket. [Mon Oct 20 11:01:04 2014]
Connection 6 Complete [Mon Oct 20 11:01:04 2014]
Connection #7 [Mon Oct 20 11:05:33 2014]
Connected to grindle.greyoak.com:443
--> [
(105 bytes of 100)
SSLRecord { [Mon Oct 20 11:05:33 2014]
   0: 16 03 01 00  64                                     | ....d
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 100 (0x64)
   handshake {
   0: 01 00 00 60                                         | ...`
      type = 1 (client_hello)
      length = 96 (0x000060)
         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
   0: 3f 58 98 2c  ad b2 c3 16  41 c0 84 f2  53 98 77 a6  | ?X.,....A...S.w.
  10: ed 66 b1 3f  12 4e db d6  76 f0 4b 40  cc 59 08 50  | .f.?.N..v.K@.Y.P
            session ID = {
                length = 0
                contents = {...}
            }
            cipher_suites[11] = {
                (0x0033) TLS/DHE-RSA/AES128-CBC/SHA
                (0x0032) TLS/DHE-DSS/AES128-CBC/SHA
                (0x0039) TLS/DHE-RSA/AES256-CBC/SHA
                (0x0038) TLS/DHE-DSS/AES256-CBC/SHA
                (0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
                (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
                (0x002f) TLS/RSA/AES128-CBC/SHA
                (0x0035) TLS/RSA/AES256-CBC/SHA
                (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
                (0x0005) SSL3/RSA/RC4-128/SHA
                (0x0004) SSL3/RSA/RC4-128/MD5
            }
            compression[1] = {
                (00) NULL
            }
            extensions[33] = {
              extension type server_name, length [24] = {
   0: 00 16 00 00  13 67 72 69  6e 64 6c 65  2e 67 72 65  | .....grindle.gre
  10: 79 6f 61 6b  2e 63 6f 6d                            | yoak.com
              }
              extension type renegotiation_info, length [1] = {
   0: 00                                                  | .
              }
            }
         }
   }
}
]
<-- [
(7 bytes of 2)
SSLRecord { [Mon Oct 20 11:05:33 2014]
   0: 15 03 02 00  02                                     | .....
   type    = 21 (alert)
   version = { 3,2 }
   length  = 2 (0x2)
   fatal: protocol_version
   0: 02 46                                               | .F
}
]
Read EOF on Server socket. [Mon Oct 20 11:05:33 2014]
Read EOF on Client socket. [Mon Oct 20 11:05:33 2014]
Connection 7 Complete [Mon Oct 20 11:05:33 2014]

Comment 5 John Dennis 2014-10-20 16:40:33 UTC
python-nss does not have support for the SSL_VersionRange* methods which appeared in NSS Version 3.14. 

I will update python-nss with support for SSL_VersionRange.

Comment 6 Andrew Dingman 2014-10-20 17:19:59 UTC
With "NSSProtocol TLSv1.1,TLSv1.2" on a set of RHEL 6.5 IPA servers, we were able to start the service, obtain Kerberos credentials, and open the web interface from Firefox on Fedora 20. I didn't check what TLS protocol version was actually negotiated, so it's entirely possible that TLSv1.2 was not in fact available. Since then, the same servers have been running with "NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2" and we have not observed any loss of functionality. This was on Friday 2014-10-17.

Comment 7 Rob Crittenden 2014-10-20 17:51:44 UTC
It appears that mod_nss ignores protocols it doesn't know as long as at least one is enabled:

[Mon Oct 20 13:49:30.094365 2014] [:warn] [pid 13698] NSSProtocol:  Unknown protocol 'tlsv1.2' not supported

With TLSv1.0 enabled the command-line client should function ok.

Comment 8 Martin Kosek 2014-10-20 18:00:36 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4653

Comment 9 John Dennis 2014-10-22 17:24:11 UTC
Please see bug #1154776. A scratch build of python-nss-0.16.0 is available which includes support for the SSL version range API.

Comment 10 Martin Kosek 2014-10-24 14:20:00 UTC
The fix should also contain any other POODLE fix.

Comment 11 John Dennis 2014-10-27 14:58:55 UTC
Please see bug #1154776. Rob asked for some additional features which were added, they are described in bug #1154776 as well as where to find a scratch build and SRPM.

Please test and report, if all looks good I'll cut a Mozilla release for python-nss 0.16.0 and then produce RPM's from that.

Comment 12 Martin Kosek 2014-11-21 09:44:41 UTC
*** Bug 1146905 has been marked as a duplicate of this bug. ***

Comment 13 Martin Kosek 2014-12-15 11:56:32 UTC
Removing RHEL-7 bug as dependency.

Comment 15 Stanislav Zidek 2015-03-27 14:49:40 UTC
There is an inconsistency in behaviour introduced by fixing this bug.

On RHEL-7.1, ipa-python-4.1.0-18.el7.x86_64, utilities like "ipa ping" support ssl protocol range (tls1.0, tls1.2), which is configured in /usr/lib/python2.7/site-packages/ipalib/constants.py.

Same configuration is on RHEL-6.7, but the protocol version range defaults to (tls1.1, tls1.2). Actually, values from constants.py are completely ignored due to the way the connection is established:

        (major, minor, micro, releaselevel, serial) = sys.version_info
        if major == 2 and minor < 7:
            conn = NSSHTTPS(host, 443, dbdir=dbdir, no_init=no_init)
        else:
            conn = NSSConnection(host, 443, dbdir=dbdir, no_init=no_init,
                                 tls_version_min=api.env.tls_version_min,
                                 tls_version_max=api.env.tls_version_max)

Since there is python version 2.6, the connection is created by NSSHTTPS, which does not take api.env.tls_version* values into account.

Comment 17 Kaleem 2015-05-13 12:45:31 UTC
Verified.

IPA version:
============
ipa-server-3.0.0-46.el6.x86_64


Snip from automation log:
=========================
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: ipaserverinstall_bz1154687: check IPA server uses safe ciphers now
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Installing IPA Server (Expected 0, got 0)
:: [   PASS   ] :: Command 'echo xxxxxxxx|kinit admin' (Expected 0, got 0)
:: [   PASS   ] :: Changing NSS Protocol to TLS1.2 (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipa restart' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipa user-show admin' (Expected 0, got 0)
:: [   PASS   ] :: Command 'sleep 2 | openssl s_client -connect 127.0.0.1:443 > /tmp/bz1154687.txt 2>&1' (Expected 0, got 0)
:: [   PASS   ] :: Command 'cat /tmp/bz1154687.txt' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/bz1154687.txt' should contain 'Protocol  : TLSv1.2' 
:: [   PASS   ] :: Changing NSS Protocol to TLS1.1 (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipa restart' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipa user-show admin' (Expected 0, got 0)
:: [   PASS   ] :: Command 'sleep 2 | openssl s_client -connect 127.0.0.1:443 > /tmp/bz1154687.txt 2>&1' (Expected 0, got 0)
:: [   PASS   ] :: Command 'cat /tmp/bz1154687.txt' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/bz1154687.txt' should contain 'Protocol  : TLSv1.1' 
:: [   PASS   ] :: Changing NSS Protocol to TLS1.0 (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipa restart' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipa user-show admin' (Expected 0, got 0)
:: [   PASS   ] :: Command 'sleep 2 | openssl s_client -connect 127.0.0.1:443 > /tmp/bz1154687.txt 2>&1' (Expected 0, got 0)
:: [   PASS   ] :: Command 'cat /tmp/bz1154687.txt' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/bz1154687.txt' should contain 'Protocol  : TLSv1' 
:: [   PASS   ] :: Changing NSS Protocol to SSLv3 (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipa restart' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ipa user-show admin > /tmp/bz1154687.txt 2>&1' (Expected 1, got 1)
:: [   PASS   ] :: Command 'cat /tmp/bz1154687.txt' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/bz1154687.txt' should contain '(SSL_ERROR_UNSUPPORTED_VERSION) Peer using unsupported version of security protocol.' 
:: [   PASS   ] :: Command 'sleep 2 | openssl s_client -connect 127.0.0.1:443 > /tmp/bz1154687.txt 2>&1' (Expected 0, got 0)
:: [   PASS   ] :: Command 'cat /tmp/bz1154687.txt' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/bz1154687.txt' should contain 'Protocol  : SSLv3' 
:: [   PASS   ] :: Restoring NSS Protocol to state before test (Expected 0, got 0)
:: [   PASS   ] :: Command 'service ipa restart' (Expected 0, got 0)
:: [   LOG    ] :: Duration: 14m 29s
:: [   LOG    ] :: Assertions: 30 good, 0 bad
:: [   PASS   ] :: RESULT: ipaserverinstall_bz1154687: check IPA server uses safe ciphers now

Comment 19 errata-xmlrpc 2015-07-22 07:38:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1462.html