The HTTPS TLS cipher suite on our dogtag 10.2.6 servers appear much weaker than previous versions. I took a look at a server running 10.2.3 and the selected cipher suite is much stronger, supporting forward secrecy (PFS). I built out a dogtag 10.2.6 system using default values and it still uses the same weaker suite and lacking PFS support.
10.2.3 host: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS 1.2 (with PFS) 10.2.5 host: TLS_RSA_WITH_AES_128_CBC_SHA 128 TLS 1.2 (no PFS)
It looks like at some point the cipher selection was altered. I spotted this using the Firefox 'Calomel' plugin, which is very good at rating the strength of TLS connections. Dogtag 10.2.6 receives a score of 56%, whereas dogtag 10.2.3 receives a 100%.
Good catch! My investigation shows that by default, since early releases, all TLS ciphers are turned on, banking on that during SSL handshake the strongest cipher will be picked. However, during the last release, Ticket 1438 (pkispawn: SSL_ForceHandshake issue for non-CA on HSM on both shared and nonshared tomcat instances), it was decided that we duplicate the cipher list and separate them out to RSA and ECC and flip the '+' and '-' accordingly during installation. Apparently, those stronger RSA ciphers (TLS_ECDSA_RSA_*) got mistakenly flipped on in the ECC section, while off in the RSA sections. I'm proposing that we do a safer default 1. of course, fix the mistake by flipping the RSA ciphers over to the correct side 2. turn off the weak ciphers by default (if weaker clients must be supported, site admins can manually configure it in the server.xml)
It will be discussed whether the following are needed 1. remove the RSA cipher that is left on in the ECC section to handle installation 2. migration support
Note: The reported issue has a work around: Edit <instance>/server.xml to turn on the TLS_ECDSA_RSA_* ciphers under sslRangeCiphers
Replying to [comment:1 cfu]:
Good catch! My investigation shows that by default, since early releases, all TLS ciphers are turned on, banking on that during SSL handshake the strongest cipher will be picked. However, during the last release, Ticket 1438 (pkispawn: SSL_ForceHandshake issue for non-CA on HSM on both shared and nonshared tomcat instances), it was decided that we duplicate the cipher list and separate them out to RSA and ECC and flip the '+' and '-' accordingly during installation. Apparently, those stronger RSA ciphers (TLS_ECDSA_RSA_*) got mistakenly flipped on in the ECC section, while off in the RSA sections. I'm proposing that we do a safer default 1. of course, fix the mistake by flipping the RSA ciphers over to the correct side 2. turn off the weak ciphers by default (if weaker clients must be supported, site admins can manually configure it in the server.xml) It will be discussed whether the following are needed 1. remove the RSA cipher that is left on in the ECC section to handle installation 2. migration support
It was determined during IRC conversations that step (1) was NTH, and therefore a separate ticket (see PKI TRAC Ticket #1561 - Remove temporary RSA ciphers after ECC instance installation/configuration) would be filed for this in the 10.3 timeframe.
Step (2), however, was deemed required by 10.2.6, and will consequently be a part of this ticket.
pushed to DOGTAG_10_2_BRANCH (for later cherry picking), as planned
commit 67c895851781d69343979cbcff138184803880ea Author: Christina Fu cfu@redhat.com Date: Fri Aug 14 19:57:15 2015 +0200
Ticket #1556 Weak HTTPS TLS ciphers This patch fixes the RSA ciphers that were mistakenly turned on under ECC section, and off under RSA section. A few adjustments have also been made based on Bob Relyea's feedback. A new file, <instance>/conf/ciphers.info was also created to 1. provide info on the ciphers 2. provide default rsa and ecc ciphers for admins to incorporate into earlier instances (as migration script might not be ideal due to possible customization)
Metadata Update from @bja: - Issue set to the milestone: 10.2.6
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/2115
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.