A have a question: Does this attacks works if we use mutual SSL Client Authentication with a cert in the Browser ?

Sylvain

Frank Breedijk :
Thanks for your comment, I have two questions.

I understood from your paper that client and server can initiate a renegoiation at any time, however all your examples revolve around a server initiated reneg. Why is this?

Because that’s the first case I got working. I agree, it is unfortunate that our document spends a bit too much time on the client cert case, but we had very little time to update it before going public.

It is a very important case, however.

Frank Breedijk :
Does eliminating server renegotiation elemitate the problem?

Eliminating all renegotiation does solve the problem, some sites may be able to turn it off entirely (OpenSSL has patches for that already).

Very little client-initiated renegotiation is needed, probably none for https, so that will be relatively easy to patch.

Many https servers will be able disable server-initiated renegotiation.
A minority, but significant, number of https apps depend on it.

Really, the best solution is for everyone to patch with the new TLS protocol extension header as soon as it becomes available. This patch will drop in the missing bit of crypto needed to make renegotiation safe.

Frank Breedijk :
When you say that M can forward C’s cerdentials to another server this seems to indicate the the attack can compromise the confidentiality of C’s request. If I understand correctly in order for C to send the request it has to have receive a valid server key exchange, which includes the server certificate and a server hello done, thus placing the request in the C-S cipher context.

Good question. You’re right, C will only send the http request after he checks the server certificate. However, due to an artifact of the design of TLS, client cert and smart card credentials have to be presented _before_ he has a chance to fully check the server’s credentials.
Servers will execute M’s evil request as soon as they receive the client cert/smart card credentials.

Frank Breedijk :
Thanks for your reaction.

Any time. I need all the help I can get to get the word out that everyone needs to update as soon as patches are available. People should also expect their browsers to inform them when they are connecting to an unpatched server.

- Marsh

I understood from your paper that client and server can initiate a renegoiation at any time, however all your examples revolve around a server initiated reneg. Why is this? Does eliminating server renegotiation elemitate the problem?

When you say that M can forward C’s cerdentials to another server this seems to indicate the the attack can compromise the confidentiality of C’s request. If I understand correctly in order for C to send the request it has to have receive a valid server key exchange, which includes the server certificate and a server hello done, thus placing the request in the C-S cipher context.

Thanks for your reaction.

“works by intercepting and forwarding the first client hello message sent by the client (C) to the server (S) and then negotiating the cipher between the Man in the Middle (M) and the server only.”

Actually, M doesn’t have to use an exact copy of the client’s hello, it just has to be reasonably similar. Some servers are stricter than others, but even if they were all perfectly strict, M could make his match perfectly if he wanted to. Actual clients show some variation in client hellos even over the same connection.

The “Reply to evil request” in your diagram is specifically a TLS “Hello Request”, indicating the server wants to renegotiate. Actually, even this is optional on some servers, some allow the client (i.e., mitm) to conduct an unsolicited renegotiation!

Also, M needn’t allow the server’s “Finished” message to make it all the way back to the client. In these cases, M can forward C’s credentials to another server and C (if it’s a browser) never even shows the scary page.