Home page logo

nanog logo nanog mailing list archives

Re: Security team successfully cracks SSL using 200 PS3's and MD5
From: Joe Greco <jgreco () ns sol net>
Date: Mon, 5 Jan 2009 15:32:11 -0600 (CST)

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

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

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.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]