[tor-talk] How evil is TLS cert collection?

[Robert Ransom]

On Tue, 21 Jun 2011 11:20:07 -0700
Mike Perry <mikeperry at fscked.org> wrote:

> Thus spake tagnaq (tagnaq at gmail.com):
> 
> > Well, after all I guess we can acknowledge that there are scenarios
> > where information disclosures will happen.
> 
> Ok, I probably should recap these scenarios here. I realized I forgot
> to reply to you.
> 
> To make sure we understand one another (and everyone else understands
> us): the remaining information disclosure scenarios we're talking
> about are limited to two:
> 
> 1. User has a private network whose DNS is set to resolve private
> names to public IP addresses which normally would not have been
> reachable in the IPv4 scan, and whose TLS certs are also signed by a
> public trusted root CA. This is a weird setup, but it's a big world.
> I guess it could exist somewhere.
> 
> 2. User has private network on RFC 1918 space, yet uses an HTTP proxy
> to access it (which means we can't tell that it is private IP space).
> Said user is also using TLS certs signed by a public trusted root CA.
> This config is less weird, and detectable by us. It makes me think we
> should handle this user specially somehow?

This could occur with a SOCKS proxy, too (such as that run by ‘ssh
-D’), since there is no standard way to ask a SOCKS proxy to resolve a
hostname to an IP address.  (Tor allows this using a non-standard
extension to SOCKS.)


> Your point is that in these two cases, with the default protection
> mechanisms defined in
> https://trac.torproject.org/projects/tor/wiki/doc/HTTPSEverywhere/SSLObservatorySubmission
> these two users could still end up sending their public-yet-private
> certs to EFF.

Yes.

> Should we somehow warn the HTTP proxy user about the possibility of
> private TLS certs being submitted if they try to opt-in to the
> feature?

Maybe.  I doubt that users with configuration 2 will opt in to SSL
certificate submission without reading all of the documentation they
can find, and configuration 1 seems more likely to occur during an
attack than in a deployed intranet.

> > To give users the possibility to contribute while preventing leaks for
> > specific domains they are concerned it would be great if the submission
> > addon would have a blacklist feature where one could say
> > never submit anything for  *.example.com.
> 
> This seems to be a reasonable option to me. I've added this to our
> spec page above.
> 
> But is there a better option? Do you think it might be likely that
> either of these users will disable OCSP for these certs, or otherwise
> indicate anything about these public-yet-private certs that we can
> detect in their config?

There is no better option than a user-specified domain blacklist.  Any
attempt to automatically detect these private certificates and avoid
submitting them will defeat the most important purpose of the
distributed SSL observatory project: detecting SSL MITM attacks.


Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20110621/d92d3905/attachment.pgp>