Hacker News Reader

Comment by tptacek | Hacker News Reader

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".

View on HN

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.

That is not a real solution.

Neither is YOUR FACE.

...

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

Neither is YOUR FACE

We don't write comments like this here.

Ref: https://news.ycombinator.com/item?id=2934523

Are you genuinely trying to be funny or is this OK coming from you on HN?

Sorry if this appears kvetchy, but clearly I need to get the rules around here straight before I open my mouth again.

I'm joking. Next time you have a question like this, you can email me; I put my email in my profile.

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 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.

sslstrip is also in large part a solved problem.

There are definitely major problems with HTTPS/TLS as a security system, but I think most of them are UI/UX issues.

What that means is we get a choice:

* Rebuild everything from scratch and spend 15+ years testing it back into reliability, or

* Rebuild just the UX for a protocol we otherwise known to be sound.

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.

TLS encryption can't be compromised by oppressive goverments. Only the CA-based authentication can.

Trying to "fix" this by rolling your own ad-hoc encryption (while ignoring the authentication issue entirely) is completely missing the point.

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.

The protocol doesn't have known major problems.

Reply on news.ycombinator.com