Hacker News Reader

Comment by michaelt | Hacker News Reader

Software vendors shouldn't list CAs as trusted when they prove they can't be trusted - but removing a CA from the trust store breaks things for innocent websites who just chose a crappy CA.

Every CA should be required to publish a signed, public list of every certificate they have issued that is currently valid; and no certificate should be considered valid if it isn't on a CA's public list of certificates.

That way, when a CA fucks up like this, vendors could remove their certificates from the root stores, but could grandfather in all their previous certificates so the CA's customers have a few months to get a certificate from a decent CA. We could even use the list to contact all the CA's customers and advise them of the upgrade deadline.

If this CA isn't removed from the root store, it sends a message to other CAs: You can issue bad certificates with impunity, and there will be no negative consequences.

View on HN

I'm not sure that you actually want to avoid punishing people for choosing crappy CAs. That causes moral hazard, because you're not risking anything yourself by choosing a crappy CA, you're just spreading the risk among everyone else on the internet, because to avoid punishing you, they're accepting certificates issued from a known bad actor.

Doing it this way is actually a good way to handle product differentiation, because generally people won't make browsing choices based on certificate brand name, but commercial website owners will choose a better CA if it means that CA is less likely to get de-certified.

On the other hand, you want to make sure CAs will keep disclosing problems like these when they become aware of them, or they will certainly do anything in their power to keep breaches silent to avoid a certain death of the company.

Well, that was kinda a big difference between Diginotar and Comodo. Diginotar got hacked, knew about it, then tried to mitigate without telling anyone. Comodo got hacked and disclosed what they knew ASAP. Diginotar was pulled from the trusted root stores and went out of business and Comodo wasn't.

There were probably other reasons for the differential treatment (the scope of the Diginotar hack was bigger, for example), but I think that a lot of them are essentially strong correlates of the disclosure policy (i.e. if you have other responsible security practices, you're more likely to have a good disclosure policy).

Once the death-of-the-company option is on the table, it gives the CA a reason to comply with any lesser punishment.

For example fines, changes to procedures, mandatory security audits, agreeing not to issue certain types of certificate etc - the CA is going to do their best to comply if the alternative is to be put out of business.

Whether we want browser vendors / an industry standards committee to have that much power is another matter, of course.

CA's already have to go through mandatory audits and the procedures they must follow are spelled out.

Unfortunately there's no real procedure you can put in place to prevent hacking, as the NSA discovered to their cost.

Excellent point. Relieving people of their responsibility to think about who they should trust makes it easier for the untrustworthy to operate.

If we told people "no matter who swindles you, we'll make you whole", everybody would invest in ponzi schemes.

Your average person probably picks their CA because it's part of their hosting company, who probably resells someone else's CA largely because they're cheap.

You'd be punishing a lot of people because they don't know better for something that really should be built into dns and http.

This just moves the problem down one level and doesn't change anything. If you're a host you only have an incentive to choose a trustworthy CA if by choosing a lesser CA you're risking a significant problems for their users (who will switch hosts when they have a really bad experience and suddenly can't take credit cards anymore).

> Software vendors shouldn't list CAs as trusted when they prove they can't be trusted - but removing a CA from the trust store breaks things for innocent websites who just chose a crappy CA.

It seems like the way to fix this is to phase out bad CAs over time. And since certificates already have expiration dates and CAs typically don't issue certificates for longer than a couple years this should be easy: You don't trust any certificate signed by that CA which expires after a date two years from when you blacklist them. So the certificate some website got six months ago keeps working until it expires in a year and a half, but the certificate someone gets from them tomorrow fails immediately because it expires two years and a day after you removed the CA, which the site operator will discover in their testing and use a different CA before it reaches production.

That's useless. A compromised CA could create a certificate for an arbitrary start and expiration date. So this only penalises users who have had a certificate legitimately, and doesn't work at all if the CA's crown jewels are stolen.

> That's useless. A compromised CA could create a certificate for an arbitrary start and expiration date.

Sure, next month they could still be issuing certificates that expire in 23 months and they would be valid. But a year from then they'll only be able to issue certificates that expire in 11 months, and after two years they'll only be able to issue certificates that are already expired.

An arbitrary start and end date means that you could post-date the certificate to be good for two years starting from 1 year ago, even though you created it today.

That's what the parent post is talking about.

[edit: You're right. Even w/ arbitrary dates, end dates crossing the threshold will still not be accepted.]

His idea deals with the problem of CAs having no incentive to do their job properly: they won't lose their ability to issue certs.

You are addressing the other problem: CRLs essentially.

I agree that sounds like it would work, and it would avoid the hassle of dealing with a giant file listing thousands of certificates.

It depends on how worried you are about (a) proactively contacting site administrators; (b) stopping the CA issuing anything at all, instead of allowing them to issue shorter and shorter certificates as the end date approaches - and thereby demonstrating clear, immediate justice instead of slow, drawn-out justice; (c) 10 year certificates [1]; and (d) allowing website owners to proactively check for accidentally-issued certificates by monitoring the certificate lists.

(admittedly, monitoring the certificate lists wouldn't help if the bad certificate wasn't on the main signed public cert list, and people being MITMed were served a different signed public cert list. So this wouldn't be safe against CA insiders or CIA warrants)

[1] Really. https://www.positivessl.com/ssl-certificate-positivessl.php

> 10 year certificates

Really browsers should just discard anything that isn't a root CA and expires more than two years from now as a matter of principle. Consider the consequences of issuing a certificate that far out on domain ownership transfers: Facebook bought facebook.com in 2005. The previous owner could still have a signed certificate for it.

http://www.certificate-transparency.org/how-ct-works

If only there was a blockchain for this.

Don't know about this Certificate Transparency thing but Namecoin does allow a certificate fingerprint to be associated with a domain, without using a CA, and it works rather well.

That does work for domains within Namecoin, but it cannot be used for ICANN TLDs. People have suggested pairing schemes to allow domains under other TLDs to be associated with Namecoin records but I have yet to see one that is secure (they all rely on honest miners).

There's a growing literature and conversation about the tradeoffs between blockchains and the approach that CT takes. They are actually historically related to one another.

http://www.aaronsw.com/weblog/squarezooko

Ben Laurie (a co-inventor of CT) had some particular objections to blockchains, partly to do with the problem that the total computational power that is or will be brought to bear on mining is unknown and maybe unknowable.

http://www.links.org/files/decentralised-currencies.pdf http://www.links.org/files/distributed-currency.pdf

I'd like to actually make a web page that talks about the historical relationship between blockchains and other decentralized append-only data stores, as well as the points of debate and trade-offs between different designs, and the space of proposals that achieve consensus about the contents of an append-only record.

The CT approach is a lot more efficient assuming a closed network of pre-registered "miners" (logs, in CT parlance). This works ok for CT because CT does not place such a large emphasis on decentralisation, nor does it need to. Ultimately the power in the SSL system lies with browser and OS vendors, in turn that means only a handful of people really. Having a super fancy ultra-decentralised system that will only be used by a handful of OS services and browsers doesn't make a whole lot of sense.

You mean like this?

https://github.com/okTurtles/dnschain

okTurtles is one of several middleware options that runs on top of Namecoin, implementing the domain record spec. It advocates using someone else's trusted server as a data source, but does not at this time implement any integrity protection for data in transit.

http://www.freespeechme.org/ is a more mature and more secure.

Edit: DNSChain does not appear to provide certificate validation for .bit domains in common browsers at this time. It can serve DANE records, but the browsers don't currently verify them and the existing browser extensions for adding DANE support require DNSSEC which DNSChain does not provide, unless I'm missing something.

I think DNSchain offers some compatibility with .bit domains, but the real innovation happens with .dns domains?

FreeSpeechMe is not practical for use because it requires running Namecoin locally.

DNSChain is just as secure as FreeSpeechMe when connected to a trusted DNSChain server.

> It advocates using someone else's trusted server

This is misleading. You and Jeremy keep repeating this line and it honestly feels like a vendetta at this point (I hope it's not). It advocates connecting to your DNSChain server (or a close friend's). This is security that is either on par with FreeSpeechMe (without the baggage), or orders of magnitude better than what's provided by HTTPS today.

Certificate Transparency does not work.

It does not, as it claims, always provide a log of issued certificates and it does not stop MITM attacks:

- http://www.ietf.org/mail-archive/web/trans/current/msg00233....

- http://okturtles.com/#oktvs

It also does nothing to fix the non-functioning certificate revocation problem (which is not a problem with the blockchain).

If more than one signature was allowed on a certificate, then sites would be able to have more than one path to the root. Then it wouldn't matter if any single CA was removed, giving people time to obtain new signatures.

Agreed, but I think it should go a step further. Browsers should require 2 signatures from different regions. That way a government can't pressure a single CA within their borders to issue rogue certs. 2 signatures would be minimum with 3 for redundancy.

Agreed: this is a major operational flaw with deployed PKIX.

It has many unintended consequences, for example it's especially a pain with UEFI Secure Boot.

A compromise that wouldn't hurt innocent websites would be to remove the CA's ability to issue new certificates.

CAs knew that the stakes were high when they signed up to be a CA, so I think it'd be fair to remove them permanently. Eventually, only the truly paranoid would be left. It may cost a bit more to run a fully secure CA, and that would be reflected in the cost of a certificate from those that remain, but that'd be a price that everyone should be willing to pay.

> It may cost a bit more to run a fully secure CA, and that would be reflected in the cost of a certificate from those that remain, but that'd be a price that everyone should be willing to pay.

I don't know, this could really discourage the adoption of HTTPS. We need to be making it easier for sites to adopt it.

Ideally we could lessen our dependence on CAs. Sure, a "fully secure/expensive" CA would validate a certificate's authenticity with high confidence, but we'd be excluding tons of hobby projects and small shops who wouldn't want that expense.

Seems to me a CA that can't avoid issuing bad certificates is a bad thing for security, no matter how cheap they are.

What good does widespread HTTPS use do if you can not trust it?

I'm all for reducing our dependence on CAs, and, reducing the number of CAs we trust for signing a site, like putting the keys in DNSSEC. But until we do that, we must not trust bad apples.

It's always better than plaintext HTTP. Nothing is worse than plaintext.

TLSv1.2 with good ciphersuites using ECDHE with a named curve like secp256r1 [murky origins I know, but we know of nothing else wrong with it, though Curve25519 is superior in my opinion], and an AEAD like AES-128-GCM or CHACHA20-POLY1305, properly implemented with no TLS compression at least comprehensively prevents Eve from spying on the contents of your connection in most cases, even if you're using self-signed certificates with no pinning and are entirely unprotected from Mallory.

A browser shouldn't call it secure or the endpoint trusted, but it should transparently replace all uses of unencrypted HTTP worldwide, including internal ones. That should not be discouraged, and will hopefully be actioned with HTTP/2 - that was the plan, anyway.

Even if the encryption is crap (Export ciphers... RC4?) I guess it does take some more work for Eve, which knocks out a few of the lower-capability adversaries.

Couldn't Mallory just replace the certificate with her own one? The browser would just pop up the same warning. The warning should show some form of a public key fingerprint at least before clicking through "I understand the risk".

I'm not sure it's possible to absolutely determine when a certificate was issued, that doesn't either introduce another third party (i.e. a timestamping service) that the CA can't trivially bypass.

A distributed no-trust-required timestamping service is fundamentally what Bitcoin provides.

So it would be possible to prove a certificate was issued before a certain time (eg. before a breach at a CA), if CAs were forced to immediately publish, in the Bitcoin block chain, the hash of each newly issued certificate. There would be no need to trust a single (bypassable/hackable) entity doing timestamping, since the block chain itself is distributed.

(This is just one of the numerous applications that distributed block chains enable IMHO! And we are just barely scratching the surface of what we can do with such a concept...)

The problem is that distributed block-chains are not a panacea. It requires a certain inertia to increase the difficulty of attacks on the block-chain, and even then attacks are still possible if your pockets are deep enough.

For some applications, yes.

But the bitcoin blockchain is already too big to store and sync on mobile devices with costly data connections - and it would only get bigger if it had to contain every SSL certificate ever issued!

You could have SSL clients connect to trusted nodes, like mobile bitcoin clients do [1], but then you've basically taken Certificate Authorities and replaced them with 'trusted nodes' so you're not much better off really.

[1] https://en.bitcoin.it/wiki/Thin_Client_Security

The bitcoin blockchain doesn't need to contain every SSL certificate. It just needs to contain a SINGLE transaction conducted each day where the comment field contains the hash of a document published by the root authority. That document would be published elsewhere (on the site of the owner of the root certificate) -- the bitcoin blockchain would be used only to provide proof that the document hadn't been changed since it was published.

i assume this would be done by looking at the issuing date of the cert and rejecting certs with issuing date > date CA was 'executed'.

however, a CA could just issue certificates with the issuing date in the past. they probably wouldn't do this for real customers because it would be detected easily. however, they could do it for fraudulent customers and it would be a massive temptation for CAs who have no other source of revenue to do this.

> That way, when a CA fucks up like this, vendors could remove their certificates from the root stores, but could grandfather in all their previous certificates so the CA's customers have a few months to get a certificate from a decent CA.

You cannot grandfather in old certificates because you have no idea what else may have been tampered with. If they have a security hole, it could have been there for a long time. There is almost no way to know if a certificate was improperly issued unless you're the domain owner. All of them have to be invalidated to stop any other potentially invalid certificates.

This is why the CA model is so stupid. It relies on humans at over 650 institutions "doing the right thing" every time, and when the inevitable happens, destroying a large number of innocent certificates.

In terms of sending a message, we already know that you can issue invalid certificates with impunity. Exploit a CA, make your fake cert, use it, get found out eventually, repeat. It doesn't work as well for pinned certificates but there's more than one way to skin that cat.

If there are no consequences then there's no value to the CA system. Why bother with it then?

> Every CA should be required to publish a signed, public list of every certificate they have issued that is currently valid;

A LIST??? This will be much MUCH larger than a list of revocations, take a LONG time to verify, and frankly, would never be up to date.

Reply on news.ycombinator.com