Bug 175779

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'?