Comments

iwonder • March 31, 2015 1:10 PM

How would one go about making a contribution to a charity, securely, assuming it’s large enough that you really don’t want it to go missing?

Alan • March 31, 2015 1:16 PM

IMO, the major browser vendors should block all certificates issued by MCS (the intermediate CA that issued the fraudulent certificates) and CNNIC (the company that issued an intermediate CA certificate to MCS). Issuing CA’s should be held accountable for their intermediate CA’s. That will send a strong message that this kind of fraudulent activity will have severe consequences, and will force CA’s to be more careful who they allow to operate under their master certificate.

MrArt • March 31, 2015 2:01 PM

Seems likely to me that the CA is issuing fraudulent MITM certificates for all domains, it’s just Google are the only ones who have picked them up on it.

Clive Robinson • March 31, 2015 2:34 PM

@ Bruce,

Yet another example of why the CA model is so broken.

Some years ago shortly after the AES competition you made a comment that next major challenge for cryptographers was Key Managment Systems.

Aside from the very limited and mainly usless QKD next to nothing appears to have happened and we are moaning for yet another decade that PubKey is bust….

Do you know if any academic cryptographers are actually working on this –fairly hard– problem, and not getting anywhere, or has it been kicked into the long grass as not having a reasonable chance of being solved any time soon…

John Macdonald • March 31, 2015 3:36 PM

A third alternative to Clive’s question – could there be no challenge issued because the people who issued the AES challenge don’t want an answer to be found?

mastmaker • March 31, 2015 3:44 PM

To me (an amateur with interest in security who wrote some code for PKInit and IKE a decade ago), a band-aid ‘fix’ would be a central certificate registry where every certificate issued by the ‘recognized’ certificate providers MUST be registered. We are at a point now where the bandwidth required for a check with this registry (at the time of accessing a website) is trivial.

Only those certificate providers who submit to this requirement can then be allowed to add their root certificates to the operating system by default.

Companies can then check this registry (for free or for nominal payment) to see which certificates are issued to their company/location/department and see whether they are all legitimate or not.

Nick P • March 31, 2015 3:50 PM

@ Clive

I still think KM is a largely solved problem in basic cases given there’s KM infrastructures operational. The main weakness of current models are security of TCB’s involved and covert/side channels. The good models simply don’t get much adoption outside of militaries and a commercial niche. I’ll look into the literature for you to see what they’re doing, though.

Note: Global CA’s obviously don’t fit into my claim as they’re a bad model to begin with.

Nick P • March 31, 2015 4:36 PM

Survey of research on various aspects of key management

Best to always start with the “survey of” papers. Usually reference good work.

Survey and Taxonomy of Key Management Protocols for Wired and Wireless Networks

Note: This one has a nice visual taxonomy.

A survey of Key Management in Mobile Ad Hoc Networks

A survey of key management techniques for secure and reliable data transmission in MANET (2013)

A survey of key management for secure group communication

Note: All of the above reference many different works on the subject. Mobile and Ad hoc key management are currently receiving most of the research effort with most innovation as well.

Survey of key management in wireless sensor networks

<a href=”http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf>NIST’s Framework for Designing Cryptographic Key Management Systems

A Survey on Key Management of Identity-based Schemes in Mobile Ad Hoc Networks

A paper on alternatives to CA’s said most of their research favors these three projects: Certificate Transparency, Public Key Pinning, and Certificate Authority Authorization.

So, there’s your whole weekend people. 🙂

Jonathan Wilson • March 31, 2015 5:04 PM

There are a number of alternative proposals to replace CAs. DANE (storing things in DNS and securing it with DNSSEC). The Sovereign Keys proposal from the EFF. And others that I cant remember or haven’t heard about.

Why is there so little interest in actually advancing these proposals to completly replace CAs? The mentioned “paper on alternatives to CAs” recommends 3 projects. None of those 3 projects are “alternatives to CAs”, they are augmentations for CAs to enhance security.

Nick P • March 31, 2015 5:12 PM

@ Jonathan Wilson

Good correction. The CA concept isn’t inherently bad if used for just what it’s intended. The current implementation is bad, though. So, they’re updating what we understand well instead of starting from scratch.

Ellendhel • March 31, 2015 5:25 PM

“Yet another example of why the CA model is so broken.”

Indeed.

We have DNSSEC and DANE that could be used to help solving this, but unfortunately it’s not deployed as fast as we would like…

65535 • March 31, 2015 5:46 PM

The Certificate Authority [CA] system has huge holes. It’s based on trust or the so-called “honor system.” That system can be easily abused.

Bruce, I would encourage you to continue with your CA authority project. I trust you more that I trust and of the major CA’s out there.

A second fork would be to develop “Minimum” or “least privilege certificates store list” on a well known web site and to let non-technical people strip out all the unneeded and non-used certificates.

That includes SSL stripping devices and Anti virus products which place a certificate in one’s browser – that is AV products under our control. We probably should be able to detect those bogus certs.

In the long run all of us are going to have to clean out and police our own certificate stores.

I have several questions for the crypto experts here:

When broad SSL/TLS stripping occurs is it correct to assume a bogus certificate has been placed on our machines with some sort of “certificate forging engine”? This forging engine could be in a fire wall or Antivirus software – and I would assume the “forging engine” is somewhat complex – visible and uses CPU cycles.

Next, should AV products depend on SSL/TLS certificates for detection of malware? That would include code signing certificates.

Given the current holes in the Certificate system shouldn’t AV products depend on finger printing, odd changes in critical files, behavior analysis and/or heuristics?

k11 • March 31, 2015 6:01 PM

Would traceroute show anything suspicious, if this were going on, and if so, what would this look like?

65535 • March 31, 2015 8:23 PM

@ k11

“Would traceroute show anything suspicious, if this were going on, and if so, what would this look like?”

If the SSL stripping device is a firewall box traceroute, Tracert and
PathPing [the latter for Windows] would show the firewall/router hop but probably not forged certificate.

This brings more questions. Which routers in the path between the server and the user are SSL stripping devices?

@ all crypto experts:

To clarify the “forging engine,” it is my understanding that such cert forging engine must be in place on all incoming HTTPS connections so each cert incoming is SSL stripped and forged but the “lock” still shows up in the browser bar – it could result in higher CPU usage and possible the need for a longer TTL displayed in path ping – but I am no expert.

What is your opinion?

[Please excuse the grammar errors and other errors]

No Such Agency • March 31, 2015 9:07 PM

@65535: Not sure if it is quite the same thing, but on some public WiFi I have seen SSL certs for secure websites flag as “untrusted” because the SSL cert belonged to the wireless network provider, and was not signed by a trusted root certificate (all “secure” websites were using this same bogus certificate).

This resulted in the browser generating a message asking to accept the unrecognized certificate.

Any user who didn’t read the message carefully would not spot that they were being MITM by the wireless operator.

Had the certificate been signed by a trusted root (or forged), the message would have never been generated.

As for delays as the result of this process, I would suggest that the performance would not be noticeably degraded.

jdgalt • March 31, 2015 10:18 PM

I’d like to subscribe to, or start, an effort to publish a list of all CAs and who owns them. Then people can start with an empty list and enable only those certifications they feel they can really trust or have no choice but to trust.

Matt • March 31, 2015 11:59 PM

@iwonder: The simplest answer is that you call them up on the phone and verify the fingerprint on their certificate. In practice, I doubt they would know how to do that. And do you trust the phone number? Also, maybe their site is hacked.

It is probably safest to cut a check, or ask them for their bank account numbers over a trusted channel.

@k11: Not necessarily. Firstly the attacker may have control of a hop that is on your legitimate route, and then traceroutes would show you nothing suspicious. They could drop ICMP time exceeded messages being sent to you, leaving your trace dead once you reach their hop (traces dying partway is quite common, and wouldn’t raise suspicion).

In addition, a cautious attacker could pass through anything which is not TCP traffic on port 443, and then only attack traffic which is on port 443. To guard against that, your trace program would have to be configured to use that port. An even more caution attacker could pass through traffic where the TTL value is below a certain threshold.

In short, traceroute would be quite unreliable in detecting such an attack, you are far better to inspect the certificate and verify out of band if necessary.

Jan • April 1, 2015 12:06 AM

@mastmaker: What you are proposing is known as “Certificate Transparency” and already being developed.

yuhgccdsdhbnjffpp • April 1, 2015 3:33 AM

@jdgalt: Another solution could be using certificate pinning. E.g. the Certificate Patrol add-on for the Firefox browser.
While to do that in an email client (e.g. Thunderbird), one can simply disable all CAs and only enable the certificates (not CAs, but specific certificates) of the email/update servers used.
The only certificate related risk then occurs on the first connection (since one doesn’t know whether the certificate is the right one). In which case, for critical connections, one can use an online certificate checker (and/or another channel, such as TOR, VPN, etc), over a previously pinned HTTPS connection. That should be fine, unless the certificate replacement happens close to the server (e.g. it’s ISP), in which case any confirmation channel would see the forged cert as well. But that doesn’t apply to CNNIC certifying Google.

uwe • April 1, 2015 4:55 AM

Did we really need yet another proof that the infrastructure around TLS/SSL is fundamentally broken? the system isn’t designed with security in mind but to enable companies like Verisign to make money. What are certificates supposed to achieve? you want to make sure you’re connecting to the right server(you trust) and not to an man in the middle. I think decentralized p2p system would do a better job. everybody connecting to a server could publish the fingerprint and the more published acknowledgements an server gets the more trustworthy it is. you can’t just buy trust with an cert but earn it by keeping your system available with the same key. of course there are some additional points to be covered like revoking a key(but let’s not forget the fact that revoking a cert nowadays is only possible in theory – Heartbleed was a proof for this). the recent tries to make the cert system more secure with techniques like pinning isn’t as much an security gain but securing the business model of those CA companies generating money from virtually nothing

Gervase Markham • April 1, 2015 11:10 AM

“There’s a Chinese CA that’s issuing fraudulent Google certificates.”

Well, no, actually. A Chinese CA issued an intermediate certificate to an Egyptian company, the certificate had woefully inadequate controls, and the Egyptian company loaded it into a SSL MITM device used by one engineer, and it issued certs for Google and other domains, and the engineer’s copy of Chrome reported that to Google.

There is much to criticise CNNIC for here, but “CNNIC issued fraudulent Google certs”, as if they are sitting on the Great Firewall MITMing thousands of Chinese people with them, is not a fair summary of the known facts.

Tobias • April 1, 2015 6:30 PM

Hi all, this is indeed bad news.

And yes, the current CA model is indeed suboptimal. 🙁

In terms of fixing some of the issues with untrusted CAs:
1. the browser vendors need indeed to remove any CA that is abusing the system by issuing rogue certificates. (whether they be ordered by government or not)

  1. the IETF has recently released (or is about to release) two new standards that shall help this a little bit: HPKP (Public Key Pinning Extension for HTTP, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21)

Here is a first report on adoption of them presented at the IETF conference last week: http://www.ietf.org/proceedings/92/slides/slides-92-saag-2.pdf

And even though the standards do not solve all problems in this regard, a fast and broader adoption of both standards would IMO surely be beneficial to reduce the attack surface in these scenarios dramatically.

Markus Ottela • April 2, 2015 3:21 PM

@ Tobias:

Appelbaum said NSA has CA resources. Also, the total market share of 5 largest US CAs – Comodo, Symatec, Go Daddy, GlobalSign and Digicert – is 94% of all globally signed certs. It’s safe to assume each of those have already received a NSL accompanied with gag order so there is no trust left. Certificate pinning might work, unless the browser installer is compromised and signed with key the proprietary OS trusts. We need to bootstrap security through strong web of trust – distributed honor system, strong end points to store keys in and relationships managed through transparent, non-profit organisations such as EFF and ACLU.

Anon • April 6, 2015 3:38 AM

@Markus Ottela

While largely you are correct in your assessment, GlobalSign is not a US Certificate Authority, they were founded in Europe and later acquired by a Japanese company and do not have root servers located within US jurisdiction.

Markus Ottela • April 10, 2015 12:57 PM

The one time I don’t double check things a mistake happens. I stand corrected and apologize for making the assumption. Their HQ is in Boston though; any source on root server locations?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.