|
|
Subscribe / Log in / New account

Laurie: Improving SSL certificate security

Laurie: Improving SSL certificate security

Posted Apr 3, 2011 9:38 UTC (Sun) by rilder (guest, #59804)
Parent article: Laurie: Improving SSL certificate security

Implementing everything in terms of DNS even though less encumbered than CA system, represents a single point of control/failure. Looking it from a political point of view, Governments have/had tampered with DNS using coercive methods, DNS is a centralized system owned by people who control root servers. What we need is an alternative beyond DNS, there is/was work being done on a distributed DNS though it is not released yet.


to post comments

DNSSEC - not perfect, but good

Posted Apr 3, 2011 11:18 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

A truly distributed system would have some advantages, but I think DNS has a lot going for it here.

The single point of failure is a very narrow point, which is a big improvement. The root rarely updates, needing only to contain accurate information about the TLDs which are in turn supposed to be fairly stable. Updates are a big window of vulnerability and the root makes that much smaller compared to global CAs.

It represents a /highly visible/ single point of failure, like the front gate of a castle. Maybe it's the most vulnerable point, but it's watched constantly for signs of attack.

On any particular week you can pretty much guarantee that some interested amateur or security researcher would look at the bits coming from the root and have a chance to notice if something is wrong with them, not so for the tens of thousands of SSL certs being issued all over the world. The problems which have been detected in SSL certs have often taken months or even years to be noticed after they first occurred, and that's just for the ones which were on public web sites. The root is always public.

Unlike the CAs which have a three ring binder somewhere documenting their alleged procedures, but get to carry on in private, the root keys are managed by a semi-public ceremony‡, in which not only the official process is documented, but deviations are recorded (in scribbled handwriting) and people from a large rotating list of interested parties are present as witnesses.

‡ You don't get visibility for some of the steps because they involve fragments of secret data, knowing these would put the keys at risk.

Now you're correct in so far as below the root governments can coerce its own registry to do whatever it orders. But a reasonable person would not expect their example.fi domain to be proof against Finland's government intervention. The least satisfying component is the unknown control of some registrars. Perhaps your example.fi domain was registered via Foo Corp, who turn out to be wholly owned by a US corporation. No doubt some pressure on them would cause Foo Corp to turn over example.fi to the US authorities without consulting Finland. But again you have the choice to go with a registrar you trust.

DNSSEC is not a panacea, but it's a better and crucially, more intuitive way to secure information about names people rely on than what we got from the CAs. They had a chance to be exemplary, and they've comprehensively failed.

Laurie: Improving SSL certificate security

Posted Apr 21, 2011 12:44 UTC (Thu) by robbe (guest, #16131) [Link]

A single point is exactly useful in security: you need to protect less!

You can take a look at the procedures -- how the . KSK is handled, there are even videos available. Does even *one* CA document that thoroughly how they protect their CA private keys? They usually just tell some auditor, which has little incentive to prove that their procedures are problematic.

Sure the goverment of Fooland can lean on nic.foo to get google.foo pointed to a different address. Citizens of Fooland will just have to learn to type google.com instead if they don't trust their government.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds