> today’s JavaScript apps are at the mercy of the security provided by web browsers, which are incapable of distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.”
This section title makes no sense.
There are lot of reasons that Javascript is bad for cryptographic use (which have been enumerated at length by others with far more experience in the field, like tptacek). But this isn't really one of them - or at least, it's not specific to Javascript.
Any application that makes an HTTP(s) connection is incapable of distinguishing between one that is secure with one that is being MITMed - that's the definition of an MITM attack. Certificate pinning (which is good) is simply a way of making it harder for a connection to be MITMed. If browser has pinned the certificate for a particular website, the only way to MITM it is to compromise the actual private key itself, and use that to fake a secure connection. (This is of course not what people usually mean when they talk about MITM attacks, but it fits the same basic structure as one).
> There are lot of reasons that Javascript is bad for cryptographic use
Wrong. Javascript is a language, the problem is the platform: client-side scripting is dangerous, but add-on or server-side through Node.js could be fine.
While there are arguments to be made for and against having secure DNS infrastructure (just look up DNSSEC), I really don't think that having trusted DNS would remotely make a browser capable of 'distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.”'
Even if you did know a trusted IP address, how do you know the packets aren't being sent by pf, or iptables, or ARP spoofing to a logging squid proxy?
This almost makes me cringe as much as draft-loreto-httpbis-trusted-proxy20-01.
Certificate pinning cannot stop this type of mass-surveillance. It is a band-aid that some companies use to mitigate the problem for their specific applications.
PKP is obviously a band-aid, and nobody involved with it says otherwise; it's a static list delivered with browsers. But the idea of pinning scales just fine and isn't simply a band-aid. The TACK proposal allows every site to assert their own pins, and does in fact largely mitigate the risks of compromised certificate authority.
It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties. They protect many properties other than their own.
The code exists for NSS. There are multiple CA mitigation technologies under consideration right now. CT seems to be the priority. Watch Chris Palmer's TrustyCon presentation for more details.
There are multiple CA mitigation technologies under consideration right now.
Do these "mitigation technologies" require us to continue paying CAs protection money? From what I read about TACK, it seems like it doesn't require that, but what's actually being done?
"Protection money" meaning paying for them to run a CA infrastructure, handle audits, and verify identity as per requirements? (Admittedly, "domain control" verification is sorta useless and completely automated.) Are HSMs and all these people supposed to just be paid on goodwill?
Not that some CAs aren't overpriced, but calling it "protection money" is just silly. You're free to go use your own CA. Once you've got it all setup and meet criteria, I'm sure Mozilla and others will let you in.
It's just protection money. No regular user actually cares about EV certs. The lowest thing that passes validation (domain validated certs) is fine and that's trivially automated.
The exorbitant fees are a joke that don't result in any improved security for the end user.
I'm not so sure about that, the way the browser vendors and companies beat it into their user's heads to look for the green bar with the company name on it.
Granted, it's still a scam. "Pay us money or all your customer's browsers will get scary and misleading error messages!"
and 99.99999999% of the time, a self signed cert represents... not much of anything, other than the fact that a site owner declined the to pay the PKI racket's protection money.
And even if we ignore that, the whole "EV Cert" thing is a total sham. All the EV cert does is indicate that you overpaid for it.
An untrusted cert looks identical to an attack. So the CA, while perhaps a circus, is necessary with current technology. Without that, there's no way to determine if you've been MITM'd or not - that's like the whole point of using TLS.
I know there are other proposals, but within the current constraints of the "global PKI", there's no alternative.
On a side note, for an EV cert, the CA must verify the registrant of the domain. They usually do a phone call to verify a phone number matching some other record with the name of the registrant. That takes some human effort to verify; more than an automated email. (In addition to just running a company, keeping a CA online but secure, etc.)
So the CA, while perhaps a circus, is necessary with current technology.
With current technology, it is not necessary.
Because of the blockchain (current tech) they serve absolutely no useful purpose.
You cannot claim that because web browsers voluntarily choose not to use it that it somehow disqualifies it as current tech.
Same goes for the EV cert and phone calls and all that jazz. Simply not necessary, and adds no extra value. In fact, it makes all of us less secure as the article points out.
If, to take one of my favorite companies as an example, Mozilla were to support the blockchain for authentication, they would register themselves there, and that's that. No phone calls necessary, they simply own their identity, and can, via established existing channels (@mozilla twitter account, their newsletter, their .com, etc.) declare what is and isn't official.
They can even get their .com into the blockchain, although that isn't yet current tech:
> It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties.
The post didn't name specific companies or products, but on that note, is there a list of sites that Chrome and/or Firefox have pinned somewhere? I don't think TACK has been implemented in them.
The thing with TACK is that it doesn't actually solve the key distribution problem. The draft itself states:
TACK pins are easily shared between clients. For example, a TACK
client may scan the internet to discover TACK pins, then publish
these pins through some 3rd-party trust infrastructure for other
clients to rely upon.
Keywords: "some 3rd-party trust infrastructure"
That is what DNSChain and the blockchain provides. It provides more than that though, and thus providing everything that TACK proposes too.
This is a misrepresentation of TACK. TACK will ordinarily be deployed similarly to HSTS: it's a key continuity scheme, like SSH. It doesn't require a "third party trust infrastructure". But unlike the CA system, TACK also supports the notion of a third-party root; the EFF could run a site that would provide trustworthy pinned keys for arbitrary sites on the Internet, and you could subscribe to that site.
Contrast to DNSChain, which requires that ordinary users trust a third-party server.
the EFF could run a site that would provide trustworthy pinned keys for arbitrary sites on the Internet, and you could subscribe to that site.
So how do you know that your subscription to EFF is secure?
Contrast to DNSChain, which requires that ordinary users trust a third-party server.
First-party, not third-party. What you described with EFF is a third-party, whereas DNSChain is a first (or 2nd) party, because either you own the server (1st party), or your friend does (2nd? party).
DNSChain isn't going to happen.
It's already happened. I'm using it right now. Where's TACK?
You're playing semantic games with "first party" and "second party" and "third party".
If I didn't think EFF was trustworthy, I wouldn't subscribe. Key continuity would still make TACK valuable; even without trusted third parties, widespread deployment of TACK would practically eradicate dragnet surveillance through compromised CAs, because every attempt to forge a certificate would quickly be detected.
I am not. Those words have real meaning that doesn't disappear when you accuse me of playing semantic games.
If I didn't think EFF was trustworthy, I wouldn't subscribe.
I asked how do you _know_?
With DNSChain, you actually have a great deal of certainty that is based on math, not public reputation.
widespread deployment of TACK would practically eradicate dragnet surveillance through compromised CAs, because every attempt to forge a certificate would quickly be detected.
With DNSChain there are no compromised CAs to eradicate, and therefore no problem. You also get to keep your money, no more need to pay for SSL certificates.
Namecoin unfortunately does not scale. You can't have lite clients, just an ever growing multi gigabyte database on every device you wish to use it on. Relying on a remote party to securely store and relay the blockchain to you is foolhardy, at best you're trusting a remote DNS server that can be MITM'd itself (the dotDNS system doesn't provide signing requests only encrypting).
It's a nice idea but inherently unusable in almost any circumstance.
Namecoin DOES scale, you can have lite clients, and note that dotDNS and OkTurtles are not official Namecoin projects.
The developer doesn't really understand what he is talking about when it comes to the blockchain and he misrepresents his work as being fundamentally different than what a CA offers. He honestly thinks everyone will setup their own DNSChain on top of a Namecoin install.
To what end? You could abusively embed data in the Bitcoin blockchain (20GB), or use the Namecoin blockchain, or any multitude of altcoins with useless security that nobody has even heard of before. The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain.
> The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain.
This project (DNSChain), uses the entire blockchain, so it's all good. And no, you don't need to store it on your phone as has been explained in other comments here, on the blog, and on the github page.
This does scale, and lite clients are not being proposed here. To use this, your phone/computer doesn't need to run any type of node to communicate with the blockchain. Instead, all of that is done for you by your chosen DNSChain server.
> This does scale, and lite clients are not being proposed here.
The first part of this document tells me that a local daemon communicated with Namecoin, ergo the system is dependent on having it running locally for anything approaching security.
> Instead, all of that is done for you by your chosen DNSChain server.
That's just it, why would I ever trust a remote resolver? There's two public resolvers listed on the homepage of the site, one is doing resolution in the clear and the "encrypted" one has no listed public key to verify that again there's no MITM.
None of this is filling me with confidence and we haven't even asked who is running the things yet.
In my mind it could be something run on a local lan, or at the organization or neighborhood ISP level. In those cases there is still a question of how trustworthy those sources are. But there is also a reduction in the ability to compromise many connections. An attacker targeting a specific computer or person or organization still has an avenue, but there is much less room for compromising the entire scheme as a whole (of which there is plenty of room currently).
The solution as presented doesn't solve ALL of our problems, but solutions rarely do, and it's not reasonable to expect them to. But it does solve SOME, and doesn't present any new ones (although I expect to eat my words as I type that). Progress is progress, even if it doesn't get us the full mile.
As for trusting those writing this particular software, we don't really have to trust them, we simply have to trust the code.
No, it gives you the option of a different server that the NSA has also compromised.
There's is no way to square the circle here - Zooko's triangle [1] guarantees that you can't have a decentralized system with memorable secure names. See Dan Kaminsky's analysis of Aaron's system (which was implemented by NameCoin. [2]
I just read that rebuttal link, and it predates Namecoin and it looks like things have changed quite a lot since the original proposal - including a 250 day expiration date and more importantly, Bitcoin-style block mining to do tiebreaking on registration races to decide what the truth is. Have there been any successful attacks of the type outlined in the rebuttal made on Bitcoin or Namecoin?
> Correct me if I'm wrong, but this looks as if it's just a system to present blockchain data to normal clients using a pseudo-tld DNS proxy.
That's about right, I think.
> That's just it, why would I ever trust a remote resolver?
You trust yourself right? The docs emphasize in multiple locations that you should be the one who is running the resolver. And if you don't know how, you can use a friend's while you're learning or others are making it easy for you to have your own.
> the "encrypted" one has no listed public key to verify that again there's no MITM.
It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy.
> They promise resolution will be signed by the server some day, but it's not a feature enabled right now.
It's not like it's difficult to implement this. I could do it in a couple of hours, but I came to a stopping point with the code and began focusing on community building for a bit. Don't worry, it's coming real soon, and you're welcome to implement it yourself and submit a pull request if you can't wait. :)
> It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy.
You're right, github must have hiccuped before. When I looked at that before it was a blank document. I assumed it was a placeholder because the client didn't support any sort of request signing yet.
(Sorry for editing my post out from under you, it wasn't intentional)
Does anyone who's got some background with DNSSEC (https://en.wikipedia.org/wiki/Dnssec) feel like comparing DNSChain to the basic idea of embedding certificates or signatures in authenticated DNS records? We've had a lot of different proposals for the latter over the years and my impression is their lack of adoption hasn't been because DNSSEC is fundamentally broken (though it is flawed in several ways). AFAICT it breaks down like this:
Against DNSSEC + certificate records:
1) There's a centralized PKI administration issue, but less so than the current CA morass
2) Administrative/rubber hose/legal/monetary compromise of the DNS root administrators (currently US NTIA) would allow substitution of the TLD keys, but this would be blatantly obvious to every organization or individual paying attention
3) DNSSEC has some annoying properties with regard to name enumeration and such
4) Need to either use a primary resolver that supports DNSSEC (Google Public DNS and Comcast, among others) or do a separate query to one who does
For:
5) Minimal extra infrastructure, already supported in some libraries
6) Extremely cacheable with low resource requirements (root & TLD keys, MRU/MFU certs)
7) No need to add a new dependency on a previously untrusted source of code and crypto data
8) As long as the parent TLD has deployed DNSSEC the organization only needs to get their key set up, add a theoretical cert record, and sign records as needed.
I think issues 1 & 2 are at least as big a problem with DNSChain because in practice the hand-waving of how you pick a trusted DNSChain chain is ignoring a huge class of vulnerabilities. Issue 4 is still a win over implementing a large chunk of infrastructure or trusting okTurtles'. The "just use Javascript" bit seems to apply equally to either, though I guess the _query_ portion of DNSChain is relatively simple.
"We’ve taken several important steps on the road to making “NSA-proof communication” on your favorite websites possible."
is that a lot of use cases involve mobile phones (of course) which have two other computers[1] inside of them that you have no control over and are regularly used to manipulate[2] your android/ios environment out from under you.
I love to see these pieces coming together to form a more secure ecosystem, but it's really one step forward and two steps back as long as we don't have an open baseband and sim card OS, etc.
The OTA updates one is such a tricky issue. What's more important? Not being able to fix bugs in hundreds of millions of devices for a long time (or at all), which NSA is going to use and abuse anyway, or worrying that one vendor will try to push an NSA backdoor to hundreds of millions of devices?
I think the best compromise for that is to have OTA updates but the source of the software being upgraded needs to be open source, so at least there's a disincentive to backdoor it and also the possibility of finding the backdoor inside the new update.
As for the baseband processor, we need to keep poking at Qualcomm and others to open source their modem firmware, and then vote with your wallet.
Getting a SIM card with an open source OS is probably going to take a while, although Google is in a very good position to push for that right now, since their OS is so dominant in the mobile market, so it's probably Google the one we need to nag to get it.
Assuming there aren't any more "any user can steal from any other user" bugs in Namecoin, here's some info on how it's intended to work: http://en.wikipedia.org/wiki/Namecoin
It isn't. He is stuffing information in the blockchain into a standard public-key crypto scheme. DNSChain is more secure in that you run your own certificate authority that happens to have it's trust root in Namecoin.
I understand how blockchains can be used to trace the history of transactions back to the root but I don't see how that can be used to do secure key distribution.
Assuming everyone trusts the root block, how does that trust get transmitted down to subsequent blocks?
Claims "NSA-proof communication" but what about KGB, MI5, BND, whatever the Chinese call themselves, and everyone else? They're all doing it, too. (Assuming you think they care about you at all.)
> today’s JavaScript apps are at the mercy of the security provided by web browsers, which are incapable of distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.”
This section title makes no sense.
There are lot of reasons that Javascript is bad for cryptographic use (which have been enumerated at length by others with far more experience in the field, like tptacek). But this isn't really one of them - or at least, it's not specific to Javascript.
Any application that makes an HTTP(s) connection is incapable of distinguishing between one that is secure with one that is being MITMed - that's the definition of an MITM attack. Certificate pinning (which is good) is simply a way of making it harder for a connection to be MITMed. If browser has pinned the certificate for a particular website, the only way to MITM it is to compromise the actual private key itself, and use that to fake a secure connection. (This is of course not what people usually mean when they talk about MITM attacks, but it fits the same basic structure as one).