On 2010-04-02 14:06 PST, Eddy Nigg wrote: > Hi Bob, > > On 04/02/2010 01:34 AM, Robert Relyea: >>> When a client (as in our case Firefox) implements RFC 5746, the >>> client can't be compromised and no data is leaked from the client. I >>> propose that Firefox should support the RFC 5746 extension >>> exclusively, but NOT block or warn on accessing servers which don't >>> support the extension. Any renegotiation attempt to the client will >>> be ignored and no data is leaked. >> >> Not true. Any client can be compromised as long as it accepts >> connections with servers that do not understand RFC 5746. A client >> that does SSL3 or TLS and *NEVER* renegotiates can be vulnerable. > > I don't have the intention to continue the argument because I've > received already some answers which addressed part of my concerns. But > for the better understanding I'd be interested to know how a client that > doesn't renegotiate can be vulnerable. Are you saying that the client > can leak data without renegotiation?
Yes, Eddy. Any client that completes just a first handshake (not a renegotiation, just a first handshake) with a vulnerable server becomes vulnerable itself. The client becomes vulnerable by virtue of dealing with the vulnerable server. It's a real threat, demonstrable. It has been actually exploited. The ONLY way for a client to protect itself from this vulnerability, when dealing with a vulnerable server is to detect, early in the client's first handshake, that the server is vulnerable, and then NOT complete the first handshake because of that. If the client detects the server's vulnerability, but goes ahead and completes the handshake, the damage is done. Believe it. This is true because the attacker can arrange it so that the victim client's first handshake is actually a renegotiation for the server. It's NOT a renegotiation for the client, but it IS for the server. The server has previously negotiated with the attacker, and thinks that it is renegotiating with the attacker, but is actually doing a negotiation with the victim client. To the server it looks like a renegotiation. To the victim client, it looks EXACTLY like a first handshake, not a renegotiation. Whatever credentials the victim client provides in its initial request (client auth, or a cookie, or a basic auth password) will be seen by the vulnerable server as having come from the attacker, because the server thinks it's renegotiating with the attacker. That's how the attack works, and how the attacker uses the victims credentials. Now, the way that a protects itself from a server's vulnerability is that, in the client hello message, it asks the server "are you fixed"? A Fixed server will answer affirmatively in its server hello message, and an unfixed old server will ignore the request. When the client gets back the server's hello message, if it doesn't contain the extension that says "yes, I'm fixed", the client should drop that handshake right then and there, like a hot potato. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
