Live data from Hacker News

Bonchat - client-side encrypted web chat for the truly paranoid

bonchat.org

11–20 of 51 posts

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#11
post #2

For any HN crypto nerds: I made a little web chat that even the server can't read. Besides boring old SSL, bonchat.org uses a javascript implementation of AES to encrypt chat client-to-client. There are no cookies, no sessions, and no account registration. You never even send your password or plaintext username to the server. If you chat with someone who knows the same password, you get a simple HTML/Markdown web cha…

It's not by-golly secure; it's insecure in a way that drives me perpetually nuts and that pushes a grevious misconception about how crypto algorithms can secure traffic in browsers.

There is perhaps no worse place in the world to do crypto than in a Javascript interpeter bound to an HTML DOM and hooked up to a network.

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#12
post #8

Cute, but unless you have some way to verify the client code every time you use it, it's only a bit more secure than a regular web chat site over HTTPS.

(Friend of the OP here.)

That’s true, but it’s a problem with pretty much everything. Google (or an impostor) could, once in a million requests, send you JS that posts your Gmail password to Twitter. You probably don’t trust this site as much as Google, but the JS is unobfuscated and you can dump your traffic. That’s about as much as anyone can offer.

Personally verifying the code and hashing it every time you use it (or whatever) is a big headache. But if you’re that serious about security, it applies to everything. Bonchat adds the unusual feature that, once you’ve done so, you know that the server can’t even theoretically read your chat. (Assuming AES is unbroken.) This is a step above Gmail etc.

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#13
post #8

Cute, but unless you have some way to verify the client code every time you use it, it's only a bit more secure than a regular web chat site over HTTPS.

And, to be precise, by "a bit more secure" we mean "resists attacks by people who don't understand either Javascript or AES".

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#14
post #12
post #8

Cute, but unless you have some way to verify the client code every time you use it, it's only a bit more secure than a regular web chat site over HTTPS.

(Friend of the OP here.) That’s true, but it’s a problem with pretty much everything. Google (or an impostor) could , once in a million requests, send you JS that posts your Gmail password to Twitter. You probably don’t trust this site as much as Google, but the JS is unobfuscated and you can dump your traffic. That’s about as much as anyone can offer. Personally verifying the code and hashing it every time you use i…

Yes. You are right. It is the problem with pretty much everything. The issue here is that you haven't solved that problem. So your application is no more secure than anything.

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#15
post #9

A couple folks have kindly pointed out that it's wide open to to XSS attacks, since it allows full HTML posting. This is 100% true ... and doesn't matter one bit. The only information to steal via XSS is the password, and anyone who can submit an attack necessarily already knows the password. You can exploit this to annoy friends you're chatting with. Try, for example, submitting: body { background: #cc3333; } a { co…

... and of course, XSS here means "attackers can turn the crypto off."

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#16
post #14
post #12

Earlier quoted context omitted.

(Friend of the OP here.) That’s true, but it’s a problem with pretty much everything. Google (or an impostor) could , once in a million requests, send you JS that posts your Gmail password to Twitter. You probably don’t trust this site as much as Google, but the JS is unobfuscated and you can dump your traffic. That’s about as much as anyone can offer. Personally verifying the code and hashing it every time you use i…

Yes. You are right. It is the problem with pretty much everything. The issue here is that you haven't solved that problem. So your application is no more secure than anything.

No. Assuming it’s correctly implemented, it’s more secure than an identical app that sends the password over SSL to the server.

This is not an innovation in cryptographic theory, but it’s something you don’t usually see in a web app.

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#17
post #10

No, it's not as secure as your browser and AES. It's exactly as secure as Bonchat's servers and application code, because your browser is going to trust any Javascript fed to it from Bonchat.org, whether or not that code subtly destroys the security of the AES encryptor. Why even bother with JS AES? If you're served a court order, you can be forced to transparently record everything being said on the site anyways, wi…

Transparently? Without anyone being the wiser?

The javascript is there for the auditing. The server-side code is not, but you're completely free to analyze the client-side code to verify that it never sends your password to the server. I've avoided minifying any of it (save jquery.js, which you can diff against the official release to make sure I haven't modified it) to make it more auditable.

It's true that you probably won't check the javascript every time to make sure bonchat.org hasn't started serving up a compromised version. Just like I don't tcpdump my network traffic every time I boot up my OS X machine to make sure FileVault isn't secretly beaming my password home to Apple. The point is that I could. More practically (hah), I can randomly sample.

Actually, it would be pretty easy to verify the javascript each time. As long as you're satisfied that any version of the js is secure, you can save a copy to your hard drive and write a script (curl | diff?) to verify the server's copy every time you load up a bonchat.

No, it can't guarantee that the server is free from tampering. Nothing can. But I believe it's the first web chat secure/transparent enough that you can protect your data even if the server is compromised.

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#18
post #15
post #9

A couple folks have kindly pointed out that it's wide open to to XSS attacks, since it allows full HTML posting. This is 100% true ... and doesn't matter one bit. The only information to steal via XSS is the password, and anyone who can submit an attack necessarily already knows the password. You can exploit this to annoy friends you're chatting with. Try, for example, submitting: body { background: #cc3333; } a { co…

... and of course, XSS here means "attackers can turn the crypto off."

... and why did you give your chat password to someone who will use it to turn off the crypto? >_>

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#19
post #6
post #3

I'm having troubles with it in Firefox on two different Ubuntu machines. The page is all red, and the javascript source code is showing up inside the web page. Then I tested it in the Epiphany web browser. It worked fine on one Ubuntu machine, showing up all nice and blue. But on the other Ubuntu machine I got the red page with the javascript source code showing up, just like Firefox.

Yikes, thanks for pointing this out! I fixed a rendering bug in MobileWebkit and wound up breaking Firefox. It should work now. Gotta love web development.

Brilliant, works like a champ now!

Re: Bonchat - client-side encrypted web chat for the truly paranoid

#20
post #11
post #2

For any HN crypto nerds: I made a little web chat that even the server can't read. Besides boring old SSL, bonchat.org uses a javascript implementation of AES to encrypt chat client-to-client. There are no cookies, no sessions, and no account registration. You never even send your password or plaintext username to the server. If you chat with someone who knows the same password, you get a simple HTML/Markdown web cha…

It's not by-golly secure; it's insecure in a way that drives me perpetually nuts and that pushes a grevious misconception about how crypto algorithms can secure traffic in browsers. There is perhaps no worse place in the world to do crypto than in a Javascript interpeter bound to an HTML DOM and hooked up to a network.

Got a specific problem in mind? How would you attack this?
Post reply on HN