On 11/08/17 16:40, Nick Lamb via dev-security-policy wrote:
On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote:
Given that these were all caught by cablint, has Let's Encrypt considered
integrating it into your issuance pipeline, or automatically monitoring
crt.sh (which runs cablint) for these issues so they don't need to be
caught manually by researchers?
The former has the risk of being unexpectedly fragile, the latter puts a bunch
of work on crt.sh which (even if Rob says it's OK) is a bit out of order.
I would suggest that Let's Encrypt could automatically run cablint on some fraction of
just issued certificates (where "some fraction" might be 100% if they've got
the resources) and summarise the output for internal review. They're obliged to keep all
the certificates they've just issued online by their own system design (ACME offers to
deliver the certificate again if you ask for it) anyway.
This way: If cablint breaks, or won't complete in a timely fashion during high
volume issuance, it doesn't break the CA itself. But on the other hand it also
doesn't wail on Comodo's generously offered public service crt.sh.
Also, while on the subject I commend to any researchers at least as interested
in the contents of the CT logs as myself the building of an actual Log Monitor
of their own rather than relying on crt.sh. This is for several reasons, off
the top of my head:
1. The Logs have anti-tamper features, but if only Comodo (and Google) look at
the Logs themselves then we miss out on much real benefit from those features
because we will never actually detect any tampering, we'd have to be told about
it by someone we trust.
+1. I trust me, but it bothers me that everyone else has to trust me
too. :-)
Also, crt.sh doesn't yet verify the Merkle Tree stuff when fetching
entries from the logs.
2. The Logs are obliged to achieve reasonable performance to hit Google's
targets and will accordingly have been built to be robust, Rob has put lots of
effort into crt.sh but it definitely has... off days.
Such as today, during which Comodo has been the target of a DoS attack
that's affected many of our services (including crt.sh and our CT logs
:-( ).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
