On 31.03.2010 14:26, Eddy Nigg wrote:
[ Please follow up to mozilla.dev.tech.crypto ]
After some discussion at bug 554594 I'm following up here - the bug was
unfortunately misused by me a little for the initial discussion.
At https://wiki.mozilla.org/Security:Renegotiation under item 4.4 the
following is proposed:
security.ssl.require_safe_negotiation
If set to true, a Mozilla client will reject *all* connection
attempts to servers that are still using the old SSL/TLS protocol
and which might be vulnerable to the attack.
I believe this to be a mistake for various reasons, but first and
foremost because an attack on a server without compromise of the client
data as well, is basically useless. When a attacker induces
renegotiation at the server, the attacker must have client credentials
in order to act as if he were the original client. Without those
credentials, the attacker would be treated as any other unauthenticated
source.
The attack that made it necessary to develop RFC 5746 is difficult to
understand.
The attacker doesn't need to know the credentials of the user.
It's sufficient that the user's credentials will be sent by the client,
after the renegotiation between MITM and server happened.
The client will see it as an initial negotiation, it will encrypt the
data, readable for the server only, not readable by the attacker. The
attacker will pass through all unreadable encrypted data.
On the server side, a request from the attacker will be combined with
the credentials sent by the client.
It's explained here:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
I'm quoting the relevant example from above document:
====== snip quote begin ======
E.g., the attacker would send:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This:
And leave the last line empty without a carriage return line feed. Then
when the client makes his own request
GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie
the two requests get glued together into:
GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1
Cookie: victimscookie
And the server uses the victim's account to send a pizza to the attacker.
======= snip quote end =======
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.
It doesn't help if the client is the only side supporting RFC 5746.
Imagine the transition from USB 2.0 to USB 3.0, where the plug remains
compatible, but the inner parts of the USB 3.0 plug introduces new
connectors.
If the client uses USB 3.0 and supports additional information, but the
server still uses the older USB 2.0 plug, it won't help anyone. The data
designed to be exchanged using the new USB 3.0 connectors can't flow.
In other words, the parties are unable to exchange information that
would help them to discover that a renegotiation from an unrelated party
(a MITM) was requested.
RFC 5746 requires a communication channel where both parties can speak
the protocol.
Any renegotiation attempt to the client will be ignored and no data is
leaked.
Even if the client rejects all incoming requests for renegotiation, the
client has already sent out its credentials as part of a HTTP/SSL
request. Yes, the credentials are not being directly leaked to the
attacker, but that's not necessary.
The credentials will be combined with an arbitrary request chosen by the
attacker, as illustrated above.
Effectively, the attacker can execute a request on behalf of the user,
without needing to know the user's credentials.
Kai
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
