On Tue, 21 Jun 2011 11:20:07 -0700 Mike Perry <mikeperry@xxxxxxxxxx> wrote: > Thus spake tagnaq (tagnaq@xxxxxxxxx): > > > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk