22 ms·

Sustaining Digital Certificate Security

260 points by fred256 11y ago

nailer 11y ago
> It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. Symantec said they did an audit, Google spent 'a few minutes' and found many more mississued certificates just from the CT logs. In other words, Symantec can't audit themselves, so Google now require public issuance logs for all their certificates. > [Google] expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. This is a massive (and justifiable) smack in the face to Symantec. Disclaimer: we're a Symantec competitor, as you may have realised: https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/sgc-ssl-certificates https://certsimple.com/blog/sgc-ssl-certificates
- sarciszewski 11y ago
  Yes, and a very well-deserved one.
- Sir_Cmpwn 11y ago
  What is a "Point-in-time Readiness Assessment"? I googled it and found it in the requirements for some CAs, but not what it actually is.
  - thenewwazoo 11y ago
    "Point-in-time" is a term of art for audit. It basically means that a third party will attest to a given state at a given time. They're in contrast to "continuous" audits, which is more focused on auditing records over a period of time, or on a recurring basis. A "point-in-time readiness assessment" is kind of redundant, but it basically means getting a third party to come look at their CA (processes, procedures, standards, implementation) and assert on Symantec's behalf that it meets some criteria.
    - Sir_Cmpwn 11y ago
      Thanks for clarifying.
bracewel 11y ago
>Symantec performed another audit and, on October 12th, announced that they had found >an additional 164 certificates over 76 domains and 2,458 certificates issued for >domains that were never registered. :|
bpolverini 11y ago
All the more reason why client-side encryption needs to become part of our daily interaction with software and cloud services.
- vtlynch 11y ago
  You mean client-side authentication? And how would this have helped.
  - nsomaru 11y ago
    I would venture that your parent meant that we should use 'dumb' cloud services that just store encrypted data which are then retrieved and de-crypted on the client side.
    - bpolverini 11y ago
      Bingo.
      - deathanatos 11y ago
        Say you attempt to do this all in JavaScript; you've still got to deliver the page (the encryption code, really) to the user securely; otherwise, I can modify it s.t. when it gets a blob from the server and decrypts it on the client, that decrypted value is also sent off to a shady spot. You still need to get your app from you to your user securely, and how do you do that? It's the core problem really: how do you distribute your public key? How do you make sure Joe user gets the right public key? Today, we have the CA infrastructure, which admittedly isn't great, but… what would you do differently? (And the big problem is that it needs to work for average Joe.)
        squidlogic 11y ago
        Couldn't you have a browser plugin that would verify your js is being served up from the correct source?
tshtf 11y ago
Days after the initial reports of rogue certificates being issued, Symantec wrote in their blog that they had already fired employees: In addition, we discovered that a few outstanding employees, who had successfully undergone our stringent on-boarding and security trainings, failed to follow our policies. Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process... At the end of day, we hang our hats on trust, and that trust is built by doing what we say we’re going to do. http://www.symantec.com/connect/blogs/tough-day-leaders http://www.symantec.com/connect/blogs/tough-day-leaders It's starting to look now like this the fault of systemic flaws at Symantec, and not just a few employees who didn't follow procedure.
- mwsherman 11y ago
  Yes, that was a very old-school way of dealing with the problem. It’s mostly symbolic. Most problems are systemic, which is a nice way of saying “ultimately management’s fault”. Most things that most people do, most of the time, are reasonable in the circumstances. Management creates the circumstances. “Human error” is a non-explanation. Here’s a book on the topic, often called systems thinking: http://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058/ref=asap_bc?ie=UTF8 http://www.amazon.com/Field-Guide-Understanding-Human-Error/... Getting even more bookish: firing “bad apples” for “human error” is a form of substituting an easier question when presented with a harder one, as Kahneman describes in Thinking Fast and Slow.
  - colechristensen 11y ago
    >Most problems are systemic, which is a nice way of saying “ultimately management’s fault”. Systemic problems are _everyone_'s problems. Both management and employees are a part of the same system. Firing bad apples for human behavior is equally as pointless as firing/resigning management (or pointing fingers).
    - mwsherman 11y ago
      Fair.
evmar 11y ago
It makes me* uncomfortable that Google has effectively appointed themselves as the internet police and using their power to push people around like this. But at the same time, there is nobody else (?) who is taking care of this, and I suppose the good of someone/anyone looking into and taking action on the sorts of serious problems that Symantec has exhibited probably outweighs my discomfort. * Disclaimer: Google employee, no connection to any of this cert stuff.
- detaro 11y ago
  All browser vendors IMHO should do exactly this. The CAs want them to entrust them with their customers secrets, they should make sure the CAs they accept work properly.
  - voltagex_ 11y ago
    I'm not sure. There's no real deliniation between Chrome and Google (as brands / entities) - this seems like Google exerting power over another company. I have no love for Symantec but it doesn't feel right. I wonder if private negotiations have failed and this is Google trying to push the point? Can you imagine if Mozilla tried the same stuff? I mean, they don't trust CACert any more after CACert wasn't able to verify itself (?) adequately, but this is on a different order of magnitude.
    - Titanous 11y ago
      Mozilla runs a root program that regularly enforces similar requirements on CAs. For example, they are currently discussing whether they will require the same of Symantec as Google or even more: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Hkyg_09EDYE https://groups.google.com/forum/#!topic/mozilla.dev.security... And here is a thread about a Chinese government CA that mis-issued certificates for Google domains: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/czwlDNbwHXM https://groups.google.com/forum/#!topic/mozilla.dev.security...
    - detaro 11y ago
      The alternative, not trusting their certs immediately instead of giving them additional requirements, would also be "exerting power over antother company". Mozilla has done so in the past, and I hope they will do so in the future. Google's argumentation that Symantec apparantly isn't able to properly assess themselves seems sound to me: if after being told about a specific issue they still are not capable of finding all instances of it happening, while outsiders can do so with the published information, then they they are missing critical abilities in this regard.
gefh 11y ago
Is the CA model just unfixably broken at this point? What should replace it if so?
- 0x0 11y ago
  Something that sets things up so that the actual domain registrar becomes the only valid issuer of certificates for any given domain. That would kill the possibility of unrelated entities issuing and obtaining certificates (well, unless you go with a registrar that happens to cheat on you, but at least you can avoid shady registrars and limit that possibility. Also if you registrar is that shady, they could already today switch around your nameservers or WHOIS records if only for a second and simply buy a certificate)
  - gefh 11y ago
    Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!
    - rvern 11y ago
      That's called DANE, and it's already in use by a number of websites and supported by many registries. Unfortunately the major browsers do not support it.[1] There's an extension for Mozilla Firefox that implements it.[2] [1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...
      - david_ar 11y ago
        Is there a particular reason why it's not supported?
        pilif 11y ago
        Because DNSSEC can't be trusted. Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs. Of the two evils, the CA model is slightly better because the incentives align
yuhong 11y ago
This reminds me of https://www.agwa.name/blog/post/how_to_responsibly_misissue_a_cert https://www.agwa.name/blog/post/how_to_responsibly_misissue_...
SimeVidas 11y ago
I don’t know much about how the CA system works, but “there’s something fishy going on with this CA” in conjunction with “starting with June 1st 2016” is not very reassuring.
- SolarNet 11y ago
  Well the CA in question represents a large market share of both internet and non-internet certs. You can't just top trusting them, large parts of the internet would crash and burn.
  - bigiain 11y ago
    And until that happens, why do we expect and significant portion of Symantec's customers to care? And unless they care, why would Symantec? Apple are using a Symantec ssl cert right now: "The identity of Apple Inc. at Cupertino, California US has been verified by Symantec Class 3 EV SSL CA - G3. Valid Certificate Transparency information was supplied by the server." But their level of give-a-shit is clearly demonstrated as well: "Your connection to www.apple.com is encrypted using an obsolete cipher suite. The connection uses TLS 1.2."
- politician 11y ago
  You can revoke their certificates from your root trust stores yourself on most devices.
  - kevinchen 11y ago
    Scrolling through the two PDFs linked from the post, looks like we would have to stop trusting Symantec, Thawte, VeriSign, GeoTrust, and probably a few others. Is that right?
late2part 11y ago
This is terrible. This is sad. Is it any wonder so many people have no faith in Government, in the Financial system? How much of the system we take for granted is corrupt? I'm not intending to be negative, I know I am. But for Pete's sake. This sucks sucks sucks.
systemz 11y ago
DNS certs would be better https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
pilif 11y ago
A clear example of too big to fail. If this was any smaller CA (like cnnic before), they would now be gone from the trusted roots. I wonder what's coming out of this. Personally, I think Symantec doesn't care in the least about Google's sabre rattling here. It's clear to everybody that Google hardly wants to release a browser which doesn't display 50% of the encrypted web sites. This is a further issue with the current PKI: too few CAs are around (after symantecs buying spree lately) which gives them way too much power to do what ever they want. Furthermore, the process of acquiring a certificate (especially an EV one) makes switching CAs very burdensome, so not even bad reputation will compel people to leave. What a mess.
- serendipitous 11y ago
  Symantec already agreed to start using Certificate Transparency in the near future, as per Google's request. This is a good thing.
chetanahuja 11y ago
To state the obvious (again) the third-party based trust system underlying TLS is broken. It places a massive amount of faith in a large crowd of human beings (the collective employee populations of all the CA's in the world) to behave with absolute rectitude and discipline for years and years without fail. The sad part is that all of us, collectively, trust pretty much our entire financial lives and other matters requiring secrecy and authentication to this system everyday. It's mind-boggling how we came to be in this situation. How did the entire society, including very very smart security experts came to vouch for and blindly trust this system?

260 points by fred256 11y ago

> It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. Symantec said they did an audit, Google spent 'a few minutes' and found many more mississued certificates just from the CT logs. In other words, Symantec can't audit themselves, so Google now require public issuance logs for all their certificates. > [Google] expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. This is a massive (and justifiable) smack in the face to Symantec. Disclaimer: we're a Symantec competitor, as you may have realised: https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/seal-in-search https://certsimple.com/blog/sgc-ssl-certificates https://certsimple.com/blog/sgc-ssl-certificates

sarciszewski 11y ago
Yes, and a very well-deserved one.
Sir_Cmpwn 11y ago
What is a "Point-in-time Readiness Assessment"? I googled it and found it in the requirements for some CAs, but not what it actually is.
- thenewwazoo 11y ago
  "Point-in-time" is a term of art for audit. It basically means that a third party will attest to a given state at a given time. They're in contrast to "continuous" audits, which is more focused on auditing records over a period of time, or on a recurring basis. A "point-in-time readiness assessment" is kind of redundant, but it basically means getting a third party to come look at their CA (processes, procedures, standards, implementation) and assert on Symantec's behalf that it meets some criteria.
  - Sir_Cmpwn 11y ago
    Thanks for clarifying.

bracewel 11y ago

>Symantec performed another audit and, on October 12th, announced that they had found >an additional 164 certificates over 76 domains and 2,458 certificates issued for >domains that were never registered. :|

bpolverini 11y ago

All the more reason why client-side encryption needs to become part of our daily interaction with software and cloud services.

vtlynch 11y ago
You mean client-side authentication? And how would this have helped.
- nsomaru 11y ago
  I would venture that your parent meant that we should use 'dumb' cloud services that just store encrypted data which are then retrieved and de-crypted on the client side.
  - bpolverini 11y ago
    Bingo.
    - deathanatos 11y ago
      Say you attempt to do this all in JavaScript; you've still got to deliver the page (the encryption code, really) to the user securely; otherwise, I can modify it s.t. when it gets a blob from the server and decrypts it on the client, that decrypted value is also sent off to a shady spot. You still need to get your app from you to your user securely, and how do you do that? It's the core problem really: how do you distribute your public key? How do you make sure Joe user gets the right public key? Today, we have the CA infrastructure, which admittedly isn't great, but… what would you do differently? (And the big problem is that it needs to work for average Joe.)
      - squidlogic 11y ago
        Couldn't you have a browser plugin that would verify your js is being served up from the correct source?

tshtf 11y ago

Days after the initial reports of rogue certificates being issued, Symantec wrote in their blog that they had already fired employees: In addition, we discovered that a few outstanding employees, who had successfully undergone our stringent on-boarding and security trainings, failed to follow our policies. Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process... At the end of day, we hang our hats on trust, and that trust is built by doing what we say we’re going to do. http://www.symantec.com/connect/blogs/tough-day-leaders http://www.symantec.com/connect/blogs/tough-day-leaders It's starting to look now like this the fault of systemic flaws at Symantec, and not just a few employees who didn't follow procedure.

mwsherman 11y ago
Yes, that was a very old-school way of dealing with the problem. It’s mostly symbolic. Most problems are systemic, which is a nice way of saying “ultimately management’s fault”. Most things that most people do, most of the time, are reasonable in the circumstances. Management creates the circumstances. “Human error” is a non-explanation. Here’s a book on the topic, often called systems thinking: http://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058/ref=asap_bc?ie=UTF8 http://www.amazon.com/Field-Guide-Understanding-Human-Error/... Getting even more bookish: firing “bad apples” for “human error” is a form of substituting an easier question when presented with a harder one, as Kahneman describes in Thinking Fast and Slow.
- colechristensen 11y ago
  >Most problems are systemic, which is a nice way of saying “ultimately management’s fault”. Systemic problems are _everyone_'s problems. Both management and employees are a part of the same system. Firing bad apples for human behavior is equally as pointless as firing/resigning management (or pointing fingers).
  - mwsherman 11y ago
    Fair.

evmar 11y ago

It makes me* uncomfortable that Google has effectively appointed themselves as the internet police and using their power to push people around like this. But at the same time, there is nobody else (?) who is taking care of this, and I suppose the good of someone/anyone looking into and taking action on the sorts of serious problems that Symantec has exhibited probably outweighs my discomfort. * Disclaimer: Google employee, no connection to any of this cert stuff.

detaro 11y ago
All browser vendors IMHO should do exactly this. The CAs want them to entrust them with their customers secrets, they should make sure the CAs they accept work properly.
- voltagex_ 11y ago
  I'm not sure. There's no real deliniation between Chrome and Google (as brands / entities) - this seems like Google exerting power over another company. I have no love for Symantec but it doesn't feel right. I wonder if private negotiations have failed and this is Google trying to push the point? Can you imagine if Mozilla tried the same stuff? I mean, they don't trust CACert any more after CACert wasn't able to verify itself (?) adequately, but this is on a different order of magnitude.
  - Titanous 11y ago
    Mozilla runs a root program that regularly enforces similar requirements on CAs. For example, they are currently discussing whether they will require the same of Symantec as Google or even more: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Hkyg_09EDYE https://groups.google.com/forum/#!topic/mozilla.dev.security... And here is a thread about a Chinese government CA that mis-issued certificates for Google domains: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/czwlDNbwHXM https://groups.google.com/forum/#!topic/mozilla.dev.security...
  - detaro 11y ago
    The alternative, not trusting their certs immediately instead of giving them additional requirements, would also be "exerting power over antother company". Mozilla has done so in the past, and I hope they will do so in the future. Google's argumentation that Symantec apparantly isn't able to properly assess themselves seems sound to me: if after being told about a specific issue they still are not capable of finding all instances of it happening, while outsiders can do so with the published information, then they they are missing critical abilities in this regard.

gefh 11y ago

Is the CA model just unfixably broken at this point? What should replace it if so?

0x0 11y ago
Something that sets things up so that the actual domain registrar becomes the only valid issuer of certificates for any given domain. That would kill the possibility of unrelated entities issuing and obtaining certificates (well, unless you go with a registrar that happens to cheat on you, but at least you can avoid shady registrars and limit that possibility. Also if you registrar is that shady, they could already today switch around your nameservers or WHOIS records if only for a second and simply buy a certificate)
- gefh 11y ago
  Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!
  - rvern 11y ago
    That's called DANE, and it's already in use by a number of websites and supported by many registries. Unfortunately the major browsers do not support it.[1] There's an extension for Mozilla Firefox that implements it.[2] [1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...
    - david_ar 11y ago
      Is there a particular reason why it's not supported?
      - pilif 11y ago
        Because DNSSEC can't be trusted. Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs. Of the two evils, the CA model is slightly better because the incentives align

yuhong 11y ago

This reminds me of https://www.agwa.name/blog/post/how_to_responsibly_misissue_a_cert https://www.agwa.name/blog/post/how_to_responsibly_misissue_...

SimeVidas 11y ago

I don’t know much about how the CA system works, but “there’s something fishy going on with this CA” in conjunction with “starting with June 1st 2016” is not very reassuring.

SolarNet 11y ago
Well the CA in question represents a large market share of both internet and non-internet certs. You can't just top trusting them, large parts of the internet would crash and burn.
- bigiain 11y ago
  And until that happens, why do we expect and significant portion of Symantec's customers to care? And unless they care, why would Symantec? Apple are using a Symantec ssl cert right now: "The identity of Apple Inc. at Cupertino, California US has been verified by Symantec Class 3 EV SSL CA - G3. Valid Certificate Transparency information was supplied by the server." But their level of give-a-shit is clearly demonstrated as well: "Your connection to www.apple.com is encrypted using an obsolete cipher suite. The connection uses TLS 1.2."
politician 11y ago
You can revoke their certificates from your root trust stores yourself on most devices.
- kevinchen 11y ago
  Scrolling through the two PDFs linked from the post, looks like we would have to stop trusting Symantec, Thawte, VeriSign, GeoTrust, and probably a few others. Is that right?

late2part 11y ago

This is terrible. This is sad. Is it any wonder so many people have no faith in Government, in the Financial system? How much of the system we take for granted is corrupt? I'm not intending to be negative, I know I am. But for Pete's sake. This sucks sucks sucks.

systemz 11y ago

DNS certs would be better https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

pilif 11y ago

A clear example of too big to fail. If this was any smaller CA (like cnnic before), they would now be gone from the trusted roots. I wonder what's coming out of this. Personally, I think Symantec doesn't care in the least about Google's sabre rattling here. It's clear to everybody that Google hardly wants to release a browser which doesn't display 50% of the encrypted web sites. This is a further issue with the current PKI: too few CAs are around (after symantecs buying spree lately) which gives them way too much power to do what ever they want. Furthermore, the process of acquiring a certificate (especially an EV one) makes switching CAs very burdensome, so not even bad reputation will compel people to leave. What a mess.

serendipitous 11y ago
Symantec already agreed to start using Certificate Transparency in the near future, as per Google's request. This is a good thing.

chetanahuja 11y ago

To state the obvious (again) the third-party based trust system underlying TLS is broken. It places a massive amount of faith in a large crowd of human beings (the collective employee populations of all the CA's in the world) to behave with absolute rectitude and discipline for years and years without fail. The sad part is that all of us, collectively, trust pretty much our entire financial lives and other matters requiring secrecy and authentication to this system everyday. It's mind-boggling how we came to be in this situation. How did the entire society, including very very smart security experts came to vouch for and blindly trust this system?