User: Password:
|
|
Subscribe / Log in / New account

Fraudulent certificates in the wild — again

Fraudulent certificates in the wild — again

Posted Jan 5, 2013 15:43 UTC (Sat) by kleptog (subscriber, #1183)
In reply to: Fraudulent certificates in the wild — again by tialaramex
Parent article: Fraudulent certificates in the wild — again

Well, if your only response to discovered issues is to blacklist CAs for life, then you'll just be encouraging cover-ups. Or to put it in economic terms, if you make responsible disclosure more expensive than the cover-up, then businesses will choose the latter.

Which is better for users? I wonder if someone has tried modelling this, perhaps using game theory.

The basic problem is that any CA can sign for any domain. That's the problem we should be working on. Once that is solved the rest becomes tractable.


(Log in to post comments)

Fraudulent certificates in the wild — again

Posted Jan 5, 2013 21:17 UTC (Sat) by JanC_ (guest, #34940) [Link]

The basic problem is that any CA can sign for any domain. That's the problem we should be working on. Once that is solved the rest becomes tractable.
That would require some out-of-band system to check which CA can sign for which domain. But then, how do you make sure you can retrieve that info securely?

Fraudulent certificates in the wild — again

Posted Jan 5, 2013 22:19 UTC (Sat) by paulj (subscriber, #341) [Link]

There is a simple solution to this, for certs that authenticate domains: publish the certs in DNSSec signed records. This automatically aligns the trust hierarchy of the certificates with that of the objects the certificates belong to, by re-using the trust hierarchy attesting to the validity of those objects.

Of course, it means the CA business model for domain names becomes obsolete, and only needed to support legacy applications.

DANE

Posted Jan 6, 2013 16:38 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

And in fact work on the standards to make this happen is already done, as RFC 6698 - DANE, DNS Authentication of Named Entities for SSL / TLS protected services like HTTPS or IMAPS

For SSH it not only exists, as the SSHFP record but the software to support it is widely deployed (modern OpenSSH), if your organisation has DNSSEC signed DNS records and a vaguely modern resolver on machines that run SSH clients then you can put the public key signatures into DNS and throw away all those known_hosts files that are such a pain to maintain and distribute on big networks.

Actually getting DANE supported is a problem. Mozilla has sat on a Firefox patch for about a year, Internet Explorer would probably only introduce support if it became a Must Have for some reason. The bigger the dinosaur the more tempting it is to preserve the status quo, no matter how miserable that is for users.


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