I'm glad to see discussions of tools. Some points to consider:

1) How to exclude domains from the search? For example I want to find gmail 
certs but exclude something like "eggmail" which could be a false positive.

2) ‎How to address wild cards? For example can I bypass these detection tools 
by issuing a cert for "*[dot]innocentdomain[dot]com" instead of 
"gmail[dot]innocentdomain[dot]com"?

3) How frequently might such tools run? Or to put it differently, how much time 
do I probably have between when I issue a gmail cert and when someone figures 
it out (and of course how much longer before my illegitimate cert is no longer 
valid)? I need only 24 hours to do all the damage I want, but in a pinch I'll 
make do with 8.

4) What's the expected model for a third-party monitor? Who might the 
organizations be and how might the monitoring be funded?

5) What's the anticipated adoption rate for CT monitoring? 1% of all domains? 
0.1%? What about the monitoring for *all* domains that the top 1,000 web sites 
own (I'm thinking of CDNs and ancillary services)?

In a way the SSL Labs service is a perfect example of the limitations of a 
monitoring service. Their SSL Pulse found an awful lot of servers with ‎a 
failing grade.


  Original Message  
From: Hubert Kario
Sent: Tuesday, June 9, 2015 5:05‎

On Tuesday 09 June 2015 10:44:58 Rob Stradling wrote:
> On 09/06/15 04:05, Clint Wilson wrote:
> > To further support your claims here, Chris, there are already tools coming
> > out which actively monitor domains in CT logs and can be set up with
> > notifications of misissuance:
> > https://www.digicert.com/certificate-monitoring/
> > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EPv_u9
> > V06n0
> > 
> > This type of tool for CT is only going to improve with time.
> 
> If you act as a CT monitor yourself, you can be sure that the logs
> aren't misbehaving. But if you rely on a third party to monitor the
> logs for you, you have to trust that third party.

True, OTOH, if a third party says that there was a misissuance, that means 
there was one.

> Therefore, ISTM that some domain owners might want to be able to use the
> services of multiple independent monitors simultaneously.
> 
> So I'm wondering if the TRANS WG should think about standardizing a JSON
> API for searching CT logs and for setting up notifications of
> (mis-)issuance. The server side of this API could be implemented by
> services such as https://crt.sh or even directly by the logs themselves.

yes, definitely. Having a service like ssllabs.com inform the user if a given 
domain uses a public key used somewhere else, or that there are "n" other 
certificates for a given domain name would be definitely useful. Command line 
tools have exact same situation.

Having a common API across multiple CT logs would definitely make the above 
more robust.‎
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to