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

Mon Jan 5 21:32:11 UTC 2009

> On 09.01.06 05:59, Joe Abley 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?
> >
> > 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.
> 
> 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.

Sure it is.  At least, sometimes it is.

One of the problems I mentioned previously was that there's such an amount
of fuss involved in obtaining SSL certs for relatively-low-value uses, and
the end result is that many sites self-sign or simply don't bother.

In the case where I've hosted a box with $BigHosterInc, and they've got
DNS control of my zones, and they've got hands on the physical box(es),
it becomes difficult to determine just how to prevent a bad actor at
$BigHosterInc from do malicious things.

On the flip side, there is very clearly value in differentiating between
"a certificate that merely guarantees that the communications between the
server and your client is secure" and "not only that, but we certify that
you are talking to a FooBank-owned web server."

Trust is all relative.  I might trust you, Randy Bush, in some particular
way.  But if a group of gunmen storm your home and force you to reveal
some bit of confidential data I've given to you, is my trust misplaced, or
is it simply that there are necessarily some limits and risks in sharing
with you that confidential data?  What is the difference if the information
is something that gets someone killed, vs information that merely results
in my company's business plans being known to a competitor?

With that in mind, there could certainly be great uses for delegating some
forms of trust through the DNS chain.  Not all, though, not all.  Banks are
a good example of the circumstance where you'd want separation.

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

Then have some coffee.  ;-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.