Bug 1302136 - [RFE] provide separate cipher lists for CS instances acting as client and server
[RFE] provide separate cipher lists for CS instances acting as client and server
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: 7.3
Assigned To: Christina Fu
Asha Akkiangady
Tomas Capek
: FutureFeature
Depends On:
Blocks: 1373961
  Show dependency treegraph
 
Reported: 2016-01-26 17:11 EST by Matthew Harmsen
Modified: 2016-11-04 01:22 EDT (History)
4 users (show)

See Also:
Fixed In Version: pki-core-10.3.1-1.el7
Doc Type: Enhancement
Doc Text:
Separate cipher lists for instances acting as a client Prior to this feature, the cipher list specified in the `server.xml` file was used when a Certificate System instance was acting as a server as well as a client. In some cases, certain ciphers could be not desired or did not work. This update gives administrators tighter control as it allows the administrator to specify an allowed list of SSL ciphers when the server is acting as a client for communication between two Certificate System subsystems. This cipher list is separate from the one stored on the server.
Story Points: ---
Clone Of:
: 1373961 (view as bug list)
Environment:
Last Closed: 2016-11-04 01:22:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Harmsen 2016-01-26 17:11:51 EST
Currently the cipher list is specified in server.xml, and it is used when a CS instance is acting as server as well as client.
However, the issue depicted in 
https://fedorahosted.org/pki/ticket/1576 subsystem -> subsystem SSL handshake issue with TLS_ECDHE_RSA_* on Thales HSM
makes it so that CS->CS inter-subsystem communication has issues;
We should not let it affect the servers open to other clients such as browsers and cli's.

We should investigate on having the cipher lists separate for acting as server and client.
Comment 2 Mike McCune 2016-03-28 18:24:40 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 5 Christina Fu 2016-08-10 12:44:06 EDT
https://fedorahosted.org/pki/ticket/1648#comment:4
Comment 6 Roshni 2016-08-12 14:40:19 EDT
[root@nocp4 ~]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.3.3
Release     : 5.el7
Architecture: noarch
Install Date: Fri 12 Aug 2016 01:14:29 PM EDT
Group       : System Environment/Daemons
Size        : 2430595
License     : GPLv2
Signature   : RSA/SHA256, Thu 11 Aug 2016 02:01:10 AM EDT, Key ID 938a80caf21541eb
Source RPM  : pki-core-10.3.3-5.el7.src.rpm
Build Date  : Tue 09 Aug 2016 07:47:56 AM EDT
Build Host  : ppc-021.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority

Verification steps:

1. Made config changes to CA and KRA's server.xml to add the ciphers as explained in https://fedorahosted.org/pki/ticket/1648#comment:4
2. Connecting to the agent pages of CA and KRA gave the following ssltap output (ssltap -sxl hostname:<secure-port>):

handshake {
   0: 02 00 00 53                                         | ...S
      type = 2 (server_hello)
      length = 83 (0x000053)
         ServerHello {
            server_version = {3, 3}
            random = {...}
   0: 4b 30 d8 b6  e3 71 89 da  0f b5 89 06  99 c0 96 bd  | K0...q..........
  10: 32 63 77 4b  ff 45 b0 47  93 5a d1 1e  91 17 94 f6  | 2cwK.E.G.Z......
            session ID = {
                length = 32
                contents = {...}
   0: 7f 4b 14 fa  95 28 c0 f0  de 20 ab fe  7e c7 1e 4f  | K...(... ..~..O
  10: 96 96 5f d7  3b 7b 7a 31  a9 42 7d 89  1b a4 3e 3c  | .._.;{z1.B}...><
            }
            cipher_suite = (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
            compression method = (00) NULL
            extensions[11] = {
              extension type renegotiation_info, length [1] = {
   0: 00                                                  | .
              }
              extension type ec_point_formats, length [2] = {
   0: 01 00                                               | ..
              }
            }
         }

3. For testing key archival I did tps token enrollment using tpsclient. I noticed that following cipher being used with all the connectors tps-ca, tps-kra and tps-tks

handshake {
   0: 02 00 00 4d                                         | ...M
      type = 2 (server_hello)
      length = 77 (0x00004d)
         ServerHello {
            server_version = {3, 3}
            random = {...}
   0: 23 6b 9a 6f  02 73 1b 69  45 0b d1 1e  3b 6a 17 7b  | #k.o.s.iE...;j.{
  10: e4 3b 2a ec  b4 cf 11 0d  3f e6 71 96  a8 54 3d a2  | .;*.....?.q..T=.
            session ID = {
                length = 32
                contents = {...}
   0: 6c c7 a1 4a  15 d0 62 16  00 7b 19 b9  28 c0 c7 f3  | l..J..b..{..(...
  10: 13 80 d9 f2  78 05 88 f5  d3 53 3b db  2c b1 c4 c1  | ....x....S;.,...
            }
            cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA
            compression method = (00) NULL
            extensions[5] = {
              extension type renegotiation_info, length [1] = {
   0: 00                                                  | .
              }
            }

I did not make any changes to the cipherlist in CS.cfg to test this (as explained in ticket 1648). The parameter ca.connector.KRA.clientCiphers= did not exist in CS.cfg (not in TPS CS.cfg either).
Comment 8 errata-xmlrpc 2016-11-04 01:22:34 EDT
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/RHBA-2016-2396.html

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