On 2016-09-05 22:37, Percy wrote:
In page 11, you mentioned that "System blocked many illegal request every day, the
following screen shot is the reject order log", in which you attached a log with
Google, Microsoft, QQ domains. Those domains are rejected because of the top domain
whitelist. Does that mean those attempts passed your automatic validation and were only
rejected because of the whitelist?
And as Kurt pointed out, for the flag, why does it happen only AFTER the
certificate is already issued? Since you specifically have the whitelist for
topdomains, you would know mis-used of such certs have particularly high
impacts.
I think that was a misunderstanding on my part. In the other e-mail I
send I came to the conclusion that what probably happened was that they
were flagged for manual review and approved. And so that there really is
something wrong with the manual review process. Their solution to that
was to move "github.com" from manual review to reject.
The document really is hard to follow and seems to more concentrate on
defending themselves, how fast they are and show that they do prevent
some certificates from being issued. What I'm looking for is just the
facts of what happened, why this happened, what is being done to prevent
this in the future.
My current understanding of what happened with the github.com case is:
- It's possible that the list of hostnames is changed between the point
of validation and the user pressed the "submit request" button. This
change can be caused by both the software adding other hostnames itself,
or the user adding new hostnames. I understand that when the user
pressed the button a CSR is generated.
- Once the CSR is generated, it's trusted that the list of hostnames in
it have been validated, which might not be the case.
- Because gibhub.com is in the list of hostnames that needs to be
checked, it's flagged for review.
- The manual review just approved it.
What I think is wrong:
- There is no check that the hostnames have been validated after the CSR
has been generated.
- Too many github.com certificates get flagged for manual review causing
the reviewers to not look careful and just approve it. The fix they
used is to reject "github.com" itself instead of flagging it for review.
They should probably also flag less things for review (probably after
talking to github.)
Looking at Figure 13, the first entry says it has 4 SANs in it, but
claims only 1 was validated and 1 was not validated, what happened to
the other 2?
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
