Comment by yason | Hacker News Reader

Comment by yason | Hacker News Reader

I think CA's are problematic nevertheless because they involve a third party I never invited. I would much prefer to have a ssh style public key fingerprint that you must verify and accept for one site, and know that once I've decided to trust them, nothing can come between me and them unlike with SSL certification chain. I would prefer to receive my bank's public key on paper when signing up for online banking and verify that it equals what I see when I first connect to their servers.

This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count. Fingerprints would be submitted to a public service that accumulates submissions from different users, identified by the same public key used to sign the submissions. Trustworthiness would be weighted based on the history and age of the users' submissions: someone who has used the same public key and submitted fingerprints for five years is likely to be a real user that you can trust instead of a bot that generates new identities in order to submit false fingerprints to launch a MITM. There are numerous ways to implement this.

One positive thing would be to bring the same attention to trustworthiness to people's minds that they must employ in "real" life as well, i.e. offline. A website that's never fraudulent or genuine (unless you got it in writing) but shades of trust more reflects the interactions we encounter in real life (can I trust this guy because my friend said he's ok?).

The approach you're talking about --- some people call it "key continuity", some people call it "trust on first use" --- does not work on the public Internet. At all.

The problem with it is that SSL/TLS is designed and intended to protect commerce. The attackers that commerce cares about† aren't targeted. If they can't sniff someone's session because they already established a trusted pairing with their bank, so be it! They'll just wait for the next person to connect. They will obviously get some percentage of user sessions that way, either from first connections or because people changed computers or reinstalled their browser or deleted files or what-have-you.

These are connections the attackers get above and beyond the stuff they already get by owning up machines. Which they'll also be able to do more of, because the same problem will happen with software update systems.

The current hardwired selection of CAs we have is bad, is a flaw in SSL/TLS/HTTPS even, but it's not so bad that we continuously lose X% of all connections to passive attackers.

† and that you should care about if you value the ability to run businesses on the Internet

See the EFF's recent 'sovereign keys' proposal for one similar idea for preserving trust in a server key, once established, against later CA-based hijacking.

Or, Tyler Close's 'YURL'/httpsy scheme for making introduction/bootstrap the important step, rather than a CA/PKI lookup:

http://www.waterken.com/dev/YURL/httpsy/

> This reduces the MITM to the initial handshake. This could be worked out to a degree with some p2p scheme or a set of DHTs for popularity count.

I'm no expert but I think the solution is already here in the form of http://convergence.io/ http://perspectives-project.org/ and other, similar projects. If each of us could have several trusted notaries (including an ability to run one) taking a look at every ssl certificate we accept by comparing it to what others are seeing, what is served in the dns records for requested domain, whether its integrity is secured with dnssec, what was presented on last connection, and whether it's signed by a trusted CA, we would have a pretty safe system, unshaken by the failure of any single entity.

Convergence is already doing a lot of it, unfortunately, last time I checked it was still breaking on SNI. But that's a minor problem with a particular plugin, the approach itself is, again in my non-expert opinion, great.

> This reduces the MITM to the initial handshake.

Mostly. No matter much you trim your certificate chain, there's nothing preventing Google/your bank/Amazon/etc from sharing their private key with, say, Uncle Sam. However, the backdoor admin access that the gov't gets to sites like TwitterFace and Gmail probably makes that a pointless effort.

Confidentiality/Authenticity are pretty much impossible to guarantee unless you control everything on both ends.

Um, that's not MITM then is it?

I mean yes, if you're paranoid enough you probably should build an underground bunker in the mountains and grow your food, but objectively there is a huge security difference between whatever shenanigans a trusted partner may be up to and a large body of auto-trusted with potentially leak able-to-who-knows-where subcerts.

Or, what if the user's browser requested a site's public key on its first visit, but required it to be signed with a trusted CA? So to perform a MITM on an SSL connection, Mallory would have to both infiltrate a CA and MITM the user's connection on their first visit to a site.

You can have this today by running Firefox with the Certificate Patrol plugin.

Though the system I suggested lets a site change CA.

When a site's certificate changes, Certificate Patrol shows you what has changed, including the public key fingerprint. So you easily detect the case when the site changes CA without changing their public key.

It is already reduced to the initial handshake. That is exactly what a CA does. But perhaps you are right that a CA should sign certificates based on influence-weighted pseudonymous votes rather than simply receipt of payment! Should CA's require payment in bitcoins?

It's only reduced to the initial handshake if every single CA¹ keeps their signing certs protected. We've seen more than once that this is not always true.

¹ (remember, even if you have a cert with a specific CA, nothing technically prevents a cert from being signed with another CA's certificate).

Reply on news.ycombinator.com