It's the golden unsolved, perhaps unsolvable problem in crypto. Trusting trust and such. There's always a key, somewhere, that has to be shared.
One way to hack the system is if you have actual knowledge of the person you are talking to, and you assume some limited amount of tampering which can be done in real-time. For example, if I know the sound of your voice, and we want to agree on a key with no MITM, we can setup an audio channel and speak some code words to each other. Baring an adversary which can in real-time intercept and synthesize my voice convincingly speaking a different code, this is pretty secure. [1]
[ZRTP] allows the detection of man-in-the-middle (MiTM) attacks by displaying a short
authentication string (SAS) for the users to read and verbally compare over the phone.
Another imperfect defense is spreading over time the data that an attacker would have to intercept and modify in order to MITM. That's what Chrome is doing with their pin lists. Now an adversary would have to alter the pinning when Chrome is downloaded. Of course in this very thread we're talking about technology which can do exactly that. E.g. technology which has any hope of preventing data exfiltration, would have an easy time altering Chrome's pin-list. Of course the Chrome binaries are signed, so there's another layer to defeat, etc. etc.
So the end result is there are a lot of good technologies to prevent MITM. If you can keep the attacker out once, you can generally be confident your future conversations will be secure as well, since good protocols don't start from scratch each time, but rather "ratchet" new keys from the old as you go. [2]
One of the big trade-offs is false positives and privacy. For example, it might be nice if my browser remembered the public key of a site I visit, like HN, and let me know if it changed. Two issues are a naive implementation would also serve as a great tracker for every site I've visited, and how do I know if when I get a warning, it's a real attack and not just an expiring certificate rotating out? Now we would need a way for sites to indicate, by signing with their old key, that indeed they are switching to a new key, and complexity explodes from there.
> It's the golden unsolved, perhaps unsolvable problem in crypto.
I think this problem was solved fairly well by Namecoin back in 2011. Software like DNSChain [1] then makes it possible to securely access blockchains like Namecoin without having to run a full node on your phone or other device.
If you can't run your own DNSChain server (or don't have a friend's you can use), you can query two or more independent servers and make sure the responses match.
Dionysis Zyndros recently came up with a mechanism whereby you can even query a single DNSChain server (that you might not trust), and still be assured of correct replies if you received an accurate key once (we'll be publishing info on this technique soon over at blog.okturtles.com; it's somewhat similar to what you're talking about with ratcheting keys).
We maintain a comparison of various approaches here:
Of course how could I have not mentioned the blockchain? Thank you!
Part of the trick with blockchain is validation. Everyone is not going to keep a full node, not even close, and just delegating trust is not the answer. You want to trust but verify.
I'm not sure what the state-of-the-art is these days for SPV-type verification, but I don't see anything in the current DNSChains response which would allow any kind of independent verification of the returned data.
> Part of the trick with blockchain is validation. Everyone is not going to keep a full node, not even close, and just delegating trust is not the answer. You want to trust but verify.
Right, so hence the two techniques I mentioned in my reply: query more than one server, and/or use Dionysis' "proof of transition" (for lack of a better name).
An interesting thought would be using a bloom filter to store certificate fingerprints. It would prevent someone from getting a list of all the websites/certificates a user has seen. However the significant downside is that a certificate hit could be a false positive and the user hasn't ever seen that certificate before.
> It's the golden unsolved, perhaps unsolvable problem in crypto.
Sorry, perhaps my question wasn't clear. I wasn't asking about MITM in the general case, I was asking about this particular case. The certificate chain for Hacker News seems to go AddTrust -> COMODO -> Another COMODO -> *.ycombinator.com. So in this case, if you're MITM'd by MCS Holdings, is MCS Holdings going to be part of the chain (after a CNNIC)?
Yes, the chain would be different. MCS Holding cannot become Comodo (Comodo = AddTrust, btw), so the chain would change to CNNIC -> MCS Holdings -> *.ycombinator.com.
One way to hack the system is if you have actual knowledge of the person you are talking to, and you assume some limited amount of tampering which can be done in real-time. For example, if I know the sound of your voice, and we want to agree on a key with no MITM, we can setup an audio channel and speak some code words to each other. Baring an adversary which can in real-time intercept and synthesize my voice convincingly speaking a different code, this is pretty secure. [1]
Another imperfect defense is spreading over time the data that an attacker would have to intercept and modify in order to MITM. That's what Chrome is doing with their pin lists. Now an adversary would have to alter the pinning when Chrome is downloaded. Of course in this very thread we're talking about technology which can do exactly that. E.g. technology which has any hope of preventing data exfiltration, would have an easy time altering Chrome's pin-list. Of course the Chrome binaries are signed, so there's another layer to defeat, etc. etc.So the end result is there are a lot of good technologies to prevent MITM. If you can keep the attacker out once, you can generally be confident your future conversations will be secure as well, since good protocols don't start from scratch each time, but rather "ratchet" new keys from the old as you go. [2]
One of the big trade-offs is false positives and privacy. For example, it might be nice if my browser remembered the public key of a site I visit, like HN, and let me know if it changed. Two issues are a naive implementation would also serve as a great tracker for every site I've visited, and how do I know if when I get a warning, it's a real attack and not just an expiring certificate rotating out? Now we would need a way for sites to indicate, by signing with their old key, that indeed they are switching to a new key, and complexity explodes from there.
[1] - http://blog.cryptographyengineering.com/2012/11/lets-talk-ab...
[2] - https://whispersystems.org/blog/advanced-ratcheting/