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: <https://lists.cpunks.org/pipermail/testlist/attachments/20140127/b8793341/attachment.sig>
More information about the Testlist
mailing list