Client-side SSL/TLS MITM, compromised CA and server impersonation detection (opens in new tab)

(detector.io)

38 pointscbolat12y ago8 comments

8 comments

I like this idea a lot!

A less powerful solution implemented completely locally: A "known_hosts" file for SSL certificates for repeat visits. As long as you've visited a site once before, any subsequent visits will be safe.

To deal with certificate upgrades, certificate Y could present a signed verification that it obsoletes a past certificate X. Then, when a client that trusts certificate X receives certificate Y, it can update its "known_hosts" file accordingly. This change would require more than just local changes, but remote cooperation.

nwh12y ago

> As long as you've visited a site once before, any subsequent visits will be safe.

As long as your first visit wasn't compromised.

Sites like Google's also don't use the same certificate every time. Out of my own curiosity I scraped their SSL sites for a while, I saw tens, maybe hundreds of different certificates being presented. There's no way of telling which are actually Google's.

gwu7812y ago

Certificates could be initially delivered out of band, e.g., in person, or by postal mail. Perhaps in a printed format that can be scanned in.

But then there's no way of telling which postal mail is actually from Google, right? :)

1 more reply

Nanzikambe12y ago

Interesting, but doesn't this pretty much assume that the MITM isn't occurring in the last hops of the path to the server?

If all paths (including those through Tor) lead through a piece of compromised infrastructure (a rogue access-point like a pineapple, or subverted router) both will report that the site uses the same certificate despite the MITM.

jarito12y ago

How is the different from convergence.io? What does using Tor offer over Moxie's approach? An existing network of machines?

aw3c212y ago

See http://detector.io/DetecTor.html , it's really not too much to read and written well.

j / k navigate · click thread line to collapse