[Pki-devel] [PATCH] pki-cfu-0106-Ticket-1648-RFE-provide-separate-cipher-lists-for-CS.patch

Christina Fu cfu at redhat.com
Tue Oct 20 23:55:00 UTC 2015


Thank you!  I was thinking just that.

Pushed to master:
commit 562a49f08df2adb1a3f233a9b7490575182ece04

Christina
On 10/20/2015 04:41 PM, John Magne wrote:
> Looks good. And I hear it is tested to work.
>
>
> Just one thing.
>
> There is a bunch of cipher mapping code in there which I believe is already in tomcatjss.
>
> It would be better if a future ticket is created to move all that down to JSS so both of those
> can make use of it and not copy it.
>
>
> ACK
>
> ----- Original Message -----
> From: "Christina Fu" <cfu at redhat.com>
> To: "pki-devel" <pki-devel at redhat.com>
> Sent: Tuesday, October 20, 2015 3:41:38 PM
> Subject: [Pki-devel] [PATCH]	pki-cfu-0106-Ticket-1648-RFE-provide-separate-cipher-lists-for-CS.patch
>
> Please review.
>
> https://fedorahosted.org/pki/ticket/1648 [RFE] provide separate cipher
> lists for CS instances acting as client and server
>
> 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>
>
> thanks,
> Christina
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel




More information about the Pki-devel mailing list