Clients may send messages encrypted with the same keys and overlapping counters. This could allow the server to recover information on the message contents.
There's also no authentication on the encrypted messages. A corrupt server can alter messages sent to a valid client without detection. This is trivial to do in counter mode.
Also, as people have already mentioned, if the server is compromised, then the Javascript is compromised.
Please consider joining our team? Pretty please? We just opened up a SF office. You're only sometimes going to have to deal with my ranting!
CTR nonce collisions are one of my most favoritest attacks. Everyone misses that. It doesn't help that CTR documentation isn't clear on how you should divide the nonce space up between counters and IV-style nonce; you'll find targets where you can induce them to wrap.
A corrupted server could alter messages without the key if it had both the plain and encrypted versions of a text. But to get that, the javascript would have to be compromise, and at that point the server might as well just steal the key anyway. This has already been discussed above, and if you're worried about it, the solution is actually pretty trivial. I especially like Whimsy's suggestion of a Grease Monkey script for verification.
You are incorrect on your statement that the corrupted server needs both the plain and encrypted versions of a message to send bogus messages. Without authentication, the server can flip arbitrary bits of a CTR message. This opens up several types of attacks. You should apply a MAC to the ciphertext.
I think that the encryption needs to happen entirely in the client and you can't rely on code downloaded from an untrusted server.
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, 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.
Even if you were among the 0.00000001% of potential users who could possibly look at a block cipher implemented in Javascript and judge whether it was intact (and among the 0% of people who would actually do this), you can't just look at one piece of code in JS and know what it's actually going to do. You have to have a way of assuring every single bound function in the entire Javascript runtime.
That mechanism of ensuring the entire state of a Javascript context in a browser? It doesn't exist yet in any modern browser.
Your last sentence? What a huge dodge. If your server is compromised, your users lose. My browser trusts your server absolutely. If you'd like me to demonstrate this to you vividly, you can catch me offline and we can arrange terms.
Another way would be to make it an option to only use the GreaseMonkey encryption - trust it to rewrite the JS on the page, so the user can control updates to the JS.
> Why even bother with JS AES? If you're served a court order,
> you can be forced to transparently record everything
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
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 chat. If you chat with someone using a different password you get gibberish. That's it. :)
It has a number of glaring flaws and no marketability, but by golly it's secure!
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.
Everything has a market. Some things just have a very, very narrow market :)
In seriousness though, in its current form it may not be that appealing but the idea probably has merit to some.
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:
<style>body { background: #cc3333; } a { color: #cc3333 }</style>
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.
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.
Your password is never sent to the server or stored in any cookies. You have to enter it every time because it only lives in browser memory while you view the page.
A cute side-effect of this is that you can chat with yourself under two different names by opening the same chat in multiple tabs. (You can also try chatting with two different passwords to watch the decryption fail.)
I've added a pseudo-random component to the nonce, and a MAC to the messages.
I certainly agree that you can't rely on code from untrusted servers, but I think doing the encryption in the client with code that is publicly viewable, even if it can be compromised at any time by a malicious server, is the best we can do for web apps unless/until major browser vendors incorporate client-to-client encryption. Right now there is no reliable protection against a compromised server, but I would like to at least see web apps strive to be more accountable.
I'm not making any promises of 100% perfect security with no effort and no room for attacks. Bonchat is merely an experiment in securing content against servers as well as network snoops.
I trust Linux more than Windows. I haven't personally audited all the code on my Linux box, and I don't know any one person who even has the skill to do so. But the code is there to be audited, which gives me more confidence than when I use a opaque operating system. The same applies here. Bonchat isn't perfect, it's just trying to be easier to keep honest than a normal web app.
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 you are asking for someone to write a really mean blog post about you and your actual understanding of how crypto works. That's drama you don't need. Don't bother with the AES stuff.
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. Again, I'd love improved code. But you have yet to make any rational argument that javascript in the browser is inherently unsuited to encryption.
I completely agree that the many attempts to make SSL irrelevant by doing all the encryption in JS (and usually horribly naive JS) are foolish. That's not the point. Bonchat isn't a shopping cart or a mail reader. SSL is for securing communication to the server. Bonchat is an experiment in securing communication against the server. Do you have a better way than client-side encryption?
This is not an innovation in cryptographic theory, but it’s something you don’t usually see in a web app.
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 fertile and interesting epsilon.
You, the owner of the server, change the code. That's the attack. There's no way for me to tell my friend Charlie that he can use the service and get secure communication, unless he installs a plugin for his browser to verify that the server has not changed the data it sends the user from the time when I verified the correctness of the code. And if he has to install a plugin to safely use this service, which is now never permitted to change its code, he might as well just install a plugin that has the code, or install a separate application for this purpose.
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.
(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.
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.)
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.
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.