Blockchain-based solutions like Namecoin & DNSChain would have prevented this attack without forcing people to rely on untrusted third-parties (if Google stored their domain info in a blockchain).
We compare various mechanisms here:
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
EDIT: Not sure why this comment is getting downvoted. Maybe some folks don't want this problem to be fixed? :-\
The only derivative of Convergence that actually addresses the problems with Convergence (ironically), is FreeSpeechMe, which btw, relies on Namecoin's blockchain.
But downvote me again for pointing out facts. lol.
The last time I brought this up you admitted there was no good solution yet, has that changed?
The same way they know that Google chose google.com and Twitter chose twitter.com instead of twitter.io or something else.
> The last time I brought this up you admitted there was no good solution yet, has that changed?
This is referring to something else I think, how to transfer .com's into a blockchain while preserving ownership, is that right? That could be done (if needed) with a centralized registrar whose job it was to vet the ownership of the names upon first registration in some namespace. After the initial registration, control would be transferred to the owner of the domain. This is again, however, specific to the case of migrating ICANN domains (if someone wants to do that).
However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1]
If we went a bit further, and required that the certs be in the public log for some minimum amount of time (say 6 hours), that would have made it possible to shut down MCS before they got started.
If you want to prevent MITM attacks, it's one of the only options available to you (probably the only realistic option):
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
> However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1]
DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
Better in what way?
No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32.
I see the wording wasn't very clear, so I removed the word "only" to make the meaning clearer. It now reads:
"The CT spec allows one SCT to accompany a certificate, making this attack feasible"
Good catch. :)
Similarly, many investment banks and financial information firms have strict requirements to monitor all communications owing to SEC rules and insider trading regulation.
Yes, but what are those controls? You check every packet to see if it contains any information from one of your databases?
What if the person sending the data just applies a simple obfuscation technique to the data, or just tunnels through some other encryption scheme?
Edit: downmods? really?
Yes, if even the simplest obfuscation technique is employed, this system falls flat on its face. (Shh don't tell the regulators)
https://www.bluecoat.com/products/dlp
“Blue Coat DLP allows you to easily create policies that analyze the data source, content, destination and more.
…
accurate data “fingerprinting” capabilities, in addition to powerful keyword, pattern, and regular expression support, so you can create precision policies to effectively secure your data while minimizing false positives.”
Sure, the every HN reader might have questions about this but I'd bet a LOT of C-level executives are receptive to this.
I certainly agree that if you have a requirement to watch outbound data like this, having a system to selectively capture it is much better than simply attempting to record everything.
Notes:
1) Modern DLP solutions have some pretty sophisticated obfuscation detection tech. Like almost all of these kinds of technologies, they're looking for the 80% case, not the 99% case.
2) Tunneling out encrypted tunnels is subject to traffic analysis techniques. It's not as uncommon as one might suspect to detect out-of-band ex-filtration of many different types this way.
Automatic analysis to statistically detect hidden channels is a research topic, it can be used to put bounds on the exfil rate but not reliably detect it.
Be aware that the site you're going to may be MitM'ing sessions to meet other compliance regulations (e.g. SOX in the financial sector).
How does it know? Does it have a list of all "personal banking, healthcare sites, etc" from the whole world? How is that list kept up-to-date? What happens if the site the employee is accessing is missing from the list? What happens if the employee knows these sites aren't monitored and finds a way to use them to bypass the monitoring?
> Be aware that the site you're going to may be MitM'ing sessions to meet other compliance regulations (e.g. SOX in the financial sector).
If it's the site itself, is it really a MITM? And even if they technically use a MITM, does it really matter, since the site would have access to the plaintext anyways?
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.
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...
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:
[1] https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
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.
Edit, also see: https://en.bitcoin.it/wiki/User:Gmaxwell/namecoin_that_sucks...
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).
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, a project we're working on called DNSChain prevents MITM attacks for domains that have their info stored in a blockchain.
We're maintaining a list of alternatives and how they compare to DNSChain here:
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
Ignorant questions ahoy:
1. Using Chrome, would you have to manually accept the MITM certificate? 2. Could such a certificate be valid across multiple domains? 3. Would it pose any threat to the computer if it was moved from the MITM network to an outside network? 4. What kind of potential problems could occur if I issued a self-signed certificate for my network?
1. In this case you would not have to manually accept anything, as the root certificate (the CNNIC cert) is already in your browser/os and the certificate chain for certs created by MCS would be OK (because their cert is signed by CNNIC).
2. As CNNIC issued them an intermediate CA cert, MCS was able to create certificates for any domain they wanted and these certificates would be considered valid by everyone that has CNNIC in the root store. So the MCS cert is not valid accross multiple domains, but it allows MCS to create certificates for every domain which kind of has the same consequences.
3. I think it would pose a threat when leaving the MITM network, but not as a consequence of having been in the MITM network. Only the root certificates are stored locally. Websites have to send a complete certificate chain that anchors their certs in one of the root certs. This means that the cert generated by MCS is not stored and therefore not used when leaving the network anymore. The danger is that this intermediate cert allows MCS to generate certs for any domain and use them outside their network, too.
4. A self signed certificate would have to be installed on the machines in the network. Otherwise users would get a certificate warning and would have to add the cert to their rootstores themselves. Other than that I think that this would grant you the same MITM-powers as this intermediate cert did for MCS, with the only restriction that you couldn't create certs for domains not in your control that would be accepted by users outside your network/that don'd have your self signed cert installed.
http://windows.microsoft.com/en-us/windows-vista/view-or-man...
Details on what certificates come with your installation of Mozilla Firefox: https://www.mozilla.org/en-US/about/governance/policies/secu...
Your organization may add their own certificates as described below: https://www.utexas.edu/its/help/user-certs/817
Google's response here seems a bit weak.
CNNIC did so here: https://docs.google.com/spreadsheet/pub?key=0Ah-tHXMAwqU3dGx...
Kathleen Wilson's comment on the bug was: https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c66 "My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period."
However, over 14th months later when it came out the ANSSI (aka the French government) was doing the exact same thing, rather than revoking the root certificate Mozilla decided to limit them to issuing certificates to: .fr, .gp, .gf, .mq, .re, .yt, .pm, .bl, .mf, .wf, .pf, .nc, .tf
which AFAICT essentially acquiesces in MitM French firefox users that go to French websites.
I wonder if the response will be the same here.
Is there any way to do the same, manually, for the other "national" CAs? I woudln't mind if CNNIC handed out a certificate for every .cn domain out there, but if they ever try to sign one for an Egyptian entity (or even worse, a .com domain), I want to see a big red warning. Ditto for the Japanese and Taiwanese governments, which Firefox also seems to trust unconditionally.
I actually do this to some extent, as I don't quite trust the NIC of my own government. I told my browser not to trust it, so whenever I try to visit a government website, I get a big red warning. I override the warning after confirming that I am indeed visiting a government website protected with a government certificate. But if the government NIC ever tried to show me a certificate for a non-government website, I would know immediately. This works, but it's inconvenient, so I'd love to be able to restrict any given CA to subdomains of specific TLDs and/or second-level domains.
Too big to fail and all that jazz.
Doing it this way, however, means that they don't need to worry about pushing their self-signed certificate out to all their machines, right?
That could be done easily with group policies on Windows machines which would take care of, at least, Internet Explorer. I haven't used a Windows machine in a long time, though, so I'll ask: do the other major browsers use the built-in certificate store? If not, they'd still have to address the problem of getting their self-signed certificate "trusted" by Firefox and Chrome, for example.
I'm curious about the mechanism of Google noticing - was Chrome side-channeling information about it's cert to Google? Because if it was a true MITM proxy, google would never have talked to the browser directly to know what cert the browser was being presented. That's kinda how the whole MITM thing is dangerous - it's invisible to both sides if done correctly...
http://blog.chromium.org/2011/06/new-chromium-security-featu...
Why do we have that extension if nobody uses it :( ?
An Egyptian telecom company, MCS Holdings, contracted with CNNIC, the Chinese national Internet authority, to obtain a CA=TRUE certificate for use in their internal enterprise proxy --- ostensibly for use only with MCS's own hostnames. Users of MCS traversed that proxy to get to Google, at which point the proxy dutifully generated a (fake) Google certificate to bypass TLS for that connection. Google noticed.
Internal enterprise MITM proxy sounds creepy but isn't. There's a bunch of good reasons why a company would need to decrypt TLS traffic leaving their own network.
But enterprises don't need delegated CA=TRUE certificates to accomplish this. They can just roll their own self-signed root CA=TRUE certificate and built it into their machines. There is no reason a CA should need to put the entire Internet at risk solely for the convenience of a single company's IT operations.
A Chicago company called Trustwave did something similar a few years back. Are they still an HTTPS CA?