These domains belong to someone. Someone who likely hasn't agreed. It's deeply troubling when a CA says: "We'll just issue some test certs for domains that sound like we could use them for testing - no matter whom they belong to and if they agree to that."
It's quite simple: Don't issue certs unless the owner of that domain has asked you for it.
But if you look closer at Andrew's mail: There were a bunch of other certs for all kinds of domains.
It's not about these particular certificates, it's about the fact that Symantec issued obviously bogus certificates at all, and then that they either didn't catch it or they caught it and decided to try not to tell us about it.
Even at best this is further evidence of incompetence, and incompetence certainly does threaten the integrity of the encrypted Web.
Ask yourself, if Symantec's "security" systems can issue for example.com without getting consent from the owner of example.com and Symantec don't notice, why not for your domain, or mine, or a big bank?
Symantec was caught because they were already on the naughty list. I wonder how many other authorities around the globe are not caught simply because they are not scrutinized as much.
Sigh, this whole cert business is so broken, and still we don't have anything else to replace it with.
> Symantec was caught because they were already on the naughty list. I wonder how many other authorities around the globe are not caught simply because they are not scrutinized as much.
Instead of wondering you could also help checking. All the data Andrew Ayer used is public.
For EV CAs are already required to submit them to CT. Soon this requirement will be extended to all certs (October 2017).
In practice almost all certificates are already in a CT log, because the google crawlers submit them. But you're right: If it's about certificates purely generated for test purposes it could be that CAs that don't do CT yet can hide that.
Or if it's a second cert generated for somebody else's site (like the example.com was), and only used for targeted MITM, then it likely won't ever make it into to CT either. I.e. the actual bad certs won't make it in there unless there's required posting to CT.
Is there a way to revoke a cert without knowing the actual signature? For example, if there are holes in the serial number sequence, does any current revocation scheme allow revoking that number, or, any serial numbers that have not yet been submitted to CT?
OCSP and CRLs both work based on specific serial numbers. Serial numbers are not really sequential either (a portion of it has to be random).
The closest thing to what you're describing would be the Expect-CT HTTP header[1] which can be used by site operators to instruct browsers to always expect a CT-logged certificate from the site (or more specifically, to expect qualified SCTs to be provided for the site's certificate). I believe this feature is planned for Chrome 58 if I'm reading the ticket correctly[2]. Presumably, this will be available as a preloaded flag for domains at some point as well (like HSTS preloading).
> The listed Symantec certificates were issued by one of our WebTrust audited
partners. We have reduced this partner's privileges to restrict further
issuance while we review this matter. We revoked all reported certificates
which were still valid that had not previously been revoked within the 24
hour CA/B Forum guideline - these certificates each had "O=test". Our
investigation is continuing.
So Symantec are letting third parties issue certificates using their root? Seems like a pretty bad idea when it's their own reputation that is on the line here. And also don't we have a system in place for that by using intermediary CAs that wouldn't require the certificates to be issued directly by Symantec?
First up I will nitpick. The certificates were issued from an Intermediate, "Symantec Class 3 Secure Server CA - G4" not from a root. Hopefully Symantec keeps all the actual roots safely physically off-line in smart cards or similar devices locked in a vault.
Now, not to excuse them of anything (I shall be jumping up and down in m.d.s.policy once they write up something more substantive) I shall try to explain what they're on about
Older public CAs (and Symantec is in effect the oldest, having inherited Thawte and Versign roots) have this complicated structure with resellers and affiliates under different contracts and with varying responsibilities. Particularly for the facts about organisations, like their official address, the registered name and so on, a local business can understand things better than some remote North American corporation. So it can make sense rather than trying to build out subsidiaries in every country to instead find a partner to do that stuff.
Likewise it used to be common to out-source domain validation to third parties who were already in the domain naming game, such as registrars or hosting companies.
Now, Symantec _should_ be keeping a firm rein on these things and exercising vigilance to ensure it knows what these partners / affiliates are doing in its name. But it's much harder to do that well than to have a much simpler setup where you can see all the moving parts for yourself and reason about the whole system.
20 comments
[ 1.7 ms ] story [ 77.7 ms ] threadBut if you look closer at Andrew's mail: There were a bunch of other certs for all kinds of domains.
Sloppy is an oopsy. This is negligence.
1. Use domains they own.
2. Use a testing environment that doesn't issue publicly-trusted certificates.
Even at best this is further evidence of incompetence, and incompetence certainly does threaten the integrity of the encrypted Web.
Ask yourself, if Symantec's "security" systems can issue for example.com without getting consent from the owner of example.com and Symantec don't notice, why not for your domain, or mine, or a big bank?
Sigh, this whole cert business is so broken, and still we don't have anything else to replace it with.
Instead of wondering you could also help checking. All the data Andrew Ayer used is public.
For EV CAs are already required to submit them to CT. Soon this requirement will be extended to all certs (October 2017).
In practice almost all certificates are already in a CT log, because the google crawlers submit them. But you're right: If it's about certificates purely generated for test purposes it could be that CAs that don't do CT yet can hide that.
Is there a way to revoke a cert without knowing the actual signature? For example, if there are holes in the serial number sequence, does any current revocation scheme allow revoking that number, or, any serial numbers that have not yet been submitted to CT?
The closest thing to what you're describing would be the Expect-CT HTTP header[1] which can be used by site operators to instruct browsers to always expect a CT-logged certificate from the site (or more specifically, to expect qualified SCTs to be provided for the site's certificate). I believe this feature is planned for Chrome 58 if I'm reading the ticket correctly[2]. Presumably, this will be available as a preloaded flag for domains at some point as well (like HSTS preloading).
[1]: https://tools.ietf.org/html/draft-stark-expect-ct-01
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=679012
I wonder what excuses we'll here this time, and if we'll lose a CA in the process.
So Symantec are letting third parties issue certificates using their root? Seems like a pretty bad idea when it's their own reputation that is on the line here. And also don't we have a system in place for that by using intermediary CAs that wouldn't require the certificates to be issued directly by Symantec?
Now, not to excuse them of anything (I shall be jumping up and down in m.d.s.policy once they write up something more substantive) I shall try to explain what they're on about
Older public CAs (and Symantec is in effect the oldest, having inherited Thawte and Versign roots) have this complicated structure with resellers and affiliates under different contracts and with varying responsibilities. Particularly for the facts about organisations, like their official address, the registered name and so on, a local business can understand things better than some remote North American corporation. So it can make sense rather than trying to build out subsidiaries in every country to instead find a partner to do that stuff.
Likewise it used to be common to out-source domain validation to third parties who were already in the domain naming game, such as registrars or hosting companies.
Now, Symantec _should_ be keeping a firm rein on these things and exercising vigilance to ensure it knows what these partners / affiliates are doing in its name. But it's much harder to do that well than to have a much simpler setup where you can see all the moving parts for yourself and reason about the whole system.