#1648 [RFE] provide separate cipher lists for CS instances acting as client and server
Closed: Fixed None Opened 8 years ago by cfu.

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.


Per CS/DS meeting of 10/19/2015: 10.3 - critical

From IRC conversation of 10/20/2015: 10.3 - critical

pushed to master:
commit 562a49f08df2adb1a3f233a9b7490575182ece04

This patch allows the administrator to specify an allowed list of ssl ciphers for subsystem->subsystem communication that is separate from the server one in server.xml

Note:

  • it is only meant for cs subsystem->subsystem communication; i.e.. ca->kra, tps->ca, tps->kra, tps->tks (e.g. not for connection to the ldap server, internal, publishing, or authentication)
  • the clientCiphers configuration is a "strict" list, meaning, only the ciphers in the comma separated list are enabled in the connection when acting as a client
  • if the clientCiphers configuration parameter is undefined, default action is taken to enable all available ciphers provided (that means it works as it did prior to this patch)
  • pki-core and pki-util packages are expected to be updated together for
    the newly added clientCiphers String parameter in various affected connection
    interfaces; since it is handled in a way that if this parameter is null, it
    goes to default, as they are expected to be internal to cs subsystems

How to test (what I have tested):

  • turn on a couple ECDH_RSA_* ciphers on the server side for CA and KRA:
    • edit <ca instance dir>/conf/server.xml, search for sslRangeCiphers, and turn '-' to '+' for, say,
      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    • restart ca
    • repeat for kra
    • expect browser to connect to ca and kra with the TLS_ECDHE_RSA_* ciphers that are turned on
    • verify using ssltap or any tool that can catch and report from an ssl session
  • turn on client side cihpers in the ca for talking to the kra:
    • edit <ca instance dir>/ca/conf/CS.cfg, add a list of ciphers WITHOUT the TLS_ECDHE_* ciphers, e.g.

ca.connector.KRA.clientCiphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
- expect ca to connect to kra using the ciphers allowed in the clientCiphers list by doing an enrollment with archival
- verify using ssltap or any tool that can catch and report from an ssl session

  • perform the same test between tps and other subsystems.
    tps.connector.<ca id>.clientCiphers=< your selected cipher list>
    tps.connector.<kra id>.clientCiphers=< your selected cipher list>
    tps.connector.<tks id>.clientCiphers=< your selected cipher list>

Metadata Update from @cfu:
- Issue assigned to cfu
- Issue set to the milestone: 10.3.0

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2207

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata