On 2010-04-03 04:29 PST, Eddy Nigg wrote:
> On 04/03/2010 01:07 PM, Nelson B Bolyard:
>> 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.
>
> I can see how this can work in cases where all other data to be
> exploited can be prepend by the attacker. Still, those are probably very
> rare and unfortunate circumstances, it mustn't happen.
Let me tell you about one very simple attack. (I think this is old enough
now that the details are no longer big news in the hacking community.) The
MITM has an account on an SMTP server on the same host as an https server.
The SMTP server and the https server on that host use the same server
certificate. The attacker arranges to intercept the victim client's https
requests and connect them to the email server (!). The attacker first
connects to the email server and sends it a set of info that looks like it's
starting to send an email. He sends all the email headers, so that it
appears to be sending an email to himself, and is simply awaiting the
message body. Then he starts the renegotiation as seen by the server, and
splices in the connection from the victim client. The victim client
connects to the MITM, thinking that it is connecting to the https server,
and sends its https request, with its usual https request cookie by which it
authenticates itself to the https server. But this information is going into
the body of an email to be mailed to the attacker. The attacker receives
the email, takes the cookies out of it, and then impersonates the victim to
the https server.
This has been exploited more than once. Yes there are some tricks. Email
message bodies are supposed to end with a line that start with a "." and
contains only that ".". This can be arranged. I won't explain how.
There are other methods. An in house attacker can get a corporate expense
check issued to himself just by having someone else who is authorized to
issue such checks to merely login. ("What do you mean "The check you
requested has been issued"? What check? I just logged in?!?!?") That's
been exploited too.
>> Now, the way that a [client] 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 later in the handshake will prove that this
>> is true] 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.
>
> Now I have a question I wanted to ask for a long time. Considering that
> this design flaw existed for some 14 years and more...how come nobody
> ever thought about this earlier? Isn't it amazing that such a fairly
> trivial exploit existed for such a long time? Yourself know the SSL
> protocols in and out and never thought about it?
It's not so trivial. What the MITM must do to arrange this handshake that
appears to the server to be a renegotiation but to the client to be a first
negotiation is quite involved. No one ever though of it until last year,
apparently. It seems to have eluded the entire TLS working group until
last year. I did wonder about this once or twice over 13 years, but didn't
see any way to exploit it and so I thought it was safe. Someone finally
found a way. Thank goodness Marsh Ray wears a white hat!
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
