7 ms·
Namecoin, A Replacement For SSL
- IgorPartola 13y ago> At cryptic.io we are creating a client-side, in-browser encryption system Here we go again... Let me guess, these guys also figured out a way to disable the context menu from popping up to prevent you from copying anything from their page. The rest of the article is pretty interesting. Edit after finishing the last bits of the article: So why is this better than something like MonkeySphere or DNSSEC? Both already let you distribute your public key and don't require anything experimental.
- jstanley 13y agoI haven't read the article, but... This isn't at all comparable to disabling the context menu. Anything that runs client-side and is in opposition to the user is screwed as the user can get around it. An attacker in this case would not have access to the client, an attacker in this case would be a MITM and would therefore not be able to mess with the encryption code (unless the encryption code itself is sent insecurely).
- tptacek 13y agoFor whatever it's worth, DNSSEC is a disaster too.
- pedrocr 13y agoWhy is that? What should we use instead? DNSCurve?
- tptacek 13y agoDNSCurve is fine, but we can also just continue assuming the DNS is insecure and pushing security out to the endpoints, where the End To End Argument says it belongs anyways.
- pedrocr 13y agoSo, how do I connect securely to a new website if I can't trust the DNS response?
- tptacek 13y agoTLS.
- pedrocr 13y agoYou seem to have a clear idea of how TLS+TACK solves this issue but you're not articulating it, just giving laconic answers. As far as I can tell TACK doesn't solve the first connection problem: "The big drawback of the TACK mechanism is that, like other client-side key-pinning methods, it does not protect the user against a man-in-the-middle (MITM) attack during the very first connection attempt to the remote server." https://lwn.net/Articles/499134/ https://lwn.net/Articles/499134/ So as far as I can tell even in a TLS+TACK world if your initial connection is to http://mail.mydomain.com http://mail.mydomain.com anyone that controls the DNS has you and if you connect to https://mail.mydomain.com https://mail.mydomain.com it's anyone that controls a rogue CA. This is exactly the same situation of TLS without TACK, no?
- tptacek 13y agoTLS+TACK doesn't solve the first connection problem if you stipulate a corrupted CA PKI. But the difference between the CA PKI and the DNSSEC PKI is that you have to stipulate that the CAs are corrupt; the DNSSEC PKI is corrupt by design. Meanwhile: the CAs are financially disincentivized from going rogue, because Mozilla and Google will remove them from the trust store if they do stupid things. What dynamic pinning plus CAs buys you, on top of key continuity that corrupted CAs can't break, is surveillance: an entity that can get bogus certificates issued can't assume they can do it undetected, because those certs will almost immediately break on someone's pin.
- pedrocr 13y ago
- timmclean 13y agoFrom their Kickstarter page[1]: > [the browser code] can also be verified against an open source repo with a browser extension [1]: http://www.kickstarter.com/projects/cryptic-io/cryptic-encrypted-online-storage http://www.kickstarter.com/projects/cryptic-io/cryptic-encry...
- aferreira 13y ago> These root certificates are managed by a small number of companies designated by some agency who decides on these things You're trying to explain how SSL is secure, that everyone implicitly trusts the root certificates and then there's this. I immediately lost complete interest in your explanation (because you probably don't understand it yourself) and hence in whatever product and/or solution you're trying to offer.
- devhinton 13y agoSecond paragraph, "One", not "On". Not trying to be a jerk but that is a bit sloppy :) EDITED: Also, unless I'm wrong equivalently comparably small errors in code are what allows for security loop holes cough cough original buffer overflow.
- tptacek 13y agoThe problems this author lists with SSL/TLS are not in fact problems with SSL/TLS, but rather with the browser vendors. The TLS standard itself is almost agnostic to how certificates are validated, and there is more than one strategy for doing so. For instance, Chromium doesn't trust the entire TLS CA system; it bakes into the browser "pinned" certificates, and not only won't honor a Google Mail cert from Komodo or China or Trustwave, but will also alert the (large, enthusiastic) security team at Google that a CA issued a rogue certificate. There's no reason the same system couldn't work for your site too; key pinning just needs to be made dynamic. And there's a standard for that: Moxie Marlinspike and Trevor Perrin's TACK, at http://tack.io http://tack.io. If you want to "fix" TLS, don't throw out the baby with the bathwater: you are vanishingly unlikely to do a better job of designing an encrypted channel than every cryptographer and protocol designer and software security person who has poured time into TLS. Instead, update the browser UX, which is the only thing leaving us hostages to the CA system.
- ENGNR 13y agoThe browser UX should only show either of: Green - The channel is secure, Red - Security error Which the current system already does. How would you upgrade the UX without exposing the complexities of security to the user? Also, why isn't there room for two authentication systems? The internet was built around redundancy. Secure systems could utilise both when they want to absolutely sure.
- pedrocr 13y ago>Instead, update the browser UX, which is the only thing leaving us hostages to the CA system. This is only the case if you mean the browser UX as it relates to site owners and not site users. For users the only browser UX they should need to know about is the browser being able to tell them with confidence "this communication is [not] secure". So why go through all this hackery to patch up the broken CA system vs just distributing the TLS keys through DNSSEC? That way you get a complete chain of trust all the way to the DNS root, validating both HTTP and the initial DNS response. Then you can really tell the user that the communication is tamper-proof without any gotchas about rogue CAs and certificate pinning.
- scovetta 13y agoIf you're paying $200 for an SSL certificate, you're doing it wrong. But I don't think any of the points of the article change for cost > $0.
- devhinton 13y agoMaybe I'm ignorant but $200 a year is not that much money. Considering a software engineer is usually paid 70k a year and you have four engineers you are looking at this being .071428571 % of total cost. So ummmmm maybe minimize your costs elsewhere :p
- ywyrd 13y agoSome of us live under the federal poverty level, where any sum of double digits or more is significant.
- devhinton 13y agoYes. That is true. You are right.
- dublinben 13y agoThere's always free certificates like from StartSSL and CACert.
- javert 13y ago$200 a year should be easily affordable under the US welfare system. Many people on welfare (oftentimes it's fraudulent, but government-encouraged, "disability" these days) make more than minimum wage. I am making a US-based comparison since you used the word "federal."
- yeukhon 13y ago$200 certificate for a personal website? That's not necessary. What we need is to stop charging a SSL/TLS certificate so much to get the recommended level of cipher used.
- michaelt 13y ago
- nwh 13y agoNice idea, but the project is pretty much dread. All the domains are squatted and up until a month or two ago you could steal anyone's domain and make it your own, it took a public full disclosure to rouse the developers enough to get it fixed.
- fragsworth 13y agoEh, they think it's fixed now. The squatting is awful, though.
- julie1 13y agoCryptography achileus heel is the UI. Think of PGP, adding a new key toyour browser, creating a certificate, adding an exception... Always unintuitive CLI. In terms of UI, I still don't get why for firefox a clear text password other an unencrypted connexion is not worse than a self signed certificate (it should be identically considered dangerous). The only crypto UI I can use is ssh.
- blahbl4hblahtoo 13y agoYou know, you're right. SSH has about the most sane crypto ui out of everything. That's a really sad state of affairs. I also agree with your point about self signed certificates...you it seems like sites should be able to identify you by that. It's probably easier to keep the certificate store on your machine safe than it is to actually follow the best practices that I've seen regarding password selection and usage.
- graue 13y ago> we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them. This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host. The threat model for server-side encryption is essentially: 1) the host has an unethical employee who wants to read your content. 2) the host's servers are insecure and get compromised. 3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here). 4) the government compels the host to provide your data (i.e. what happened with Lavabit). The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it. Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.
- mediocregopher 13y agoOne of cryptic's features is that the front-end is completely open-source. You can see the source for the current prototype here: https://github.com/cryptic-io/web https://github.com/cryptic-io/web We'll be releasing tools, like a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository. And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary. To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.
- graue 13y agoCryptocat was and is open source too: https://github.com/cryptocat/cryptocat https://github.com/cryptocat/cryptocat That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing. > To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure. At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit. > We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository. So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected. See here for a long list of other reasons in-browser crypto is problematic: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- eps 13y agoIt's rather disingenious to say that an SSL cert is $200, when in reality a domain-verified cert goes for about $20. Hardly anyone interested in Namecoin would be needing EV certs.
- mediocregopher 13y agoA wildcard cert, which you would likely want/need if you're running a business, does indeed go for about $200 (that's the minimum I've seen it, if you have a cheaper source it would make me very happy :))
- mnkypete 13y agohttp://www.startssl.com/ http://www.startssl.com/
- eps 13y agoI would want wildcard cert if I have over 10 public facing domain names. And if I have that many, $200 is not an issue. I mean... your cost argument is weak, almost meaningless. Just focus on the trust angle, it's a reason enough against PKI/SSL.
- stormbrew 13y agoThis seems to propose that the namecoin block chain could be used as an alternative to root certificates, but without the client needing to participate in the block chain. But this means you have to trust a third party service (and your connection to it) to serve you correct information from the block chain. How exactly does that work?
- mediocregopher 13y agoFor that case you're right, the scheme suffers from the same concerns as the CA scheme. The difference is that there is room to move forward, in that you can host the namecoin chain yourself and be sure of its accuracy. I think we could even have browsers have it built-in that they host a copy of the chain (the whole chain doesn't have to be downloaded, nor does all that's been downloaded need to be in memory).
- runn1ng 13y agoI think there were some problems with namecoin. Mainly that nobody is currently developing it and fixing its bugs.