Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bonchat.org

Post reply on HN
Print view View original

41–50 of 51 posts

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

#41

Post by tptacek »

nickbw wrote: post #34
tptacek wrote: post #32

Earlier quoted context omitted.

You say "po-TAY-to", I say "po-TAH-to". You say "to-MAY-to", I say "no thank you". You say "supersititious distrust of Javascript", I say "a day job finding, breaking, and fixing the horrible things people try to get away with doing in Javascript". (Or, less charitably: "knowing how Javascript works in browsers.") Trust me on this one. It's a cool little hack. It's even useful if you get rid of the vanity crypto. But…

If you would like to propose improved crypto code, I would love it . Honestly. But "javascript is a messy language" is not inherently an attack. You can obfuscate just about any language. Do you actually have an attack in mind based on the fact that it's implemented in the browser ? It's true I don't have a deep understanding of the AES algorithms, and the AES code, as stated in the attribution, isn't even mine. Agai…

You seem intent on evading the point. Most security systems don't depend on me being able to read the code every time I use it.

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

#42

Post by [deleted] »

nickbw wrote: post #40
Rhapso wrote: post #38

Earlier quoted context omitted.

as long as I am logged in, the password "new_pass" will also allow you to join this chat (abet with a messed up user list, but all text is readable) This is done by adding javascript to my username that changes the password in all those who log in normally.

Heehee. Nice!

[deleted]

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

#43

Post by tptacek »

celoyd wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

It's something you don't see in web apps because the idea has been roundly rejected. Because in almost every setting where you could possibly implement crypto in JS, you have to run the app over HTTPS anyways, you gain only epsilon more security than if you would without added crypto --- and that's if you get everything right .

Sure. As this is designed now, HTTPS’s prevention of malicious JS insertion is the big weak point I see. But it’s implicitly asking what you could do if you found ways of getting around that, for example by using client-side caches of the code after a strict initial check. The real wow for me here is that JS is fast enough to do AES-128 at comfortable chat speed. That’s really suggestive. It’s an epsilon, but it’s a…

Nothing you just said is in the marketing material for this. Instead, it promises to be (paraphrased generously) so secure that not even the operators can tell what people are saying over the service.

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

#44

Post by Rhapso »

Rhapso wrote: post #38
JoshCole wrote: post #21

https://bonchat.org/cb9d007ac6e12605 pass: hacker news

as long as I am logged in, the password "new_pass" will also allow you to join this chat (abet with a messed up user list, but all text is readable) This is done by adding javascript to my username that changes the password in all those who log in normally.

Nevermind, HTML is no longer posted in such a way that we can inject javascript with the old method. I need to go turn off my troll bot that is now spewing nonsense due to the client being updated.

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

#45

Post by nickbw »

tptacek wrote: post #41
nickbw wrote: post #34

Earlier quoted context omitted.

If you would like to propose improved crypto code, I would love it . Honestly. But "javascript is a messy language" is not inherently an attack. You can obfuscate just about any language. Do you actually have an attack in mind based on the fact that it's implemented in the browser ? It's true I don't have a deep understanding of the AES algorithms, and the AES code, as stated in the attribution, isn't even mine. Agai…

You seem intent on evading the point. Most security systems don't depend on me being able to read the code every time I use it.

Most web security systems don't even give you the option. You sends your data off and you trusts your server. You can't read the code at all because it lives on a box you don't have access to.

Any security system you didn't code yourself does rely on someone you trust having read it at some point.

Is it more secure than some audited local code you compiled months ago and haven't touched and don't have to re-download? No, of course not. Is it more secure than chatting on Facebook? Potentially, yes. The necessary transparency is there.

This is not an innovation in protecting your data from network snoops. In that sense it's no improvement on SSL and it's not trying or claiming to be.

What it does do better than other web apps is protect your conversations from the middleman you can't avoid -- the web server itself.

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

#46

Post by tptacek »

nickbw wrote: post #45
tptacek wrote: post #41

Earlier quoted context omitted.

You seem intent on evading the point. Most security systems don't depend on me being able to read the code every time I use it.

Most web security systems don't even give you the option. You sends your data off and you trusts your server. You can't read the code at all because it lives on a box you don't have access to. Any security system you didn't code yourself does rely on someone you trust having read it at some point. Is it more secure than some audited local code you compiled months ago and haven't touched and don't have to re-download?…

Nick. Please. It doesn't do this thing you keep claiming it does, because you left out any mechanism for the client to verify the code the server sends. You keep implying, directly and indirectly, that clients can do this by hand. People keep telling you, no they can't. When I give a specific and unintuitive reason why people can't manually verify your code in a browser, you throw out a smokescreen about how Javascript is a fine language to write things in, which of course has nothing to do with the issue at hand.

(By the way, thing you don't want to hear from the guy offering you super-secure communication system? "You have a superstitious paranoia about Javascript".)

And, as Steve Weis took the time to point out, even if you had invented some new system by which browsers could verify the state of a Javascript interpreter fed by an app that, among other things, had until a few hours ago a bunch of obvious Javascript injection flaws, you still wouldn't have been secure, because you don't really understand how CTR mode works and implemented colliding nonces. (Why did you bother with CTR mode anyways?) You also don't seem to understand the relation between encryption and authentication; not having a MAC would just be an embarassing oversight if you hadn't then argued with Weis about why it wasn't necessary.

The security model behind this application is just a really bad idea, Nick. I know that's tough to hear, since you obviously put some time and effort into it, but you're going to need to zag instead of zig now and come up with something cool about this chat system other than the notion that it's somehow more secure than Campfire or any other https chat.

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

#47

Post by nickbw »

tptacek wrote: post #46
nickbw wrote: post #45

Earlier quoted context omitted.

Most web security systems don't even give you the option. You sends your data off and you trusts your server. You can't read the code at all because it lives on a box you don't have access to. Any security system you didn't code yourself does rely on someone you trust having read it at some point. Is it more secure than some audited local code you compiled months ago and haven't touched and don't have to re-download?…

Nick. Please. It doesn't do this thing you keep claiming it does, because you left out any mechanism for the client to verify the code the server sends. You keep implying, directly and indirectly, that clients can do this by hand. People keep telling you, no they can't. When I give a specific and unintuitive reason why people can't manually verify your code in a browser, you throw out a smokescreen about how Javascri…

Actually I really appreciate Weis' comments, because they're actual concrete problems and implementable solutions. (A bit-flipping attack is not particularly interesting by itself, since the server can inject gibberish any time it wants anyway, unless it can be used to insert meaningful content. But I will be happy to add both a MAC and a better nonce.)

What I don't understand is why you think any unaudited code is secure. There is no mechanism by which code from an unknown source becomes trustworthy without someone reading it, or being able to read it.

Nowhere am I suggesting that understanding the javascript source is quick or easy, but it is in fact possible, which is the difference between encrypting client-to-server vs. client-to-client. Source code you can view is not automatically trustworthy. Of course not. But it is easier to trust than code you will never be allowed to see. Can we at least agree on that much?

As far as trustworthiness, I would say: local code > remote code run on the client > remote code run on the server > closed source. This makes (a theoretically fatal-bug-free) bonchat-like system worse than PGP, but better than Facebook IM.

It sounds like your real complaint is with the "marketing", such as it is. Perhaps I should do a better job labeling it as experimental, or a proof of concept? These would be actual concrete criticisms.

Folks complaining of XSS vulnerabilities seem to be under the mistaken impression that it somehow secures you against the people you're talking to, which is not the problem it's trying to solve. Unescaped HTML chat is vulnerable to XSS, which is why you shouldn't exchange raw HTML with random strangers. You wouldn't open an HTML attachment from a stranger, but you'd open one from your good web developer friend.

(A very fair complaint is that, although XSS is irrelevant to the intended use, I should've anticipated that people would want to test/demo the basic chat features by broadly distributing passwords. This turns it into, essentially, a plain text chat with two URLs you have to enter. Which is useless, but perhaps amusing, so I've added default HTML escaping.)

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

#48

Post by tptacek »

nickbw wrote: post #47
tptacek wrote: post #46

Earlier quoted context omitted.

Nick. Please. It doesn't do this thing you keep claiming it does, because you left out any mechanism for the client to verify the code the server sends. You keep implying, directly and indirectly, that clients can do this by hand. People keep telling you, no they can't. When I give a specific and unintuitive reason why people can't manually verify your code in a browser, you throw out a smokescreen about how Javascri…

Actually I really appreciate Weis' comments, because they're actual concrete problems and implementable solutions. (A bit-flipping attack is not particularly interesting by itself, since the server can inject gibberish any time it wants anyway, unless it can be used to insert meaningful content. But I will be happy to add both a MAC and a better nonce.) What I don't understand is why you think any unaudited code is s…

Nick, "bit flipping attacks" imply that attackers can make messages say whatever they want to. They do not simply mean attackers can inject "random gibberish".

Furthermore, your nonce problem doesn't mean attackers can inject messages; it means attackers can cryptanalyze messages.

It would be helpful, before trying to implement cryptographic security for other people, for you to spend some time researching cryptography. A great way to do that is to learn how to attack cryptosystems in other applications. Maybe that should be your next project.

Best of luck, Nick.

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

#49

Post by alecco »

tptacek wrote: 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…

  > Why even bother with JS AES? If you're served a court order,
  >  you can be forced to transparently record everything
They can try the "Warrant canary" approach. Nothing to lose (but I'm foreign and not a lawyer.)

http://en.wikipedia.org/wiki/Warrant_canary

Still it would be vulnerable to ISP-level MitM with SSL CERT hijacking. Aren't major government agencies (at least technically) able to control root CAs?

EDIT: (relevant discussion on the Clipperz forum) http://groups.google.com/group/clipperz/msg/c4e5f76af2e77bf6

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

#50

Post by nickbw »

tptacek wrote: post #48
nickbw wrote: post #47

Earlier quoted context omitted.

Actually I really appreciate Weis' comments, because they're actual concrete problems and implementable solutions. (A bit-flipping attack is not particularly interesting by itself, since the server can inject gibberish any time it wants anyway, unless it can be used to insert meaningful content. But I will be happy to add both a MAC and a better nonce.) What I don't understand is why you think any unaudited code is s…

Nick, "bit flipping attacks" imply that attackers can make messages say whatever they want to. They do not simply mean attackers can inject "random gibberish". Furthermore, your nonce problem doesn't mean attackers can inject messages; it means attackers can cryptanalyze messages. It would be helpful, before trying to implement cryptographic security for other people, for you to spend some time researching cryptograp…

I appreciate your concern, Thomas, but you seem to be telling me that:

1. no one will be able to gauge the integrity of a web app by reviewing the code, and

2. I should fix the security problems sweis found by reviewing the code.

I wholeheartedly agree with #2 (and I'm working on it now), but it rather contradicts #1.

I threw this thing together because I'm a long-time open source fan and I've been watching as more and more code people entrust their privacy to moves behind the opaque border of the web app cloud. I'd like to find ways to deal with that.

Bug reports are interesting and useful, and I'm extremely grateful for them. My implementation is flawed, no doubt in ways beyond the ones sweis has already pointed out, and discovering those flaws is one reason I posted it somewhere like HN.

But simply declaring that javascript is an unsuitable language for encryption, or that web clients are an unsuitable environment, doesn't add anything factual. I think code transparency is a boon to security, and I would like more web apps to at least try to make their security reviewable, even if reviewing is a job for experts. If you don't think that code transparency adds anything useful, well, fair enough. I respectfully disagree.

Post reply on HN