Subject: [therightkey] DetecTor - client side detection of MITM, server impersonation, CA compromise

From: Kai Engert <[email-masked]>
Date: Mon, 16 Sep 2013 22:49:01 +0200

I've started yet another project to solve "the right key" problem.

DetecTor is an open source project to implement client side SSL/TLS MITM
detection, compromised CA detection and server impersonation detection,
by making use of the Tor network.

In short, make use of the existing Tor network, perform multiple
connections to the destination server through multiple routes, check for
consistency in the use of certificates, and either fail or proceed
automatically, without user interaction.

The detailed description of the idea, including suggestions for the
handling of edge cases, can be found at http://detector.io/

Looking forward to your feedback.

Regards
Kai

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Sep 2013 21:59:04 +0100

Hi,

Interesting idea. I note you say that this might add 5-30 seconds
to the access time for a give site and more for a web page with
more than one TLS server cert needed.

Is that something that could get quicker to the level where it'd
be acceptable do you think?

I suspect those kinds of latency would be a killer for browsers or
other applications using TLS.

Or am I misreading it? (Even if I'm not and this'd have to be
that slow, I think experimenting with it is worthwhile btw.)

Ta,
S.

On 09/16/2013 09:49 PM, Kai Engert wrote:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>

---

From: Kai Engert <[email-masked]>
Date: Mon, 16 Sep 2013 23:17:48 +0200

> be acceptable do you think?

If more people ran Tor network exit nodes (using the existing Tor
project software), and the existing nodes would be less of a bottleneck,
it would probably get quicker.

Also, it depends on the sphere configuration. In my initial experiments,
one of the spheres was configured to accept only Tor exit nodes that are
located in Africa or South America, but those countries have very few
nodes currently (around 12 in total).

For example, if you were located in Europe, and you configured all of
the spheres to use european countries, only, it would probably be much
quicker.

> other applications using TLS.

I agree that at this time the delay is a killer argument for enabling
the feature by default for all users.

However, there might be people who are very much worried about their
security, who might be willing to accept such delays.

Regards
Kai

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Sep 2013 17:19:38 -0400 (EDT)

> be acceptable do you think?

tor is slow, there is not much you can do about speeding that up.

> other applications using TLS.

You could cache known results?

For TLSA, I've worked on making things faster with a draft (soon two
separate drafts) that allow you to ask chunks of DNS(SEC) with 1 TCP
query. That should speed up TSLA validation on the endnode, even if it
is using DNSSEC itself for validation of TLSA records.

(and also, doing edns-tcp-query-chain allows one to get all the DNSSEC
  info using one tor circuit/connection)

Paul