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

[tagnaq <tagnaq@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Mike Perry wrote:
> 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.

Yes, this is the scenario I was concerned about.

> 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?

> 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.
> 
> 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?

I would suggest the following:
- - user opts-in
- - addon performs check if host can resolve hostnames to IPs (possible?)
- - if it can't and the first adv. option isn't enabled, tell the user
that the addon will not do anything, but still give the user the
possibility to override this default check-and-disable procedure

the next question would be: is the addon doing periodic checks to see if
the situation changed?


>> > 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.

Thank you for the inclusion of this feature.

> 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?
> 
> And is there anything else?

Another feature request just came to my mind: (actually it became more
than just one)
[ ] do not submit the IP address (server_ip argument) for private DNS
domains
(submits: '-2')
[ ] do not submit the IP address for the following private DNS domains
	[input field]

I see this useful in the following scenario:
The user is fine with submitting certificates that would fall into the [
] Check/submit certificates for private DNS domains
option, but doesn't want to disclose the internal IP addresses.
The new option is only available when the user enables the submission of
certificats for private DNS domains.

Or you submit -2 by default for private DNS domains (if he enabled the
submission for private DNS domains) and give the user the possibility to
further opt-in and say: "I'm fine with submitting the IP address for
private DNS domains" (this would probably be the better way from a
privacy point of view but will result in less people submitting that data)


I don't know if you find submissions with empty domain argument
valuable, but if you do, you could also consider adding an option like:
[ ] do not submit the hostname (domain argument) for private DNS domains.
[ ] do not submit the hostname for the following private DNS domains:
	[input field]

One might argue, the hostname is also included in the certificate (CN),
but this is not always the case (wilcard certificate).

Giving the users fine grained possibility about what they disclose might
result in more users willing to participate, but I totally agree to keep
them in an "expert section" because non-technical users might be
confused by these options.
These options give a "experts" the possibility to disclose more if they
are fine with that.


-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAk4BCakACgkQyM26BSNOM7b6KgEAlepwfgenzJLP5VaPWi8bIgnh
s1K88Ipz4XSwbqG9YhcBAIfn3M0EARvvZUiB0cJy3wloBKJ0noj6QGro9oQgKaqi
=/zwt
-----END PGP SIGNATURE-----
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk