Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Way to go, EFF!

Long story short: Verizon bought GTE CyberTrust. GTE CyberTrust signed a CA=TRUE for Etisalat, the UAE's biggest telco. Even if you didn't know the rest, you wouldn't be happy, but: Etisalat has already MITM'd and backdoored a zillion Blackberries. Now they can turn off your encryption, too.

You can't easily disable Etisalat's "Comtrust" certificate (you can see it for yourself; go to http://j.mp/a11K0t and click the lock icon in your browser; note that the GTE CyberTrust root is also an MD5 cert --- classy), but you can disable the root CyberTrust cert easily:

* For OS X Safari, pull up Keychain Access, click "Certificates", search for "Cybertrust", and baleet.

* For Firefox, go to Security -> Certificates, browse to CyberTrust, and click delete.

This will probably break a bunch of other random sites validation. Oh well.

The really disturbing thing about this, and the part that's unique to the EFF/iSEC SSL observatory ("you know it's great research when I talk up my competitors"), is the prevalence of CA=TRUE certificates signed by root CAs. There's no easy way to find out how many of these exist! It's the closest thing there is to a fundamental flaw in the SSL/TLS certificate model.

The thing this highlights is the way that CA certificates are all-or-nothing. You can't say "This is a CA, but they should only be trusted for certificates where the CN matches this pattern".

Separate CAs were always a bogus idea. They should have just issued certificates in parallel with domain names - so if I registered "google.com", I also got a certificate from the domain registrar which allowed me to sign certificates for "<anything>.google.com".

... and if the owner of somerandomdomain.net lets his domain expire, you're faced with the choice of (a) put his SSL key (along with a couple thousand others) on the global CRL, which then grows to monstruous proportions or (b) let the old somerandomdomain owner play man-in-the-middle games with the new somerandomdomain customers?

Also, would that mean that VeriSign (.com registrar) would be your only option for a .com SSL certificate?

(I'm not saying it's a bad idea to limit CA authority to a certain top-level or second-level domain, it's just that I see certain problems with doing it wholesale and in parallel).

It would only have to go onto the CRL until it expired. The CRL would become large, but it would still be a couple of orders of magnitude smaller than the global DNS itself, and we manage to deal with that OK.

The idea would be that the certificate comes with the domain name, as the whole ball of wax. Verisign aren't the only _registrar_ though - GoDaddy, MelbourneIT etc. are all registrars - VeriSign's claim to fame is that they manage the .com _registry_.

I've pretty much always felt that there should be no central authority. I don't know much about the actual protocols in use, but it's my understanding that they're single-signer.

What I would prefer is a multiple-signer system. Each resource can have a list of signatures indicating entities that trust the resource. Each entity can have a list of other entities they trust. Then to verify a resource, you search the web of trust until you hit max_separation while looking for a path from you (source) to the resource (sink).

So to sign my payment processor, I'd self-sign and have visa sign. I'd get a personal signature from the .com authority. You trust visa if you're interested in payment, and you trust the .com authority if you're interested in identity. There would be no difference between authentication and authorization by default, but that would be easy to patch in via specialized authorities.

If some entity turns out to be overly trusting, it would be trivial to replace, since all trust is directed. Just add a new, trustworthy, intermediary. The downside is that much more computation would be required to find the links, but I'm confident that would remain manageable because of the human element; we wouldn't include more trustworthy entities than bureaucracy allows.

There are holes in this scheme, sure. It might even be a subset of the current technology. But I'm fairly certain it'd be a superset of the current practise.

Oddly enough, GTE Cybertrust doesn't actually seem to be the same Cybertrust that Verizon Business bought in 2007 (as information on "GTE Cybertrust" predates the incorporation of "Cybertrust" by a good ten years).

It looks like GTE Cybertrust was part of GTE Internetworking, which would have been absorbed into the Bell Atlantic-GTE merger which created Verizon.

That seems odd.

You don't have to delete certificate, you can mark it as "Never Trust".

On OS X, it is possible to disable just Etisalat's Comtrust certificate. Click the lock icon to view that certificate, drag the large certificate icon to your desktop, then drag it into Keychain Access (i.e. into your login keychain). At that point, you can set the trust settings on that certificate to Never Trust.

Neat! I'm surprised and happy this works; I presumed the Apple SSL framework would only check the trust setting on the root.

Unfortunately, you can't (as far as I can tell) do this with Firefox; import the Comtrust certificate and turn off "use to validate websites", restart Safari, and it'll still accept the Etisalat site.

What does work is to take the CER file, pop it open in a hex editor, whack 1 byte of it, and import that; the result is a mismatched certificate error on sites signed by Etisalat/Comtrust.

...go to http://j.mp/a11K0t [Etisalat site]

> This site requires Internet Explorer !

If you were looking for more reasons to dislike these guys I guess...

In OS X Opera, you can go to Preferences -> Advanced -> Security -> Manage Certificates -> Authorities. Select the GTE CyberTrust one and either Delete it, or disable it from the "View..." screen.

"This will probably break a bunch of other random sites validation. Oh well."

Fun fact! Among said sites, PayPal. Or more specifically, paypalobjects.com which hosts their CSS.

They signed a CA=YES cert for Akamai. Lovely.

Reply on news.ycombinator.com