4 ms·

Symantec issues more illegit HTTPS certificates

104 points by 0xbadf00d 10y ago

aleksi 10y ago
In the same time, https://arstechnica.co.uk/ https://arstechnica.co.uk/ redirects to http:// http://.
paralelogram 10y ago
How does issuing certificates for test1.com, test2.com, test3.com etc. "threaten the integrity of the encrypted Web"?
- hannob 10y ago
  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.
  - cube00 10y ago
    Especially when we have TLDs for this purpose (.test and .invalid), it's just plain sloppy.
    - JumpCrisscross 10y ago
      > * it's just plain sloppy* Sloppy is an oopsy. This is negligence.
    - agwa 10y ago
      CAs would not be allowed to use those TLDs under the current rules. They have two options for testing: 1. Use domains they own. 2. Use a testing environment that doesn't issue publicly-trusted certificates.
- tialaramex 10y ago
  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?
- deleted 10y ago
  [deleted]
- borplk 10y ago
  How does it not threaten the integrity of the encrypted Web?
toyg 10y ago
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.
- hannob 10y ago
  > 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.
  - azdle 10y ago
    Except, most CAs aren't required to publish all certs to CT. Symantec is specifically required to because of hanky-panky in their past.
    - hannob 10y ago
      It's a bit more complex, but you have a point. 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.
      - epistasis 10y ago
        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?
jwilk 10y ago
Duplicate of https://news.ycombinator.com/item?id=13447349 https://news.ycombinator.com/item?id=13447349
tetrep 10y ago
Symantec is investigating: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/fyJ3EK2YOP8 https://groups.google.com/forum/#!topic/mozilla.dev.security... I wonder what excuses we'll here this time, and if we'll lose a CA in the process.
- poizan42 10y ago
  > 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?
  - paulddraper 10y ago
    Yes, I don't get that. What justification is there for another party signing with your root?
    - tialaramex 10y ago
      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.

104 points by 0xbadf00d 10y ago

aleksi 10y ago

In the same time, https://arstechnica.co.uk/ https://arstechnica.co.uk/ redirects to http:// http://.

paralelogram 10y ago

How does issuing certificates for test1.com, test2.com, test3.com etc. "threaten the integrity of the encrypted Web"?

hannob 10y ago
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.
- cube00 10y ago
  Especially when we have TLDs for this purpose (.test and .invalid), it's just plain sloppy.
  - JumpCrisscross 10y ago
    > * it's just plain sloppy* Sloppy is an oopsy. This is negligence.
  - agwa 10y ago
    CAs would not be allowed to use those TLDs under the current rules. They have two options for testing: 1. Use domains they own. 2. Use a testing environment that doesn't issue publicly-trusted certificates.
tialaramex 10y ago
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?
deleted 10y ago
[deleted]
borplk 10y ago
How does it not threaten the integrity of the encrypted Web?

toyg 10y ago

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.

hannob 10y ago
> 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.
- azdle 10y ago
  Except, most CAs aren't required to publish all certs to CT. Symantec is specifically required to because of hanky-panky in their past.
  - hannob 10y ago
    It's a bit more complex, but you have a point. 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.
    - epistasis 10y ago
      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?

jwilk 10y ago

Duplicate of https://news.ycombinator.com/item?id=13447349 https://news.ycombinator.com/item?id=13447349

tetrep 10y ago

Symantec is investigating: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/fyJ3EK2YOP8 https://groups.google.com/forum/#!topic/mozilla.dev.security... I wonder what excuses we'll here this time, and if we'll lose a CA in the process.

poizan42 10y ago
> 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?
- paulddraper 10y ago
  Yes, I don't get that. What justification is there for another party signing with your root?
  - tialaramex 10y ago
    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.