A user looking at the "cryptocat session verifier plugin" has to think to herself, "What is this thing verifying? Is it just checking a digest of the Javascript files? How does it know if the CSS files have surreptitious Javascript in them that negates the crypto?"
Which is funny, because if cryptocat just required a browser extension that implemented all the crypto, it wouldn't need to verify anything at all. What was the point of Javascript crypto at all, if you're just going to push an extension onto people?
Your unease with SSL/TLS and its X509 PKI is entirely orthogonal to whether Javascript crypto works or does not work. Wanting an alternative to TLS does not give you an alternative to TLS.
It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".
Actually, in the case of that particular plugin, every bit of code, including CSS, JS, and HTML, are verified.
> It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".
It's hilarious how you completely ignore the much more pressing issues in HTTPS that I've pointed out. The server can read plaintext in the case of HTTPS, which is mitigated in JS crypto; not to mention that things such as SSLStrip and the COMODO hack have put many chinks in HTTPS's armour - HTTPS is a technology that derives a lot of trust from being able to authenticate the server, whereas we've seen authorities such as China create entirely passable fake certs to fool dissidents.
When the server is providing the client with its crypto code, the server can read the plaintext no matter what. I don't like these bullshit false promises.
If you are worried that China may own one of the root certs in your browser, remove the certs you don't trust. Hell, remove all the certs. Every mainstream browser allows you to do that. In most of them, you can even set up permanent exceptions for Amazon.com after you strip your certs out.
Meanwhile, HTTPS/TLS has over a decade of the most intensive study anywhere on the planet, and your favorite half-assed ad-hoc bespoke random "crypto-cat" scheme... does not.
> When the server is providing the client with its crypto code, the server can read the plaintext no matter what.
What? I don't see how that's necessarily true. The crypto code can be verified and if it turns out to be fine, then the server shouldn't be able to read the plaintext "no matter what." That's silly.
> Hell, remove all the certs.
Is this seriously your solution?
> ...does not.
This borders on ad-homimen - under this logic, we should never strive to attempt creating new techniques but always rely on 10+year old ones. There will always be new techniques that need testing, and the fact that older ones exist is not sufficient to prevent the study and advancement of new research.
Yes. I'm saying that if your execution environment is a browser, and your security code comes from a server, that server is going to be able to read your plaintext no matter what.
Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.
Yes. In cryptosystems, 10+ years of study does count for a lot.
> that server is going to be able to read your plaintext no matter what.
I'm truly sorry, I follow you on Twitter and actually really respect your opinion, but that's just nonsense. the HTML, CSS and JS can all be verified, either by a plugin or by researchers studying what the server is sending, or by a variety of other ways. This ultimatum you're giving is silly.
> Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.
That is not a real solution.
> Yes. In cryptosystems, 10+ years of study does count for a lot.
Of course - I never suggested it didn't - but that doesn't mean that new research can't undergo and survive skepticism.
You just stuck a plugin into the mix. You can make crypto work from a browser plugin. Just use the plugin for all the crypto; what the hell is the point of Javascript cryptography if you have a plugin? That's reckless to the point of negligence.
Although I don't really appreciates the tone here, I think that point that you are trying to make is that, if we are just going to use plugin, just use plugin all the way; why bother with Javascript for crypto at all.
I seriously don't appreciate your debate style, but I feel obligated to point out that your question has been discussed at another section of this thread: http://news.ycombinator.com/item?id=2935473
I think the point you are missing is that even if researchers/people can verify what the server is sending in general, there's no way for you to verify that the HTML/CSS/JS it sends you at that particular point in time is the same as the generally vetted version.
... and what feature of any Javascript browser crypto makes it anything more than trivial to defeat by such an attacker?
You can use sslstrip or malicious trusted CAs to argue the imperfection of SSL/TLS as deployed by browsers and users, but it does not follow that that somehow makes Javascript browser crypto any less broken.
I don't understand why a protocol with known major problems that can be compromised by oppressive governments is a better solution to client-side crypto that can be verified for integrity and hides the plaintext from the server.
Only the configuration of the CA-based authentication can. Nobody loves X509 PKIs, but so far, they seem to "work".
This matters because you can literally write a HOWTO that my mom could follow to get a browser configured so that China can't snoop on (many of) your HTTPS connections. No code required.
Which is funny, because if cryptocat just required a browser extension that implemented all the crypto, it wouldn't need to verify anything at all. What was the point of Javascript crypto at all, if you're just going to push an extension onto people?
Your unease with SSL/TLS and its X509 PKI is entirely orthogonal to whether Javascript crypto works or does not work. Wanting an alternative to TLS does not give you an alternative to TLS.
It's funny how many arguments supporting Javascript crypto devolve to "but the world would be so much better if this stuff worked".