Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > On Tue, 21 Jun 2011 11:20:07 -0700 > Mike Perry wrote: > > > 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.) Ugh, sorry. You've said this a couple times now, but each time I had assumed that when OpenSSH added SOCKS4A+5, they also added this extension. Turns out you are right, they did not. You still can't do resolutions, so this type of SOCKS proxy is the same as an HTTP Proxy in that respect.. Ugh. > > > 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. Yes, the added attack potential worries me too. Does this tradeoff mean we should turn on "[ ] Check/submit certificates for private DNS domains" by default? I think it might. The answer depends on if we prioritize providing protection over automatically withholding info that may be private. It is my feeling that since this feature is meant to be opt-in, we should prioritize security. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpNT6sJzLzGd.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Tue, 21 Jun 2011 11:20:07 -0700 Mike Perry wrote: > Thus spake tagnaq (tag...@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 signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake tagnaq (tag...@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? 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? > 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? And is there anything else? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpphECxwUEv1.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Well, after all I guess we can acknowledge that there are scenarios where information disclosures will happen. 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. -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3qswIACgkQyM26BSNOM7aAcQD+JS078EttKKcUMK22blcwrqjZ DfeHjMMhGK6imblxAZEA/AimrKqZAvOPkL5zkA+7j2mmhgbCABeocUxtxxK6Wtkn =UL9T -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sat, 4 Jun 2011 12:56:15 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > On Sat, 4 Jun 2011 12:09:52 -0700 > > Mike Perry wrote: > > > > > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > > > > My understanding was that EFF would query DNS for a hostname, and if > > > > the hostname does not exist, assume that it's private. (This should > > > > scare you even more.) > > > > > > EFF only needs to do this query if the browser could not (because it > > > was using an HTTP proxy without a SOCKS proxy). Does this scare you > > > less or more? I'm getting confused by the reactions in this thread. > > > > If EFF needs to perform a DNS query on each hostname it receives a > > certificate for, EFF will leak information to an attacker watching its > > servers. If EFF tries to not log hostnames which do not exist, EFF > > will leak a user's request time *every time* that it receives a > > certificate associated with a non-existent hostname. > > I think you missed the first half of my email where I explicitly said > EFF shouldn't need to do this under normal circumstances. It only > needs to do this when the browser fails to do so itself. Do you expect > this to be common? Firefox cannot resolve hostnames to IP addresses when it is using *any* proxy. Anyone who uses an SSH tunnel as a SOCKS to connect to an intranet will risk this leakage, and SSH tunnels can be made fairly easy to use. I have no information on how widely used that configuration is. > The observatory itself could also be running a tor client for these > resolutions, just in case they do end up being common. That would be a Good Thing, just to decrease the incentive for attackers to monitor EFF's Internet connection. > P.S. When the browser does attempt to do these resolutions, should > they be done via Tor or via whatever local resolver/proxy was used to > access the domain? Doing it via Tor exposes potentially private names > to exits, but doing it locally will fail to detect attacks where the > MITM is able to operate on the user's own infrastructure (because they > can just make sure that the domains they MITM resolve to RFC1918). Either way, the attacker wins -- if you resolve hostnames over Tor, the attacker can use a homoglyph or near-homoglyph of a target hostname for its attack, and simply not allow DNS servers accessible outside its victim network to see the attack hostname. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/04/2011 12:37 PM, tagnaq wrote: > IP address and hostname (and cert.) of intranet-server1.example.com > using a valid certificate *.example.com will be published even if the > first two options in the "advanced options" are enabled. Is that correct? > In such scenarios I'm not worried about the certificate being submitted > but the hostname and IP address (domain and server_ip arguments). To make this example clearer: The internal DNS resolves intranet-server1.example.com to a public IP address (non RFC1918). The public DNS does not resolve this hostname (split DNS). -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3qk0AACgkQyM26BSNOM7YgjQD/Y5k2f4A5oZ1iN6YHAvlxm76f imGN4ouFX1BftSTBdJkBAIr1xVUdNg8enYqo8n984ClZ29vzJcKpEfOgVfjYmrFk =i/Wt -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/04/2011 09:56 PM, Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > >> On Sat, 4 Jun 2011 12:09:52 -0700 >> Mike Perry wrote: >> >>> Thus spake Robert Ransom (rransom.8...@gmail.com): >> My understanding was that EFF would query DNS for a hostname, and if the hostname does not exist, assume that it's private. (This should scare you even more.) >>> >>> EFF only needs to do this query if the browser could not (because it >>> was using an HTTP proxy without a SOCKS proxy). Does this scare you >>> less or more? I'm getting confused by the reactions in this thread. >> >> If EFF needs to perform a DNS query on each hostname it receives a >> certificate for, EFF will leak information to an attacker watching its >> servers. If EFF tries to not log hostnames which do not exist, EFF >> will leak a user's request time *every time* that it receives a >> certificate associated with a non-existent hostname. > > I think you missed the first half of my email where I explicitly said > EFF shouldn't need to do this under normal circumstances. It only > needs to do this when the browser fails to do so itself. Do you expect > this to be common? > > The observatory itself could also be running a tor client for these > resolutions, just in case they do end up being common. > > > P.S. When the browser does attempt to do these resolutions, should > they be done via Tor or via whatever local resolver/proxy was used to > access the domain? Doing it via Tor exposes potentially private names > to exits Yes, instead of asking the EFF to resolve a hostname an internal client could just use Tor to get an "outside view" regarding a hostname. This way hostnames don't have to go through a central point (EFF) for the 'is this hostname private?' - check. -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3qkz0ACgkQyM26BSNOM7ZYBgEAjPYkTkP8R8BpJl5Wl24DvGve sRKAywVBTv4Vxeql9y4BAJ8AGofNSR5W/Y3HqY1ieWGRJksd+5GD2/QatB0oTEWl =SreM -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > On Sat, 4 Jun 2011 12:09:52 -0700 > Mike Perry wrote: > > > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > > My understanding was that EFF would query DNS for a hostname, and if > > > the hostname does not exist, assume that it's private. (This should > > > scare you even more.) > > > > EFF only needs to do this query if the browser could not (because it > > was using an HTTP proxy without a SOCKS proxy). Does this scare you > > less or more? I'm getting confused by the reactions in this thread. > > If EFF needs to perform a DNS query on each hostname it receives a > certificate for, EFF will leak information to an attacker watching its > servers. If EFF tries to not log hostnames which do not exist, EFF > will leak a user's request time *every time* that it receives a > certificate associated with a non-existent hostname. I think you missed the first half of my email where I explicitly said EFF shouldn't need to do this under normal circumstances. It only needs to do this when the browser fails to do so itself. Do you expect this to be common? The observatory itself could also be running a tor client for these resolutions, just in case they do end up being common. P.S. When the browser does attempt to do these resolutions, should they be done via Tor or via whatever local resolver/proxy was used to access the domain? Doing it via Tor exposes potentially private names to exits, but doing it locally will fail to detect attacks where the MITM is able to operate on the user's own infrastructure (because they can just make sure that the domains they MITM resolve to RFC1918). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpRu7FHVNWXK.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sat, 4 Jun 2011 12:09:52 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > My understanding was that EFF would query DNS for a hostname, and if > > the hostname does not exist, assume that it's private. (This should > > scare you even more.) > > EFF only needs to do this query if the browser could not (because it > was using an HTTP proxy without a SOCKS proxy). Does this scare you > less or more? I'm getting confused by the reactions in this thread. If EFF needs to perform a DNS query on each hostname it receives a certificate for, EFF will leak information to an attacker watching its servers. If EFF tries to not log hostnames which do not exist, EFF will leak a user's request time *every time* that it receives a certificate associated with a non-existent hostname. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com):
> > >> Someone running this (SSLObservatorySubmission) in a non-public network
> > >> (i.e. an internal corporate network) with Internet access will probably
> > >> disclose internal hostnames including IP addresses, if that is the case
> > >> I would identify this as an issue. What do you think about it?
> > >
> > > We're going to try really hard to avoid this by default. See the first
> > > two options in the client UI section under "advanced options":
> > > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables
> >
> > These two options will prevent disclosure in many scenarios but I don't
> > think it will avoid the problem in a common scenario (internal hosts use
> > a valid FQDN and a valid cert).
> >
> > IP address and hostname (and cert.) of intranet-server1.example.com
> > using a valid certificate *.example.com will be published even if the
> > first two options in the "advanced options" are enabled. Is that correct?
> > In such scenarios I'm not worried about the certificate being submitted
> > but the hostname and IP address (domain and server_ip arguments).
> >
> > I'm not sure if I understand "private DNS domains" correct.
> > "[x] Do not check/submit certificates for private DNS domains"
If this option is set, the browser addon itself will try to check the
server IP and determine if it is RFC1918 ("Address Allocation for
Private Internets"). If the domain resolves to a private range, it is
considered private. The browser should be able to perform this lookup
so long as the user isn't *only* using an HTTP proxy.
Are you saying that you expect there to be a lot of publicly routable
IP addresses that use certificates signed by CAs in the default root
set out there? How can these be considered private? They are already
in the observatory DB from the IPv4 scan..
Or are you saying you expect there to be a lot of HTTP proxy users out
there who do not have a SOCKS proxy but who access certs signed by
public CAs?
> > Are private DNS domains just non-existing TLDs? Something like
> > "foobar.localnet"?
>
> My understanding was that EFF would query DNS for a hostname, and if
> the hostname does not exist, assume that it's private. (This should
> scare you even more.)
EFF only needs to do this query if the browser could not (because it
was using an HTTP proxy without a SOCKS proxy). Does this scare you
less or more? I'm getting confused by the reactions in this thread.
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
pgpp9vGEWtTs1.pgp
Description: PGP signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 04 Jun 2011 12:37:14 +0200 tagnaq wrote: > >> Someone running this (SSLObservatorySubmission) in a non-public network > >> (i.e. an internal corporate network) with Internet access will probably > >> disclose internal hostnames including IP addresses, if that is the case > >> I would identify this as an issue. What do you think about it? > > > > We're going to try really hard to avoid this by default. See the first > > two options in the client UI section under "advanced options": > > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables > > These two options will prevent disclosure in many scenarios but I don't > think it will avoid the problem in a common scenario (internal hosts use > a valid FQDN and a valid cert). > > IP address and hostname (and cert.) of intranet-server1.example.com > using a valid certificate *.example.com will be published even if the > first two options in the "advanced options" are enabled. Is that correct? > In such scenarios I'm not worried about the certificate being submitted > but the hostname and IP address (domain and server_ip arguments). > > > I'm not sure if I understand "private DNS domains" correct. > "[x] Do not check/submit certificates for private DNS domains" > > Are private DNS domains just non-existing TLDs? Something like > "foobar.localnet"? My understanding was that EFF would query DNS for a hostname, and if the hostname does not exist, assume that it's private. (This should scare you even more.) Robert Ransom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN6g6FAAoJENmcrTGPJVyVilYH/iVcZd4GbSA19BIYUWCWJwah tImYDiS+5v1ai2fXgPLabvSrNHdxqrfgoUnXOaaHMiZiSqJx8ekVOe5ah5rfd67E d+ONg5NWX9qyB+wpEtCJ0hHooMuBt9jcUlrVZAYNkyRy1BoyjB4PkqkXBh8S3mF1 xEtC/SDAoDU3g6hWC3q5OW3USykETKH2lI0WF0QFt4lY9GnUz8cn+l+HV9uCU/0C sMo9Q0BhhoSwyzr10VBLyuSm2HG1AzbJfS2eT2UPtitBbxNPjaCni/abvRlfzRxn CcOjl79oQ+xaM7qJrQt/tmMnD0t2LbkRdEbSM8vU5XAe4nPB7HmZ5+lV+VM3/BQ= =cCCI -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> Someone running this (SSLObservatorySubmission) in a non-public network >> (i.e. an internal corporate network) with Internet access will probably >> disclose internal hostnames including IP addresses, if that is the case >> I would identify this as an issue. What do you think about it? > > We're going to try really hard to avoid this by default. See the first > two options in the client UI section under "advanced options": > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables These two options will prevent disclosure in many scenarios but I don't think it will avoid the problem in a common scenario (internal hosts use a valid FQDN and a valid cert). IP address and hostname (and cert.) of intranet-server1.example.com using a valid certificate *.example.com will be published even if the first two options in the "advanced options" are enabled. Is that correct? In such scenarios I'm not worried about the certificate being submitted but the hostname and IP address (domain and server_ip arguments). I'm not sure if I understand "private DNS domains" correct. "[x] Do not check/submit certificates for private DNS domains" Are private DNS domains just non-existing TLDs? Something like "foobar.localnet"? thanks, tagnaq -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3qCtoACgkQyM26BSNOM7bktQD/U/GuTCz8AAu8zfexN6FcVB5x 702U2AnIaoj/nL5BYyYA/jQ6ZLfpVXRqoeYJGcSW4v8ysgej5duMO4I2L2fn/1Ae =719C -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/04/2011 12:52 PM, Robert Ransom wrote: > My understanding was that EFF would query DNS for a hostname, and if > the hostname does not exist, assume that it's private. (This should > scare you even more.) Well, if the EFF is able to ask the DNS regarding the hostname then the submission to the EFF took already place :) -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3qFHUACgkQyM26BSNOM7ZcgQEAnDKTd0GGldwsnrElSs7FON/B f425GsmZ466/SzuzmXsA/ROi6wNEt3W21TcsGJMFOIwdnmjs+SrrUuG3tbUIfKY2 =S0u2 -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake tagnaq (tag...@gmail.com): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 03/21/2011 01:58 AM, Mike Perry wrote: > > I've spent some time working with the EFF recently to build a > > distributed version of the SSL Observatory > > (https://www.eff.org/observatory) to be included with HTTPS > > Everywhere. The draft API and design sketch is here: > > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission > > > > The brief summary is that it will be submitting rare TLS certificates > > through Tor to EFF for analysis and storage. We will also leverage the > > database of certificates to provide notification in the event of > > targeted MITM attacks**. > > > > I am trying to decide if this is a bad thing to enable by default for > > users. > > Someone running this (SSLObservatorySubmission) in a non-public network > (i.e. an internal corporate network) with Internet access will probably > disclose internal hostnames including IP addresses, if that is the case > I would identify this as an issue. What do you think about it? We're going to try really hard to avoid this by default. See the first two options in the client UI section under "advanced options": https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables However, the tricky bit is that we may not know the real IP address of the destination server with certainty. We may have to rely on the DNS cache and/or an additional resolution (which may not even be possible if the user is using an HTTP proxy without SOCKS). This means that for the intersection of HTTP Proxy users who do not have a SOCKS proxy set who ALSO use private sites that are actually signed by a CA in the default root set may still have these "private" certs submitted to the observatory. We don't expect this set to be very large, but just in case, the EFF intends to do server-side scrubbing if the private_opt_in post parameter is set to false. Hopefully this will not be needed, but we'll need to see what the prevalance of this case is in the field to be sure. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFMzMXMRljm.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/21/2011 01:58 AM, Mike Perry wrote: > I've spent some time working with the EFF recently to build a > distributed version of the SSL Observatory > (https://www.eff.org/observatory) to be included with HTTPS > Everywhere. The draft API and design sketch is here: > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission > > The brief summary is that it will be submitting rare TLS certificates > through Tor to EFF for analysis and storage. We will also leverage the > database of certificates to provide notification in the event of > targeted MITM attacks**. > > I am trying to decide if this is a bad thing to enable by default for > users. > > On the one hand, we have taken a lot of precautions to ensure that the > EFF is given the minimal amount of useful information, and retains > even less (such as no high-resolution timing information). The EFF is > extremely trustworthy, and has an army of lawyers on-hand to defend > against subpoenas or legal requests for excessive data retention. > > Furthermore, the OCSP revocation servers have just as much or more > information, and who knows what they do with this same information. > In all likelihood, they probably sell it to netcraft and whoever else. > It is valuable. > > On the other hand, the EFF intends to publish as much of the > information gathered with this system as it can for analysis by the > wider Internet community. This will likely include raw SQL dumps of > the resulting certificate database. > > > So, the question for the bikeshed discussion then is what should the > default state of this collection be? Our thought is to provide > HTTPS-Everywhere users with this dialog on first-run > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables > > However, I'm not sure that this is going to work for Tor Browser > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > on readonly USB keys or live cds. They may end up being asked each > time they start. > > Is this a decent compromise? The other option is to not even bother to > ask users who have a working tor installed, on the assumption that > since we can submit certs through tor, it is always safe to do so. We > may end up doing this instead of always asking them. Is this wrong? If > so, why? Someone running this (SSLObservatorySubmission) in a non-public network (i.e. an internal corporate network) with Internet access will probably disclose internal hostnames including IP addresses, if that is the case I would identify this as an issue. What do you think about it? btw: sorry for my late reply to this topic, but it was still 'unread' till now on my side. -BEGIN PGP SIGNATURE- iF4EAREKAAYFAk3pgi8ACgkQyM26BSNOM7bfAQEAmib2/dGbUwP/kLJz9Dus2S3e 8h8KKCrFOQEypUz6SHAA+QFRPKGt7UJROpeCkd/aG0jZ4WuOXfQppGnPm+qeQFLW =6Ad/ -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
> But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't Always thought it would be useful to have a third party service where you could feed it a cert's sha1 fingerprint and it would return 0 or 1 if it felt that fp was legit. Many people have only one supposedly 'clear' view of the net from which to see. Tor exits certainly cannot be trusted to have a taint free view. And verification with CA issuer/subject is a pain. Call it a looking glass without guarantee. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
> if EFF was presented with a national security letter > or other legal demand under seal demanding the > existence of a given certificate not be exposed, > would they be bound to not present a MITM alert for > that cert? >> Leaving this for pde and/or Seth. > It's a question for our legal team. I'll ask them. >From various side channels, I've been led to believe that a certain portion of the legal community feels that NSL's are not, in fact, legal/constitutional... and they are awaiting a good test case before presenting that question. It would seem prudent for an ISP or node op to be quite concerned about following any demand that was not signed by a judge having jurisdiction... mostly to avoid doing anything that could later become a criminal or civil liability for them. Such as say installing and operating a wiretap under the guise/authority of such an extrajudicial letter or demand. For that reason alone, it would seem wise to seek review of any such thing before blindly producing or performing work. Note also that federal, state and even most county jurisdictions have 24hr judges on call, plus the FISA court for particularly sensitive 'national security' issues. ianal, call one :) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > On Tue, 22 Mar 2011 21:19:46 -0700 > Mike Perry wrote: > > Yeah, we need to start issuing requests for the IP, because the DNS > > request itself is an anonymity set fragmentation issue (since it won't > > go to the enclave, but will be mixed with other tor traffic). The EFF > > says using the IP for submission should be doable: the IP address they > > plan to use should be stable in the medium term. > > Will you be able to get a certificate valid for that IP address (rather > than hostname)? Supposedly some CAs will sign certs for IPs. We can alternatively distribute a self-signed cert with the xpi and install it pragmatically. Not sure which route to take. The latter is more secure, but the cert will show up in the user's "trusted certs" window in Firefox, which may or may not bother people. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpGJJdWC9ljP.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Tue, 22 Mar 2011 21:19:46 -0700 Mike Perry wrote: > > > But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't > > > this solve the same-circuit correlation problem? Tor should prefer > > > using that exit enclave in all cases when it is up in this case. > > > > This won't work if an exit node lies about the IP address of > > ???observatory.eff.org??? (and it won't work reliably in any case). Using > > an EFF-run hidden service would fix that problem if we can make hidden > > services work reliably again. > > Yeah, we need to start issuing requests for the IP, because the DNS > request itself is an anonymity set fragmentation issue (since it won't > go to the enclave, but will be mixed with other tor traffic). The EFF > says using the IP for submission should be doable: the IP address they > plan to use should be stable in the medium term. Will you be able to get a certificate valid for that IP address (rather than hostname)? Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > > > This ???phone-home??? behaviour is not safe for users who browse the web > > > over Tor until proposal 171 is implemented in Tor. At best, it would > > > *only* fragment the anonymity set of Tor users. > > > > The problem with 171 (SOCKS username/password to split streams across > > different circuits, for those playing at home) is that Firefox also > > lacks username and password fields in the proxy APIs for SOCKS, so we > > cannot do this for anyone except for TBB users. > > Could you include a native-code SOCKS client library in the extension? In Firefox 3.x, yes. But the threading support in FF4 is such that we cannot expect to have access to very many XPCOM interfaces or share JS objects with new threads, and post-FF4 we may be stuck with the XUL version of WebWorker threads, which have even less access. Not the way we want to go, I think. https://developer.mozilla.org/en/The_thread_manager We should patch TBB to send a u+p and try to get this patch merged upstream for post-FF4. > > But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't > > this solve the same-circuit correlation problem? Tor should prefer > > using that exit enclave in all cases when it is up in this case. > > This won't work if an exit node lies about the IP address of > ???observatory.eff.org??? (and it won't work reliably in any case). Using > an EFF-run hidden service would fix that problem if we can make hidden > services work reliably again. Yeah, we need to start issuing requests for the IP, because the DNS request itself is an anonymity set fragmentation issue (since it won't go to the enclave, but will be mixed with other tor traffic). The EFF says using the IP for submission should be doable: the IP address they plan to use should be stable in the medium term. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp6Ch08XUpGd.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Mon, 21 Mar 2011 17:09:38 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > On Sun, 20 Mar 2011 17:58:06 -0700 > > Mike Perry wrote: > > > > > However, I'm not sure that this is going to work for Tor Browser > > > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > > > on readonly USB keys or live cds. They may end up being asked each > > > time they start. > > > > > > Is this a decent compromise? The other option is to not even bother to > > > ask users who have a working tor installed, on the assumption that > > > since we can submit certs through tor, it is always safe to do so. We > > > may end up doing this instead of always asking them. Is this wrong? If > > > so, why? > > > > This ???phone-home??? behaviour is not safe for users who browse the web > > over Tor until proposal 171 is implemented in Tor. At best, it would > > *only* fragment the anonymity set of Tor users. > > The problem with 171 (SOCKS username/password to split streams across > different circuits, for those playing at home) is that Firefox also > lacks username and password fields in the proxy APIs for SOCKS, so we > cannot do this for anyone except for TBB users. Could you include a native-code SOCKS client library in the extension? > But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't > this solve the same-circuit correlation problem? Tor should prefer > using that exit enclave in all cases when it is up in this case. This won't work if an exit node lies about the IP address of ‘observatory.eff.org’ (and it won't work reliably in any case). Using an EFF-run hidden service would fix that problem if we can make hidden services work reliably again. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > On Mon, 21 Mar 2011 09:05:30 -0400 > Joseph Lorenzo Hall wrote: > > > It strikes me that I'd want notice (or the option to get notice) > > before submitting rare certs to the database... say a dialog like: > > "We're about to submit the certificate for the following site, [x] ok, > > [ ] no, do not submit this certificate. ([ ] remember this preference > > for this certificate)." My reasoning is that I should usually have a > > good idea when I'm expecting a rare/self-signed cert, and if I'm not > > expecting it, I'd probably want to submit it. Does that make sense? > > best, Joe > > 1. The extension cannot determine whether you have a ???rare??? certificate >without querying the database. Well, we are planning on shipping a list of the most popular TLS leaf fingerprints in the addon itself to reduce load on the observatory. This would be what "rare" means for deciding when to submit. But this is still likely too common to ask every time. > 2. If users do not report self-signed certificates that they expect to >see, the database cannot be used to detect man-in-the-middle attacks >on sites that use self-signed certificates. For those users, yes. But even if only one user is submitting self-signed certs, each observatory instance can also check the site itself, much like Perspectives. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpmmzAPFOHaG.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake Robert Ransom (rransom.8...@gmail.com): > On Sun, 20 Mar 2011 17:58:06 -0700 > Mike Perry wrote: > > > However, I'm not sure that this is going to work for Tor Browser > > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > > on readonly USB keys or live cds. They may end up being asked each > > time they start. > > > > Is this a decent compromise? The other option is to not even bother to > > ask users who have a working tor installed, on the assumption that > > since we can submit certs through tor, it is always safe to do so. We > > may end up doing this instead of always asking them. Is this wrong? If > > so, why? > > This ???phone-home??? behaviour is not safe for users who browse the web > over Tor until proposal 171 is implemented in Tor. At best, it would > *only* fragment the anonymity set of Tor users. The problem with 171 (SOCKS username/password to split streams across different circuits, for those playing at home) is that Firefox also lacks username and password fields in the proxy APIs for SOCKS, so we cannot do this for anyone except for TBB users. But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't this solve the same-circuit correlation problem? Tor should prefer using that exit enclave in all cases when it is up in this case. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpGzPhhS24fR.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On 03/20/2011 08:05 PM, Mike Perry wrote: >> if EFF was presented with a national security letter or other legal >> demand under seal demanding the existence of a given certificate not >> be exposed, would they be bound to not present a MITM alert for that >> cert? > > Leaving this for pde and/or Seth. It's a question for our legal team. I'll ask them. The main thing is that this feature is not intended for true real-time MITM alerts. It's for research and study, and I hesitate to overload it for MITM detection for all sorts of technical reasons, including those Mike has raised. -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Mon, 21 Mar 2011 09:05:30 -0400 Joseph Lorenzo Hall wrote: > It strikes me that I'd want notice (or the option to get notice) > before submitting rare certs to the database... say a dialog like: > "We're about to submit the certificate for the following site, [x] ok, > [ ] no, do not submit this certificate. ([ ] remember this preference > for this certificate)." My reasoning is that I should usually have a > good idea when I'm expecting a rare/self-signed cert, and if I'm not > expecting it, I'd probably want to submit it. Does that make sense? > best, Joe No. 1. The extension cannot determine whether you have a ‘rare’ certificate without querying the database. 2. If users do not report self-signed certificates that they expect to see, the database cannot be used to detect man-in-the-middle attacks on sites that use self-signed certificates. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sun, 20 Mar 2011 17:58:06 -0700 Mike Perry wrote: > So, the question for the bikeshed discussion then is what should the > default state of this collection be? Our thought is to provide > HTTPS-Everywhere users with this dialog on first-run > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables > > However, I'm not sure that this is going to work for Tor Browser > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > on readonly USB keys or live cds. They may end up being asked each > time they start. > > Is this a decent compromise? The other option is to not even bother to > ask users who have a working tor installed, on the assumption that > since we can submit certs through tor, it is always safe to do so. We > may end up doing this instead of always asking them. Is this wrong? If > so, why? This ‘phone-home’ behaviour is not safe for users who browse the web over Tor until proposal 171 is implemented in Tor. At best, it would *only* fragment the anonymity set of Tor users. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
It strikes me that I'd want notice (or the option to get notice) before submitting rare certs to the database... say a dialog like: "We're about to submit the certificate for the following site, [x] ok, [ ] no, do not submit this certificate. ([ ] remember this preference for this certificate)." My reasoning is that I should usually have a good idea when I'm expecting a rare/self-signed cert, and if I'm not expecting it, I'd probably want to submit it. Does that make sense? best, Joe On Sunday, March 20, 2011, Mike Perry wrote: > Thus spake coderman (coder...@gmail.com): > >> > The brief summary is that it will be submitting rare TLS certificates >> > through Tor to EFF for analysis and storage. We will also leverage the >> > database of certificates to provide notification in the event of >> > targeted MITM attacks**. >> > >> > I am trying to decide if this is a bad thing to enable by default for >> > users. >> >> if EFF was presented with a national security letter or other legal >> demand under seal demanding the existence of a given certificate not >> be exposed, would they be bound to not present a MITM alert for that >> cert? > > Leaving this for pde and/or Seth. > >> (said another way, could this potentially be a false sense of >> security, if all trust for anomaly notification was placed in the EFF >> alone?) > > The reality is we won't have the Firefox APIs to actually prevent > content load after certificate inspection any time soon, so it's not > feasible to trust this as your only security measure. Monsterous hacks > might make this possible sooner, though... > > On a timescale where we can provide real security rather than just > analysis and post-pwnage notification, we can build multiple databases > to submit to/query, just like Perspectives. > > There's also no real reason why you can't use both Perspectives and > HTTPS-Everywhere. Then you can get both of our half-assed > after-the-fact notifications that you were owned :) > > > -- > Mike Perry > Mad Computer Scientist > fscked.org evil labs > -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On 21.03.2011 01:58, Mike Perry wrote: > The brief summary is that it will be submitting rare TLS certificates > through Tor to EFF for analysis and storage. We will also leverage the > database of certificates to provide notification in the event of > targeted MITM attacks**. Awesome. :) -- Moritz Bartl https://www.torservers.net/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
Thus spake coderman (coder...@gmail.com): > > The brief summary is that it will be submitting rare TLS certificates > > through Tor to EFF for analysis and storage. We will also leverage the > > database of certificates to provide notification in the event of > > targeted MITM attacks**. > > > > I am trying to decide if this is a bad thing to enable by default for > > users. > > if EFF was presented with a national security letter or other legal > demand under seal demanding the existence of a given certificate not > be exposed, would they be bound to not present a MITM alert for that > cert? Leaving this for pde and/or Seth. > (said another way, could this potentially be a false sense of > security, if all trust for anomaly notification was placed in the EFF > alone?) The reality is we won't have the Firefox APIs to actually prevent content load after certificate inspection any time soon, so it's not feasible to trust this as your only security measure. Monsterous hacks might make this possible sooner, though... On a timescale where we can provide real security rather than just analysis and post-pwnage notification, we can build multiple databases to submit to/query, just like Perspectives. There's also no real reason why you can't use both Perspectives and HTTPS-Everywhere. Then you can get both of our half-assed after-the-fact notifications that you were owned :) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpMrHf3HRp2M.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sun, Mar 20, 2011 at 5:58 PM, Mike Perry wrote: > I've spent some time working with the EFF recently to build a > distributed version of the SSL Observatory > (https://www.eff.org/observatory) to be included with HTTPS > Everywhere. The draft API and design sketch is here: > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission cool! > The brief summary is that it will be submitting rare TLS certificates > through Tor to EFF for analysis and storage. We will also leverage the > database of certificates to provide notification in the event of > targeted MITM attacks**. > > I am trying to decide if this is a bad thing to enable by default for > users. if EFF was presented with a national security letter or other legal demand under seal demanding the existence of a given certificate not be exposed, would they be bound to not present a MITM alert for that cert? (said another way, could this potentially be a false sense of security, if all trust for anomaly notification was placed in the EFF alone?) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] How evil is TLS cert collection?
I've spent some time working with the EFF recently to build a distributed version of the SSL Observatory (https://www.eff.org/observatory) to be included with HTTPS Everywhere. The draft API and design sketch is here: https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission The brief summary is that it will be submitting rare TLS certificates through Tor to EFF for analysis and storage. We will also leverage the database of certificates to provide notification in the event of targeted MITM attacks**. I am trying to decide if this is a bad thing to enable by default for users. On the one hand, we have taken a lot of precautions to ensure that the EFF is given the minimal amount of useful information, and retains even less (such as no high-resolution timing information). The EFF is extremely trustworthy, and has an army of lawyers on-hand to defend against subpoenas or legal requests for excessive data retention. Furthermore, the OCSP revocation servers have just as much or more information, and who knows what they do with this same information. In all likelihood, they probably sell it to netcraft and whoever else. It is valuable. On the other hand, the EFF intends to publish as much of the information gathered with this system as it can for analysis by the wider Internet community. This will likely include raw SQL dumps of the resulting certificate database. So, the question for the bikeshed discussion then is what should the default state of this collection be? Our thought is to provide HTTPS-Everywhere users with this dialog on first-run https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables However, I'm not sure that this is going to work for Tor Browser Bundle users (which ships with HTTPS Everywhere) who may have the TBB on readonly USB keys or live cds. They may end up being asked each time they start. Is this a decent compromise? The other option is to not even bother to ask users who have a working tor installed, on the assumption that since we can submit certs through tor, it is always safe to do so. We may end up doing this instead of always asking them. Is this wrong? If so, why? ** Due to a limitation of the Firefox APIs, we cannot actually prevent the load of any content that is delivered by a MITM attacker. We will resort to an after-the-fact message that will inform you of compromise and advise you get to a more secure Internet connection immediately to change your password. Perspectives (http://www.networknotary.org/) has this same limitation, but it uses DOM manipulation to make you believe it has actually prevented the page load, when in fact your authentication tokens have also already been transmitted at the time of notification of MITM. Perspectives also has just enough differences that we decided to work on a different implementation. The EFF wants to turn every user into a vantage point, so that we can gather information on the extent of targeted, CA-authenticated MITM events. They want to find a silver bullet against the CA model, to conclusively prove that it can't possibly provide the security properties it claims. The Perspectives protocol is not set up to do this. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpXkSFqxBnOb.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
