On 01/22/14 16:44, coderman wrote:
On Wed, Jan 22, 2014 at 7:12 AM, Kelly John Rose <iam@kjro.se> wrote:
To verify though, this has no effect on someone using tor and staying on .onion sites or if you are using https end-to-end right?
correct.
Honestly, if you use Tor and don't use SSL that seems like laziness to me and deserves to be caught.
i would agree, and i would also show some sympathy towards the unsuspecting. anything cypherpunks can do to ensure end to end crypto everywhere by default is another MitM and eavesdropping attack denied....
(someone should write more about using client-side certificates as a method to thwart SSL MitM with a CA signing transparent proxy adversary upstream. aka BlueCoat with "enterprise certificate" injected or private key pilfer.)
Dear coderman, Client certificates are part of my answer to MitM attacks. The other part is to forget about third-party CA's. 1. The trick is to have each (web-)site sign the client certificates for their own users. Users sign up for a site by creating a fresh public/private keypair, invent an account name, and create a CSR containing just that: the accountname and the public key. The site's own Certificate Signer (local authority) checks to see if the user's chosen account name is unique and if so signs the certificate and returns it in the same response. The site's web server is configured to only accept their own client certificates signed by their own Signer. Each site only accepts their own certificates. In addition to that, the server sports a server-certificate that has been signed by the site's Signer. When the user connects to the site, the user agent first connects without presenting any client certificates. Ie, anonymously. The agent will then offer the user to log in at the site. But it only offers those certificates that have been signed by the same local authority. The client certificate becomes the identity of the client, while the site's Certificate Signer Root Certificate becomes the identity of the site. The MitM protection so far, is all-or-nothing. The user can only be MitM'ed if Mallory sits in between all the time, right from the first connection. However, there are several mitigation strategies. 2. The first mitigation strategy is for the site-owner to publish the Site's Local Signer Root Certificate in the DNSSEC-record. I realise that "true cypherpunks" don't like centralised systems but bear with me, here it is part of the solution. The user agent does a DNSSEC lookup, validates the signature tree up to the pinned DNSSEC root key. This limits MitM attacks to those who have a copy of that root key. ie, state level spooks. This lookup needs only be done once, before the first connect. The second mitigation strategy is an independent global append-only log of created client certificates. Whenever a user agent receives a certificate, it submits it to this global log. Every once in a while, the agent queries the log for all certificates bearing the account name that the user has chosen. There must be exactly one anser. To improve security at first contact, the agent queries the log for the expected value of the sites' Certificate Signer Root certificate. There must be only one. This list must be cryptographically protected against tampering. Ideally it is a distributed, decentralised global effort. The downside of this second approach, it needs to be designed, the DNSSEC-approach can be used right now. The combination of DNSSEC and the Log make it even more robust. The DNSSEC effectively specifies the intentions of the site owner, the log measures the reality. These two should match. 3. So far, I haven't mentioned Tor. When you use this protocol, you are protected against spoiled onions. The exit nodes won't have access to any site's private key, so they cannot fake a certificate that matches the client certificates. When an exit node creates a fake certificate for a site, the user agent interprets that as either a new site, (and offering the user to create an account). Or the user agent detects that the server certificate does not match with the certificate that it has remembered for this site and raises an alarm. As users change Tor-exit-nodes regularly, there can't be a MitM at each connection. 4. As every connection is encrypted and authenticated, Tor traffic does not stand out from non-Tor traffic. Even if people use this protocol to connect to facebook and spill their lives there, they are helping activists to hide their traffic better. 5. Using this protocol, we can create an introduction-service that lets total strangers exchange and validate each other's public keys. And from there bootstrap other secure channels. Coderman (and others), does this appeal to you? See http://eccentric-authentication.org/ (via Tor, if you want) to read more. I'd love to hear comments. With regards, Guido Witmond.