On 09/29/2010 05:51 PM, Jordon Bedwell wrote:
On 09/29/2010 04:23 PM, Michael Gilbert wrote:
I could have sworn that renegotion in lenny's openssl was disabled.
But according to the changelog, that looks to not be the case [0].
Based on that, I agree that a DSA should be issued.
Even if renegotiation was disabled (which I briefly mentioned there was
an issue with somebody challenging it in the original ticket) you can't
seriously call that a fix more than a temporary damage control mechanism
until a permanent fix comes.
Part of what's so maddening about this bug is not that its so incredibly
hard to patch, or that there are millions of sites using renegotiation,
but that so often solutions which seem like a good idea at first turn
out to be borderline and crummy in the broader picture. And it always
takes a lot of discussion to work it out.
For example, Apple quickly disabled renegotiation, they didn't know
anybody was using it. Turns out it broke Tor, which needed it, but
didn't happen to be insecure in they way they were using it.
I think of it like this: SSL/TLS is a client-server protocol. Both
endpoints have to work together to make the channel secure. It also has
to be correctly interfaced to the application layer protocols running on
top of it.
We often have the picture in mind of the user shopping online and not
wanting to have his credit card number intercepted in transit. This
model has driven several design decisions of SSL/TLS and not always for
the better.
But really, from the protocol perspective, we have to expect that the
client and server both have a critical interest in the security of their
mutual connection. We can't assume that the client-side user is the only
endpoint with secrets to protect. The server side shouldn't leaving it
up to the client side to prevent a MitM (but PKI is a whole nother topic).
We usually swift patch things out when we
plan to work on a permanent fix, not disable a feature and call it a
fixed when there is already a solution...
Debian is usually really great. We knew that folks would disable
renegotiation and we might have trouble getting it fix it correctly
after that, since so few used it.
If Debian's users don't need renegotiation, that's fine! It doesn't need
to be turned back on! Most developers didn't know about this hidden
feature anyway. That's not really the issue.
All that we really need to move forward right now is:
When a client sends a Client Hello containing an empty "Renegotiation
Info" (RI) extension, the server replies with an empty RI extension of
his own. It's just five fixed-value bytes that the server appends to his
own Server Hello to acknowledge the client's request.
This happens on the initial handshake and all in the SSL library itself.
***** It doesn't require that renegotiation be re-enabled. *****
Neither should it require changes to the application code (except
conceivably to back out temporary patch or two).
These five bytes will mean the world to some server admin somewhere,
who's boss is questioning his judgment for installing Debian everywhere
and now users are starting to report strange warnings in their browsers.
- Marsh
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ca3e8a5.8000...@extendedsubset.com
