Security team successfully cracks SSL using 200 PS3's and MD5

Mailman List Mirror (Read Only)
1

> We cannot continue to justify security failure on the basis that a
> significant percentage of the clients don't support it, or are
> broken in
> their support. That's an argument for fixing the clients.

At a more basic level, though, isn't failure guaranteed for these kind
of clients (web browsers) so long as users are conditioned to click OK/
Continue for every SSL certificate failure that is reported to them?

Yes. This is a major problem.

If I was attempting a large-scale man-in-the-middle attack, perhaps
I'd be happier to do no work and intercept 5% of sessions (those who
click OK on a certificate that is clearly bogus) than I would to do an
enormous amount of work and intercept 100% (those who would see no
warnings). And surely 5% is a massive under-estimate.

Yet I do not particularly wish to ignore the problem, just because we do
not have a completely comprehensive solution to the problem that solves
every case and prevents every mistake.

The Firefox changes to really draw attention to certificate issues is,
regardless of what people have said about "usability" and "practicality,"
an important step.

However, there's something else being highlighted here. SSL certificates
have a major failing in that it is really spectacularly annoying and
difficult for some people to acquire them, and/or the value in paying more
than a trivial sum (or any sum) is hard to justify, etc.

For example, I have absolutely no desire to pay even a modest $15/year
per device to get all my various networking devices to have legitimate
SSL certificates; instead, we run our own local CA and import our root
CA cert into browsers. It's cheaper, *more* secure, etc. Nobody but us
will be logging into our devices, and our browsers have the local root CA
added.

Now, many sites just don't see the need, and self-signed certs are
the result.

This would seem to point out some critical shortcomings in the current SSL
system; these shortcomings are not necessarily technological, but rather
social/psychological. We need the ability for Tom, Dick, or Harry to be
able to crank out a SSL cert with a minimum of fuss or cost; having to
learn the complexities of SSL is itself a "fuss" which has significantly
and negatively impacted Internet security.

Somehow, we managed to figure out how to do this with PGP and keysigning,
but it all fell apart (I can hear the "it doesn't scale" already) with SSL.

... JG

2

If we had DNSSEC, we could do away with SSL CAs entirely. The owner
of each domain or host could publish a self-signed cert in a TXT RR,
and the DNS chain of trust would be the only form of validation needed.

3

If we had DNSSEC, we could do away with SSL CAs entirely. The owner
of each domain or host could publish a self-signed cert in a TXT RR,

... or even in a CERT RR, as I heard various clever people talking about in some virtual hallway the other day. <http://www.isi.edu/in-notes/rfc2538.txt >.

and the DNS chain of trust would be the only form of validation needed.

Joe

4

perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put?

randy

5

If I can get secure answers to "www.bank.example IN CERT?" and "www.bank.example IN A?" then perhaps when I connect to www.bank.example:443 I can decide to trust the certificate presented by the server based on the trust anchor I extracted from the DNS, rather than whatever trust anchors were bundled with my browser.

That presumably would mean that the organisation responsible for bank.example could run their own CA and publish their own trust anchor, without having to buy that service from one of the traditional CA companies.

No doubt there is more to it than that. I don't know anything much about X.509.

Joe

6

x.509 is not the issue. it is your assumption that dns trust is formally transferrable to ssl/tls cert trust.

to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail.

and i am not interested in quibbling about banks and who issues root cas. the point is that there are two different trust models here, and trust is not transitive.

but then again, i have not even had coffee yet this morning.

randy

7

All you've done *there* is transfer the trust from the contractor to
the company that's the "ca for the bank". Yes, the ca-for-banks.com
has a vested interest in making sure none of its employees go rogue and
do something naughty - but so does the DNS contractor.

One could equally well argue that if a site was using the DNS for certs
would be immune to an attack on a CA.

8

Randy Bush wrote:

perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put?

randy

It wouldn't, which is why the original suggestion is a bad idea.

They're different issues (finding the actual address of the server you want to talk to vs. authenticating that the server is the server you want to talk to), and the trust doesn't transfer for multiple reasons.

Mostly it isn't a good idea because there's a big "too many eggs in one basket" problem here... compromise of the DNS root keys not only would cause address lookups to be as insecure as they are now (which still works much of the time for many people), but inserting fake self-signed certs becomes trivial.

This is nearly as bad as the argument I've seen that if we had DNSSEC we wouldn't even need SSL's authentication, because you'd be sure you were talking to the right server (never mind that there's demonstrated examples of just how easy it is to reroute someone else's packets from far away). Of course we could secure the entire routing system as well...

Matthew Kaufman

9

Because I have to trust the DNS anyway. If the DNS redirects my users
to a bad site, they may not notice that they are actually entering their
personal information into the perfectly-SSL-secured www.bankofamerca.com.

Given the willingness of some CAs (which are trusted by browsers) to
give out certs with no verification at all[1], I am not sure there is
much to be trusted in the current CA-cartel arrangement, with the
exception of EV certs. So banks can continue to use the equivalent of
EV certs, and the rest of us who don't need an extra layer of trust can
switch to using root certs in the DNS secured via DNSSEC. The trust
hierarchy is already there.

I agree that there are two different trust models, one of which I am
required to trust and the other of which I don't trust at all.

michael

[1]http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/

10

To be pedantic, it'd have to be the contractor who holds the signing
key for the bank.example zone (which may be a separate entity from
whoever has operational control of the nameservers).

You're correct that this proposal treats control of a DNS zone as a
strong proof of identity, but I'd argue that that's the case already --
whoever controls the zone can easily get a CA to issue them a cert
which is valid for the host "www.bank.example". Whether the
organization name is "Example Bancorp" or "DomainSquatters'R'Us, Inc."
is irrelevant, since nobody ever looks at that.

I'd go so far as to argue that the hostname is the proper *definition*
of identity in this context. The client identifies the destination it
wishes to connect to by hostname, not by organization name. The
purpose of the cert ought to be to ensure that we're talking to the
host identified by that hostname (according to a necessarily trusted
DNS).

Ensuring that the hostname belongs to someone the user really wants to
speak to is an orthogonal problem which is impossible to solve without
a clueful user in the loop, and at which the current model is failing
miserably.

11

I must also be slow. Can someone tell me how DNSSEC is supposed to encrypt my TCP/IP traffic?

12

Joe Abley <jabley@hopcount.ca> writes:

If we had DNSSEC, we could do away with SSL CAs entirely. The owner
of each domain or host could publish a self-signed cert in a TXT RR,

... or even in a CERT RR, as I heard various clever people talking about
in some virtual hallway the other day.
<http://www.isi.edu/in-notes/rfc2538.txt&gt;\.

i wasn't clever but i was in that hallway. it's more complicated than
RFC 2538, but there does seem to be a way forward involving SSL/TLS (to
get channel encryption) but where a self-signed key could be verified
using a CERT RR (to get endpoint identity authentication). the attacks
recently have been against MD5 (used by some X.509 CA's) and against an
X.509 CA's identity verification methods (used at certificate granting
time). no recent attack has shaken my confidence in SSL/TLS negotiation
or encryption, but frankly i'm a little worried about nondeployability
of X.509 now that i see what the CA's are doing operationally when they
start to feel margin pressure and need to keep volume up + costs down.

i don't have a specific proposal. (yet.) but i'm investigating, and i
recommend others do likewise.