From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Description of problem: Qualsys scan report: Vulnerability: Netscape/OpenSSL Cipher Forcing Bug Qualys ID : 38284 Port : 443 Diagnosis: Netscape's SSLv3 implementation had a bug where if a SSLv3 connection is initially established, the first available cipher is used. If a session is resumed, a different cipher may be chosen if it appears in the passed cipher list before the session's current cipher. This bug can be used to change ciphers on the server. OpenSSL contains this bug if the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option is enabled during runtime. This option was introduced for compatibility reasons. The problem arises when different applications using OpenSSL's libssl library enable all compatibility options including SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, thus enabling the bug. Consequences: A malicious legitimate client can enforce a ciphersuite not supported by the server to be used for a session between the client and the server. This can result in disclosure of sensitive information. Solution: This problem can be fixed by disabling the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option from the options list of OpenSSL's libssl library. This can be done by replacing the SSL_OP_ALL definition in the openssl/ssl.h file with the following line: #define SSL_OP_ALL (0x00000FFFL^SSL OP NETSCAPE REUSE CIPHER CHANGE BUG) The library and all programs using this library need to be recompiled to ensure that the correct OpenSSL library is used during linking. Version-Release number of selected component (if applicable): openssl-0.9.7a-43.4 How reproducible: Always Steps to Reproduce: Use Qualsys scanner to connect to Apache with SSL enabled. Actual Results: Report shown above. Expected Results: Error/warning should not appear. Additional info: openssl-0.9.7a-43.4.src.rpm does not have the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG flag excluded from SSL_OP_ALL. Further down in our bug, Charlie Brady noted: [...] Looks like nobody knows why that compat code is there: http://www.mail-archive.com/openssl-dev@openssl.org/msg18059.html Also looks like the bug which is asserted to exist does exist - the client can switch to null cipher on reconnect. [...] Proposed patch to follow.
Created attachment 122248 [details] Patch to remove 'workaround' from OP_ALL. Here's a diff implementing the proposed fix.
We don't believe this is actually a security issue, here is why: Here is the original report of this issue: www.mail-archive.com/openssl-dev/msg18047.html Leads to further mails in the thread, including: www.mail-archive.com/openssl-dev/msg18056.html This mail shows that the original reporter made a mistake in his report and the bypass of ciphers was in fact only allowed after a handshake including the master key from the original connection - as is expected behaviour. This therefore has no security consequences, and the vulnerability scanner is showing a false positive. The customer should report this to Qualsys as a false positive.
Actually re-reading the Qualsys report it seems they were not reporting the possibility of a session reuse attack (which was disproved above), but in fact that you'd be allowed to drop to a null cipher on the resume. This is what is expected according to http://www2.psy.uq.edu.au/~ftp/Crypto/ssleay/vendor-bugs.html "SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, when set, will cause the server side of SSLeay's SSL to attempt to drop down to either a NULL encryption cipher or an export cipher. Netscape clients do not always update the key when the reused session is weaker than the initial connection."
This problem will be resolved in the next release of Red Hat Enterprise Linux. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.
Your analysis sounds fine to me, except for this part of the original report: [...] Consequences: A malicious legitimate client can enforce a ciphersuite not supported by the server to be used for a session between the client and the server. [...] If you can change to another cipher supported by both the server and client, there's no issue. But if you can change to a cipher which is in the supported_by_client list but not in the supported_by_server list, that would be a concern. Should this be CLOSED - WONTFIX (or NOTABUG), rather than CLOSED - NEXTRELEASE?
Apologies - I did not mean to change this to NOTABUG (and didn't realise I could).
Well as I think Netscape clients which require setting this SSL_OP are no longer generally used it should be OK to remove this from SSL_OP_ALL for the next RHEL release. However it is not worth fixing (could theoretically break existing working configurations) for current RHEL releases.
OK - just clarifying that your intention is to fix at some stage in the future. We'll decide whether we want to patch ahead of you. Thanks everyone for the quick turnaround.
This bug still appears to be open and it is affecting our Qualys scans. Is there any intention to fix this?
Sorry - my mistake. Please ignore comment #10 in respect to comment #5. If we were to roll our own RPM to fix this, do you foresee any issues or unwanted side effects?
You would break compatibility with very old broken Netscape clients but I don't think they are generally used anymore.
I see that this is addressed in RHEL5: openssl-0.9.8b/include/openssl/ssl.h:#define SSL_OP_ALL 0x00000FF7L /* without SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG */ ... * Thu Dec 15 2005 Tomas Mraz <tmraz> 0.9.8a-5 - don't include SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG in SSL_OP_ALL (#175779) ...
> The primary objectives of update releases are to enable new hardware > platform support and to resolve critical defects. Is not a possible attack on SSL encryption a 'critical defect'?