On Wednesday, August 31, 2016 at 10:07:19 AM UTC-7, watso...@gmail.com wrote:
> Dear Richard,
>
> It's clear WoSign has continuing compliance issues with CA/Browser forum
> rules, and has repeatedly failed to correct them. Furthermore there has been
> lots of questions about what it would take to improve CA practices given the
> degree of incompetence some have practiced, and it's clear penalties would go
> a long way.
>
> Is there a reason we shouldn't permanently ban WoSign, and all CAs controlled
> by people involved with it, from the root program?
For how long?
> It seems clear that WoSign has been misleading its auditors repeatedly and
> has insufficient tracking of which certificates are issued, has been aware of
> these problems for years, and has not been forthright in addressing them.
These are all very compelling arguments.
> Making an example would do a lot to encourage better CA behavior in general.
This is less compelling, because "making an example" seems a subjective
judgement/punitive response, although you to clarify "to encourage better CA
behaviour".
At present, it looks like there's around 60K (active, valid) WoSign certs
presently logged in CT logs, either through WoSign's logging or through
secondary sources (such as Google's crawling). Richard has indicated that
WoSign issued around 115K certificates in 2015 alone, but it's unclear how much
overlap that would have; if we assume the worst case, and that they're all
unique certs not previously before seen/logged (for example, perhaps due to the
Great Firewall causing difficulty for Google's crawler), and if we generously
extrapolate the same amounts for 2014, and take a quarter of that for 2013
certs that could still be valid within the 39 month window, we end up with an
"Extreme Worst Case" of 319K certs. While I suspect the number if likely much
lower, especially when considering when WoSign switched to SHA-2 (as the SHA-1
certs will be invalid by January 1, 2017), let's operate on two assumptions:
1) "Best Case" of say, ~200K valid certs
2) "Worst Case" of, say, ~319K valid certs
If browser vendors/root stores move to distrust WoSign, all of these certs
would be invalidated. We know that a number of sites within the Alexa Top 1M
are (intentionally) using WoSign, so we can expect a large number of users,
across browser vendors, are accessing these sites, and would thus be seeing a
significant amount of SSL/TLS error pages if the CA was distrusted. We know
that major platform providers (such as Microsoft Azure) have partnered with
WoSign as well, and thus further suggest a larger than desired user impact.
Setting aside for a second whether or not distrusting is the right action,
let's think about what possible responses.
A) Remove the CA. Users may manually trust it if they re-add it, but it will
not be trusted by default.
B) Actively distrust the CA. Even if manually added (by user or enterprise
policy), it will not be trusted.
C) Remove the CA. Develop a whitelist of pre-existing certificates to be
trusted.
- What form should this whitelist take?
* Shipping it in the binary is unacceptably large.
* Downloading it in full on demand is unacceptably large/unreliable.
* Checking with a central server for serial number can lead to misleading
results (WoSign has shown they issue duplicate serials, and nothing would
prevent them from doing so in the future)
* Checking with a central server for certificate hash may have privacy
considerations.
* Conclusion: Something SafeBrowsing-like would have to be developed (
https://developers.google.com/safe-browsing/v4/ ), which could be months away.
D) Distrust any certificate without appropriate CT information. Whitelist certs
before 2016.
- See whitelist problems above
E) Distrust certs without appropriate CT information, wholesale.
- Note: It appears that WoSign is or has had similar issues to Symantec,
failing to log to a diverse-enough set of logs to ensure a robust CT
implementation. A quick and random sampling shows, for example, that
precertificates are only being logged to Google logs (such as for 8-30-16).
Thus, unless an implementation is willing to fully trust Google CT logs alone -
something Google themselves are unwilling to do - then this suggests that this
may be the same as wholesale distrusting.
In effect, a number of these options boil to a set of concerns:
- Distrusting can be significantly disruptive to end-users, potentially
habituating them to SSL warnings or errors
- Distrusting potentially could interfere with those who may still want to
trust WoSign manually, themselves
- Distrusting in a way that minimizes disruption has concerns for privacy,
stability, or timeliness.
I'm not trying to suggest that distrusting is right or wrong, but I am curious
for those who would advocate distrusting how browser vendors, such as Google
and Mozilla, for example, might appropriately balance the concerns of the
broader community, while also minimizing any damage, particularly to their
users, and avoiding any reactionary responses.
It would seem like a form of whitelist (whether to continue trusting WoSign
with CT enablement, or distrusting but grandfathering in disclosed certs, ala
CNNIC) would require active development and assistance from the broader
security and privacy community on how best to balance and scale such concerns,
and regardless, would take time to implement, test, and deploy, but would be
useful and possibly scalable for other future CA incidents. However, are there
alternatives or concerns that I omitted from the above list?
In either event, hopefully this thought experiment brings into light the set of
concerns that vendors, such as Mozilla and Google, may have to consider, and
may help find an appropriate response that reflects the gravity of these
incidents, and the handling of them, and may spark the community for ideas and
solutions that can help balance those needs.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
