[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AF59F32.1030408@extendedsubset.com>
Date: Sat, 07 Nov 2009 10:24:18 -0600
From: Marsh Ray <marsh@...endedsubset.com>
To: rea-sec@...elabs.ru
CC: oss-security@...ts.openwall.com, tls@...f.org,
"Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: [TLS] CVE-2009-3555 for TLS renegotiation MITM
attacks
Eygene Ryabinkin wrote:
>
> Had anyone considered the scenario when the server requires client
> certificate from the beginning, but MITM possesses some other
> credentials that will be good for authentication (but can be of no use
> for authorization)? In this case MITM can use this certificate to start
> the splitting request, then initiate renegotiation and proxy client's
> request through the established channel.
Yes. I regret that we didn't get a chance to update the paper before
making it generally available, so it is a bit understated:
"Other techniques allow the attacker to forward or re-purpose client
certificate authentication credentials."
> If the second certificate is used for the authorization and it is
> allowed to have distinct certificates during the first and second
> negotiations, then this could be the other way to trigger this attack
> against the servers that are requiring certificates from the beginning.
>
> Any thoughts?
It's even worse than that. In practice, clients will sign with their
client cert without user intervention.
"For one thing, browsers' behavior of allowing automatic certificate
sending is suspect and should be reconsidered. Secondly, browsers suffer
from a fundamental inability to authenticate the specific transaction
the server is about to execute, ostensibly on behalf of the client. That
underlying problem should be addressed, and will likely involve either a
protocol change or changes in the way existing protocols are implemented.
"Finally, it may make sense to require clients to authenticate servers
using the supplied certificate before handing client certificates back
to the server. This will effectively prevent the chosen-server attack
scenarios described above. This may also represent a breaking protocol
change, however, and is being investigated.
Even worse (and this is shown in some of the packet captures), web
servers will execute MITM's request as soon as they get the Finished
message from legit client, but the browser doesn't put up the scary page
until he gets the Finished from the server (which could simply be
silently dropped by the MITM).
So if a client has useful client cert (or smart card) credentials, MITM
can redirect a request to a server of his choosing that will accept
them, use them to authenticate his arbitrary transaction, and the
browser may never even show the scary cert error page.
- Marsh
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
