Hi, Bob. Please see toward the end of this email for why discussing
the security of SSL/TLS itself is a red herring.
On 4/25/05, Bob Relyea <[EMAIL PROTECTED]> wrote:
> SSL 101 begins....
[excellent high-level overview of SSL handshaking snipped - may I
submit it for inclusion into the wiki?]
> Conclusions:
> 1) A MITM attack on SSL involves either attacking the authentication
> scheme (why, yes, I'm amazon.com), or attacking the master secret (see
> bleckenbauker for some active attacks which required some changes to
> many SSL implementations of the protocol). The former lets you fake one
> side (You could make the client think you were amazon, I'm not sure you
> could sit in a middle of a client auth session, though. I'd have to look
> at the protocol more closely -- I'm not so sure SSL protects against
> this case. I'll have to go back and think about this.... In practice,
> however, it doesn't matter since most sites do not use client auth,
> spoofing the server is sufficient). The latter allows you to fake both
> sides, tap both sides, and do so until one or the other changes the
> session key. Accomplishing either is a full attack on SSL (not just MITM).
Client auth messages are also part of the MAC that is sent during the
integrity phase from the client to the server. Servers that do not
authenticate are prevented from asking the client to authenticate. I
don't remember if the master key is seeded from material that the
client sends during client auth. (And TLS is generally regarded as a
superior protocol to SSL in any case.)
>
> end SSL 101....
>
[iang's quote snipped]
> This attack requires either breaking a private key from a valid signed
> certificate, or somehow learning the master secret between a client and
> server -- both of which SSL is (believed to be) strong against. If you
> can do either of these, then you have a viable attack on SSL itself, and
> even encrypted-"only" channels are completely vunerable (ones which you
> wouldn't verify the certificate).
See, we're not really discussing SSL itself -- we're discussing an
attack versus the (CA|Internet) infrastructure:
Since the client isn't asked to authenticate by most eCommerce sites
or banks, if there's an attack against the infrastructure that directs
all traffic originally destined to Chase to another site, the server
can't really easily detect if it's talking to the original browser or
to a proxy. That means that the client has to be the one doing all
the authentication, and the only way it can do that is via the DNS
name and the certificate it gets.
If the interloper can get a certificate that says he's Chase, from any
of the CAs that are embedded into the browser with the trust bit set,
he's gold.
Now, an attack of that nature is a harder (and more expensive) problem
than I would want to deal with. So what I have to do is get the user
to come to my page, and have them expect what's there. A common way
of doing this is to send spoofed emails, with a link that appears to
go one place but in actuality goes to another. (ECMAscript makes this
easier, since it can do
onMouseOver(Window.status("https://www.chase.com/";)), or whatever the
relevant code would be.)
In this case, if I send a spoofed email like that, and at least one
moron clicks on it, I have now simplified (and made MUCH less
expensive) my attempted fraud: all I have to do is have the actual URL
go to https://www.chase.com[URL-encoded
":dummypass"@sitename.example.fraud"]/[apparently-valid string], and
wait. If I can get a certificate for "sitename.example.fraud" from a
trusted CA (say, Thawte, with its new Domain-Validated SSL123
certificates), the lock icon will [currently] appear on the UI because
it's SSL-encrypted, and the session will (if I've copied Chase's look
& feel correctly) appear to be completely valid to the customer.
Remember what Bruce Schneier said? "Using strong cryptography inside
an insecure process is like putting a high-grade lock on door and
leaving the window open." [paraphrased, I don't remember the exact
quote] Most attacks aren't going to be against the cryptography
(though there have been notable exceptions), since it's expensive to
attack the SSL itself. Instead, attack the infrastructure around it
-- hack the server, or get a cert from a trusted CA that lets you do
what you want because of client behavior, or social-engineer your way
into getting the information that's of value to you.
The Firefox UI has at least one UI improvement (next to the lock icon,
it shows the authenticated site name) to the standard process that
existed before -- but it's not enough. The CA infrastructure that is
currently in place is broken beyond repair, and now we're trying to
find ways of non-invasively modifying the user experience so that the
user herself can see the details of who she's sending information
to... before she sends it.
Cordially,
Kyle Hamilton
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
