Red Hat Bugzilla – Bug 175779
Qualsys scan: Netscape/OpenSSL Cipher Forcing Bug
Last modified: 2009-03-26 13:38:41 EDT
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
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
OpenSSL contains this bug if the
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option is
runtime. This option was introduced for compatibility
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
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.
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:
(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):
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.
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:
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:
Leads to further mails in the thread, including:
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
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
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
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 <firstname.lastname@example.org> 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'?