and not a single Tor hacker was surprised...

rysiek rysiek at hackerspace.pl
Sun Jan 26 16:17:16 PST 2014


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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140127/b8793341/attachment-0001.sig>


More information about the cypherpunks mailing list