Description of problem: There is a natural request to support only selected SSL cipher suites in qpid broker. As nss libraries (that qpid uses) does not offer this setting and also other products (like DirectoryServer,httpd or so) have their own configuration option(s) for this, it makes sense to have this feature in qpid and not in nss. Based on the NSS API that might affect the broker options to be implemented, either broker option should be available: disable-ssl-cipher-suite=<comma_sepparated_list> enable-ssl-cipher-suite=<comma_sepparated_list> disable (resp. enable) option would work as blacklist (resp. whitelist). Version-Release number of selected component (if applicable): qpid-cpp 0.22-49 How reproducible: n.a. Steps to Reproduce: n.a. Actual results: No way to limit qpid broker what SSL cipher suites it accepts or not. Expected results: Have a way doing so. Additional info:
Disabling SSLv3 is done via bz1153757. As SSLv3 and v2 are not recommended to be enabled at all, and there is no reason to filter TLS versions, there is no use case for this feature request.
There are definitely reasons to restrict ciphers even with TLS. BEAST affected TLS 1.0. More recently, there's the "Bar Mitzvah" RC4 issue. Based on the latter, at least, I think this has to be viewed as a security vulnerability...
(In reply to Matthew Edmonds from comment #9) > There are definitely reasons to restrict ciphers even with TLS. BEAST > affected TLS 1.0. More recently, there's the "Bar Mitzvah" RC4 issue. Based > on the latter, at least, I think this has to be viewed as a security > vulnerability... Hi Matthew, this would not be considered a security vulnerability but rather a hardening measure. This bug is filed simply to implement the functionality of enabling/disabling certain cipher suites. Disabling TLS 1.0 may not be an option for legacy application so forcing this onto every user is not the desired action. Implementing the ability to choose which cipher suites should be enabled/disabled gives you the option to support whichever ciphter suites you require.
How can this be considered purely hardening? As you said, disabling TLS 1.0 can't be forced on every user (which is one reason I haven't suggested that... and there is no currently supported way to do that, is there?). Disabling all the RC4 cipher suites for every user is also unacceptable (and to my knowledge has not been suggested). So the only alternative solution for Bar Mitzvah is to allow users to specify which cipher suites they'll allow, which is this defect. If that's the only way to resolve the Bar Mitzvah RC4 issue, then this has to be tracked as a security issue, not just hardening.
TLS 1.0 has known vulnerabilities. When will we get a mechanism to turn control protocols and ciphers like apache?