Dnia sobota, 25 stycznia 2014 16:53:19 Guido Witmond pisze: > On 01/22/14 16:44, coderman wrote: > > On Wed, Jan 22, 2014 at 7:12 AM, Kelly John Rose <[email protected]> > > > > 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?
That makes sense. I'll have to look into it more. > See http://eccentric-authentication.org/ (via Tor, if you want) to read > more. Thanks. -- Pozdr rysiek
signature.asc
Description: This is a digitally signed message part.
