Bug 1084224

I should probably add that the dogtag pki-user member reported that he was using the following:
pki-ca v9.0.3-32 with FreeIPA v3.0.0.-37 on a CentOS 6.5 machine

Please provide steps to test and verify this

I'm the one that reported this issue. Steps to reproduce from RH documentation :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html-single/Deploy_and_Install_Guide/index.html
 
1. Scan the administration interfaces with sslscan and check that it uses weak ciphers (RC4 & MD5; SSLv2...)

2. Edit /var/lib/pki-ca/conf/server.xml and edit the proper connector : 
<Connector name="Agent" port="9443" maxHttpHeaderSize="8192"
        ...
        ...
        sslOptions="ssl2=false,ssl3=false,tls=true"
        strictCiphers="true"
        ...
>
3. Enable FIPS mode in the NSS software database.
modutil -dbdir /var/lib/pki-ca/alias -fips true

4. Verify that FIPS mode has been enabled. The command will return the current FIPS status.
modutil -dbdir /var/lib/pki-ca/alias modutil -dbdir . -chkfips true 
FIPS mode enabled.

5. Start the daemon.

6. Run sslscan to check the ciphers available and see that nothing has changed.

Created attachment 909318 [details]
patch providing strictCiphers implementation

This patch provides the missing implementation for strictCiphers.

Note:
In process, I found 
1. server.xml ciphers in pki-core out of date
2. server.xml has "tls3Ciphers" while tomcatjss in conformance with other versions has "tlsCiphers".  In this patch, I use "tls3Ciphers" so it won't break.

Created attachment 909320 [details]
spec file with related changes

(In reply to Christina Fu from comment #7)
> Created attachment 909320 [details]
> spec file with related changes

Change:
    Buzilla 1084224
To:
    Bugzilla Bug #1084224

ACK

Comment on attachment 909320 [details]
spec file with related changes

Change:
    Buzilla 1084224
To:
    Bugzilla Bug #1084224

ACK

Comment on attachment 909318 [details]
patch providing strictCiphers implementation

Approving this, with a few observations.

1. In the code that clears out the ciphers, we swallow an "Exception" even though the method is declared to throw a "SocketException". I think that possibly we can get rid of the try catch block and just let the thing throw.

2. In the final block of changes in the patch, there the boolean isStrictCiperhs is checked twice. If we wanted, we could consolidate the code into one block checking for this.

Due to the fact that this patch is across many version, we might defer this cleanup to a later upstream release.

QE:
for comment #4 procedure, for step 6, I'm not familiar with "sslscan".  I personally use ssltap.

checked into IPA_v2_RHEL_6_ERRATA_BRANCH/tomcatjss

$ svn commit tomcatjss.spec patches/tomcatjss-strict-ciphers.patch
Adding         patches/tomcatjss-strict-ciphers.patch
Sending        tomcatjss.spec
Transmitting file data ..
Committed revision 278.

Reproduced the bug on tomcatjss-2.1.0-2.el6 as follows:

1. Ran ssltap -sfxl localhost:9445 and got the following line in the output on going to url https://localhost.localdomain:1924

   cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA

2. Modified /var/lib/pki-ca/conf/server.xml file as explained in Step 2 of comment 4 and restart the service.

3. Ran ssltap -sfxl localhost:9445 and got the following line in the output  on going to url https://localhost.localdomain:1924

   cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA

   The value was unchanged

Verifying the fix in the build tomcatjss-2.1.0-3.el6


1. Ran ssltap -sfxl localhost:9445 and got the following line in the output on going to url https://localhost.localdomain:1924

   cipher_suite = (0x002f) TLS/RSA/AES128-CBC/SHA

2. Modified /var/lib/pki-ca/conf/server.xml file as explained in Step 2 of comment 4 and restart the service.

3. Ran ssltap -sfxl localhost:9445 and got the following line in the output on going to url https://localhost.localdomain:1924

   cipher_suite = (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA

   The value of the parameter was changed.

Is this the way to verify the bug? In step 2 of comment 4 we are setting SSL2 and SSL3 to false but with the latest tomcatjss build we get cipher_suite = (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA in the output of ssltap, could you explain?

(In reply to Roshni from comment #14)
> 
> <snip>
> Is this the way to verify the bug? In step 2 of comment 4 we are setting
> SSL2 and SSL3 to false but with the latest tomcatjss build we get
> cipher_suite = (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA in the output of
> ssltap, could you explain?

Which ciphers the server allows depends on your server.xml configuration.  Since you turned off ssl2 and ssl3 that leaves tls.  You need to look at what tls3Ciphers is defined in your server.xml. It should have a list of ciphers that the administrators wish to offer.  If you don't want to offer any cipher, you take it off the list.
Which cipher the server chooses in the end depends on what the client says it is capable of handling.  As long as there is at least one match between the client's cipher list and the server the ssl connection should happen.

So, if your result was (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA, check your tls3Ciphers, you probably has that in the list.
We should have another bug to clean up that list on that particular version of Dogtag.  But in the mean while, you can just copy the proper list from the RHCS8.1 server.xml.  Note, you are to look for "tlsCiphers" in the RHCS8.1 server.xml, as I explained in comment#6, somehow the name is different.

Verified on tomcatjss-2.1.0-3.el6 by testing as explained in comment 14.

The result obtained for cipher_suite parameter is from the list that was enabled (tls3Ciphers)

This is to answer Roshni's question from irc on how to test the "strictCiphers" feature in general.
The feature is to allow the tomcat server to restrict SSL ciphers to the selected ones.
Once you followed the instruction to turn on "strictCiphers" and turn off ssl2 and ssl3, you can decide on which ciphers you want to keep in the tls3Ciphers (or tlsCiphers in other versions of tomcatjss).

A sure way to test if this feature is in place and function is to 
1. run ssltap and hit the server with the same client (I used Firefox to hit the CA ee port) to see which cipher gets picked up consistently.  Note that down.
2. save a copy of the server.xml, edit the main copy tls3Ciphers (or tlsCiphers, whichever you find in the server.xml) by changing '+' to '-' the cipher that got picked from step 1.  I would then proceed to change '+' to '-' for every other one except for one single cipher.
3. restart the server, the single one that's left should be the one that's picked.

For example, my tlsCiphers had the following values
tlsCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

I observed that in ssltap, the one that consistently gets picked was:

            cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA

so I changed my tlsCiphers to contain only one '+' which is NOT the one above:
 tlsCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,-TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,-TLS_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_DSS_WITH_AES_128_CBC_SHA,-TLS_DHE_DSS_WITH_AES_256_CBC_SHA,-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_RSA_WITH_AES_128_CBC_SHA,-TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

Now I observe the new ssl session was done with the cipher that I picked:
            cipher_suite = (0x002f) TLS/RSA/AES128-CBC/SHA

If you really want to be sure, you can try a few more times with different cipher.  As long as you pick RSA cipher for the RSA session, and the correct ECC cipher for the ECC session offered by the underlying PKCS#11 module then it should work.

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.

http://rhn.redhat.com/errata/RHBA-2014-1550.html