and not a single Tor hacker was surprised...

[Guido Witmond]

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?

See http://eccentric-authentication.org/ (via Tor, if you want) to read
more.

I'd love to hear comments.

With regards, Guido Witmond.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20140125/6630e6bd/attachment-0001.sig>