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