
Symantec issues more illegit HTTPS certificates - 0xbadf00d
http://arstechnica.co.uk/security/2017/01/already-on-probation-symantec-issues-more-illegit-https-certificates/
======
aleksi
In the same time, [https://arstechnica.co.uk/](https://arstechnica.co.uk/)
redirects to [http://](http://).

------
toyg
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
> 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
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
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
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?

~~~
pfg
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).

[1]: [https://tools.ietf.org/html/draft-stark-expect-
ct-01](https://tools.ietf.org/html/draft-stark-expect-ct-01)

[2]:
[https://bugs.chromium.org/p/chromium/issues/detail?id=679012](https://bugs.chromium.org/p/chromium/issues/detail?id=679012)

------
jwilk
Duplicate of
[https://news.ycombinator.com/item?id=13447349](https://news.ycombinator.com/item?id=13447349)

------
tetrep
Symantec is investigating:
[https://groups.google.com/forum/#!topic/mozilla.dev.security...](https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/fyJ3EK2YOP8)

I wonder what excuses we'll here this time, and if we'll lose a CA in the
process.

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

~~~
tialaramex
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.

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

~~~
hannob
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
Especially when we have TLDs for this purpose (.test and .invalid), it's just
plain sloppy.

~~~
agwa
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.

