5 ms·

It's just insane that they haven't been able fix this issue and get back into good standing with 6 months warning.

mtgx 8y ago
They've already sold the division. They don't care and probably never did.
spydum 8y ago
Sold and DigiCert has been reissuing new certs. Unfortunately they can’t change them for you. Poor operators won’t know until the rug is finally pulled from under them. DigiCert and browser vendors have done a decent job of telegraphing the changes..
klodolph 8y ago
> Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization. Source: https://sslmate.com/certspotter/failures https://sslmate.com/certspotter/failures “Willfully” is the key word here. The business side of running a CA is fundamentally at odds with the security side. A few short-sighted decisions by business-minded managers with their eyes set on profits can completely eviscerate the security side of a company, and it’s possible that nobody remains at Symantec who has the combination of security knowledge + internal political power + will. There’s also the Trustico fiasco. Trustico revoked 50,000 Symantec-issued certificates in a shockingly bad way. Because policies allowed for certificates with compromised public keys to be revoked, Trustico intentionally compromised the private keys in order to achieve the desired revocation. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wxX4Yv0E3Mk https://groups.google.com/forum/#!topic/mozilla.dev.security... > As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with. You can see more bad behavior here—Symantec is seen as a reckless company, and Trustico (recklessly) cuts ties with Symantec for its business needs. Both actors are bad enough that their relationship reflects poorly on both of them. I’m sure there are some people who could fix this problem in six months, but I bet they don’t work for Symantec or don’t have the power to do it.
- pitaj 8y ago
  > The business side of running a CA is fundamentally at odds with the security side. Well, as we're seeing here, they can only be out of phase to a certain degree before both suffer.
gsnedders 8y ago
Given how wide-spread the issues were, I'm not surprised that they couldn't turn it around within six months, even if they had the will from management to do so (which it isn't clear they did!).
olliej 8y ago
The problem is that they repeatedly mismanaged and violated the BRs. There’s only so many screw ups you can accept from a CA before you simply can’t trust them to do the right thing. Given that Trust is the basis of the entire CA system there isn’t really an option but to distrust the CA. Note that multiple CAs have been distrusted in the past, and they were more or less instantaneous distrust. Symantec was a huge CA, and that got them through multiple errors that would have probably resulted in distrust for smaller CAs, and even the final distrust has had something like a years notice.
- munchbunny 8y ago
  Pardon my ignorance, but what does "BR" stand for?
  - stanleydrew 8y ago
    Pretty sure it refers to "Baseline Requirements" as specified by the CA Browser Forum. https://en.m.wikipedia.org/wiki/CA/Browser_Forum https://en.m.wikipedia.org/wiki/CA/Browser_Forum
    - tobz 8y ago
      You beat me to it! :) https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/
  - deleted 8y ago
    [deleted]
dboreham 8y ago
Just to be clear : there is no "fix this issue" because the problem is with certs issued _in_the_past_. The only fix is to re-issue the cert and replace the existing one on servers with the new one. This fwiw is easy to do, if you know you need to do it. But then presumably folks running SSL endpoints already knew they had to keep on top of expiry dates, cipher suites and so on so this is just one extra aspect to watch out for. Explicitly tested and reported via ssllabs, of course.
__jal 8y ago
The base issue is trust, not some technical issue. They repeatedly violated the trust placed in them. They'd have to fire the entire chain of command that allowed those to happen, retool their processes, and probably post a sizable bond before many folks would give them a second chance. But really, who needs them? We need fewer registries, or in the alternative many, many, many more.

mtgx 8y ago

They've already sold the division. They don't care and probably never did.

Sold and DigiCert has been reissuing new certs. Unfortunately they can’t change them for you. Poor operators won’t know until the rug is finally pulled from under them. DigiCert and browser vendors have done a decent job of telegraphing the changes..

klodolph 8y ago

> Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization. Source: https://sslmate.com/certspotter/failures https://sslmate.com/certspotter/failures “Willfully” is the key word here. The business side of running a CA is fundamentally at odds with the security side. A few short-sighted decisions by business-minded managers with their eyes set on profits can completely eviscerate the security side of a company, and it’s possible that nobody remains at Symantec who has the combination of security knowledge + internal political power + will. There’s also the Trustico fiasco. Trustico revoked 50,000 Symantec-issued certificates in a shockingly bad way. Because policies allowed for certificates with compromised public keys to be revoked, Trustico intentionally compromised the private keys in order to achieve the desired revocation. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wxX4Yv0E3Mk https://groups.google.com/forum/#!topic/mozilla.dev.security... > As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with. You can see more bad behavior here—Symantec is seen as a reckless company, and Trustico (recklessly) cuts ties with Symantec for its business needs. Both actors are bad enough that their relationship reflects poorly on both of them. I’m sure there are some people who could fix this problem in six months, but I bet they don’t work for Symantec or don’t have the power to do it.

pitaj 8y ago
> The business side of running a CA is fundamentally at odds with the security side. Well, as we're seeing here, they can only be out of phase to a certain degree before both suffer.

gsnedders 8y ago

Given how wide-spread the issues were, I'm not surprised that they couldn't turn it around within six months, even if they had the will from management to do so (which it isn't clear they did!).

olliej 8y ago

The problem is that they repeatedly mismanaged and violated the BRs. There’s only so many screw ups you can accept from a CA before you simply can’t trust them to do the right thing. Given that Trust is the basis of the entire CA system there isn’t really an option but to distrust the CA. Note that multiple CAs have been distrusted in the past, and they were more or less instantaneous distrust. Symantec was a huge CA, and that got them through multiple errors that would have probably resulted in distrust for smaller CAs, and even the final distrust has had something like a years notice.

munchbunny 8y ago
Pardon my ignorance, but what does "BR" stand for?
- stanleydrew 8y ago
  Pretty sure it refers to "Baseline Requirements" as specified by the CA Browser Forum. https://en.m.wikipedia.org/wiki/CA/Browser_Forum https://en.m.wikipedia.org/wiki/CA/Browser_Forum
  - tobz 8y ago
    You beat me to it! :) https://cabforum.org/baseline-requirements-documents/ https://cabforum.org/baseline-requirements-documents/
- deleted 8y ago
  [deleted]

dboreham 8y ago

Just to be clear : there is no "fix this issue" because the problem is with certs issued _in_the_past_. The only fix is to re-issue the cert and replace the existing one on servers with the new one. This fwiw is easy to do, if you know you need to do it. But then presumably folks running SSL endpoints already knew they had to keep on top of expiry dates, cipher suites and so on so this is just one extra aspect to watch out for. Explicitly tested and reported via ssllabs, of course.

__jal 8y ago

The base issue is trust, not some technical issue. They repeatedly violated the trust placed in them. They'd have to fire the entire chain of command that allowed those to happen, retool their processes, and probably post a sizable bond before many folks would give them a second chance. But really, who needs them? We need fewer registries, or in the alternative many, many, many more.