Things not to do with client-side script

Things not to do with client-side script

  • Comments 10

Browsing Slashdot, I saw an article about some browser-based encryption code called JavaScrypt (ha ha, funny name guys). I thought this was funny since I used to be the PM for JScript and now I spend some time thinking about security. Quite what the purpose of this tool is, I don't know. It seems to let you encrypt some data inside your web browser, and then... uh... look over there! It's Keanu Reeves!

As some of the comments on the article point out, the algorithm used is AES, a symmetric algorithm that requires a single secret key for both encryption and decryption (as opposed to asymmetric algorithms that use different keys for encryption (public key) and decryption (private key)). So although you can encrypt information using only your web browser, you can't actually send that information to anyone without also sending them the secret decryption key... and how are you going to do that? Probably in the same message / packet / HTTP request that you send the encrypted data in. Oh dear. Hope nobody is suckered into thinking this is "secure."

To be fair, the web site does suggest using keys that are communicated out-of-band, but the average user is not going to do this, especially a naive internet user who is conversing with someone on the other side of the world whom they've never actually met in person.

Another "cool" thing about this is that the site promises no data is ever sent from your machine back across the network, so it must be secure. And how can you be sure that no data is ever sent across the network? Because they let you download a ZIP file purporting to contain the source code, and then tell you in bold text that "Nothing is sent to any Web site when you encrypt or decrypt a message!"

Wow.

Say it with me now:

"W...O...W"

So now if I'm an ultra l33t h4x0r then maybe I can download the ZIP file, read the contents, completely understand it, and then install it on my local machine and use it as a local application. I certainly can't download the ZIP file, completely understand it, and then use the site on the web. Why? Because there's no reason why the stuff on the site has to be anything like the stuff in the ZIP file. (Not that I'm saying I think the people hosting the site would do that; just that it's a really bad thing for people to think that what they downloaded yesterday in a ZIP file is the same as what is on the live web site today).

The last thing we want to do is get into a world where people believe that just because a web site says "You can trust me because of XYZ" that they really can trust the web site because of XYZ without providing some other independent evidence. (And no, source code is NOT suitable evidence for the average person!). People are already confused enough about the web to submit all sorts of personal information into web forms embedded in e-mail messages claiming to be from AOL or ICQ or their bank. This kind of thing can only make things worse if it catches on.

But if this is only useful as a local application, why make it into a browser app at all? As Eric Lippert will tell you over and over again, ECMAScript really isn't the right tool for this kind of job. And as Michael Howard (and anyone else with a security background) will tell you, you should never write your own crypto code. (And you know that must be true because I just said it in bold text on a web page!). Use whatever libraries your platform provides. For Windows, that would be CryptoAPI and for .NET it would be System.Security.Cryptography. Obviously those don't provide the same kind of cross-platform support that ECMAScript does, but you still have Java Cryptography Extensions which should work most places.

One other funny thing: In one of the Slashdot comments, somebody said that they implemented some kind of browser-based encryption because their employer was too frugal (that's a euphemism for "tight" :-) ) to purchase an SLL cert. You can get a 1-year 128-bit cert from VeriSign for under $900, which is probably less than what it actually cost to develop and test the home-grown encryption (and almost certainly is more secure and carries less risk associated with it).

Now I'm sure this was a cool project to work on, and the people that did it were likely very smart and talented individuals. I don't want to sound completely negative. It's just that this sort of thing (pointless technology) isn't really what we need to help make the web a better place. We need better education.

  • Also plug into the CryptoAPI all you want. But what is the use of strong encryption in the face of poor crypto protocol design? They go hand in hand.
  • GeoTrust sells SSL serever certificates fro aprox. $100 9x cheaper than VeriSign and I am sure it took more than $100 worh of time to write this script, although I do think its cute.
  • You can get a certificate for even less than that... http://www.instantssl.com/ssl-certificate-products/ssl.html. $49/yr for a domain.
  • I did like a good engineer would, and went to the site. From the preceeding comments, it doesn't appear that ANY of the contributors on this thread did. Here is what I found: The site is run by John Walker, an industry heavyweight who founded AutoDesk and AutoCad. The particular 'script' mentioned above is not a kiddee script. It is a tool designed to easily encrypt/decrypt any old piece of text you might desire. The fact that it runs in your browser is immaterial. It is simply a decryption/decryption tool. I did a lot of work with Bokler's software. All of their stuff is command line driven (or was). There was nothing like a GUI that you could type into, or cut and paste into, and then just press a button. That is what John Walker's tool does. For free. Fritz Schneider is another big boy, probably still off at Google. He did a sweet Javascript implementation. By writing it in Javascript, he enabled the algorithm to be executed by a web browser, encapsulated with an HTML page, and dished up elegantly and simply to the user. You could do the same thing in an MFC app, but it wouldn't run under LINUX, and it wouldn't run on UNIX, and it wouldn't run on any big iron, and you couldn't download it, because, to the best of my knowledge, there is no MFC implementation/port of the AES encrypter/decrypter. So, all in all, John Walker really came up with a damn nice tool, for free. The public/private key issue is moot, because those problems exist regardless of the language the encrypter/decrypter is implemented in. That issue is called 'key transmission stragety', and is unrelated to the implementation of the algorithm, or the GUI the algorithm is wrapped in. Gotta go. Need another MOCHA Norzilla
  • I did like a good engineer would, and went to the site. From the preceeding comments, it doesn't appear that ANY of the contributors on this thread did. Here is what I found: The site is run by John Walker, an industry heavyweight who founded AutoDesk and AutoCad. The particular 'script' mentioned above is not a kiddee script. It is a tool designed to easily encrypt/decrypt any old piece of text you might desire. The fact that it runs in your browser is immaterial. It is simply a decryption/decryption tool. I did a lot of work with Bokler's software. All of their stuff is command line driven (or was). There was nothing like a GUI that you could type into, or cut and paste into, and then just press a button. That is what John Walker's tool does. For free. Fritz Schneider is another big boy, probably still off at Google. He did a sweet Javascript implementation. By writing it in Javascript, he enabled the algorithm to be executed by a web browser, encapsulated with an HTML page, and dished up elegantly and simply to the user. You could do the same thing in an MFC app, but it wouldn't run under LINUX, and it wouldn't run on UNIX, and it wouldn't run on any big iron, and you couldn't download it, because, to the best of my knowledge, there is no MFC implementation/port of the AES encrypter/decrypter. So, all in all, John Walker really came up with a damn nice tool, for free. The public/private key issue is moot, because those problems exist regardless of the language the encrypter/decrypter is implemented in. That issue is called 'key transmission stragety', and is unrelated to the implementation of the algorithm, or the GUI the algorithm is wrapped in. Gotta go. Need another MOCHA Norzilla
  • Norzilla, thanks for your remarks. The problem is not so much that I believe there are bugs in the implementation or that the people who wrote the code are incompetent (although obviously I would recommend using a platform-provided service rather than writing your own any day). The problem is that something like this will be ABUSED by people who do not know any better. If you read the Slashdot posts, you would see people thinking of this as a cheap way to get secure HTTP traffice without paying for an SSL certificate. That's just plain wrong -- there's no secure way to use symmetric encryption at the browser level without having previously communicated a secret key (which would require, uh, something like SSL). Something like this is a nice tool to play with, but it's not really what the web needs. I guess my post was more a reaction to the Slashdot comments rather than to the technology itself, but I fear this will be what the majority of people will think of when they see the site. "Why have encryption in the browser if not to secure web site communication?", the thinking will go. Also, you don't need ECMAScript to be cross-platform; any number of languages would have worked equally as well. Like, say, C, Perl, or even Java. ECMAScript is not designed for this kind of task. It's designed for displaying menus on web sites or doing simple form evaluation. To be able to verify the correctness of this code, you not only have to be an expert in AES implementations (which very few people are), you also have to be an expert in ECMAScript (which very few people are). An average Java or C++ developer cannot expect to read ECMAScript code of any degree of complexity and understand what is going on.
  • "ECMAScript is not designed for this kind of task. It's designed for displaying menus on web sites or doing simple form evaluation. " well, then ECMAScript must be the worst language ever made, cause it certainly doesn't fulfill it's designs well, but then of course this is because these two tasks are related to an environment in which ECMAScript is often used, an environment that often has problems of its own, especially where menu displays and such like are concerned. "If you read the Slashdot posts, you would see people thinking of this as a cheap way to get secure HTTP traffice without paying for an SSL certificate. " As there is a continueing argument regarding the efficasy of SSL I don't think a useful argument against a security solution is that it doesn't make use of SSL. " An average Java or C++ developer cannot expect to read ECMAScript code of any degree of complexity and understand what is going on." can't be expected to read lisp like languages and understand what's going on either, ECMAScript when used at a high level seems to be closer in spirit to Lisp-like languages then its own c-roots. of course I'm a sub-par Java developer and I find advanced ECMAScript very much to my tastes.
  • Any content encrypted with John Walker's tool is about as secure as anything on this planet. AES can't be broken without special big-boy hardware (NSA can crack AES in less than an hour - but they have 1024 bit wide custom built processors that we aren't supposed to know about). I checked out Fritz's algorithm, yes, it is the real McCoy. However, Peter, I agree with you. The web being populated, on average, by underinformed, over zealous about their own coolness, geek wannabees who neither have the time, technical background, or inclination to crack out a hard-core book and study... these folks may think they can get the benefits of an SSL line without paying for it. Fine. Do it. The tool only encrypts, or decrypts single messages, individually, no batch mode, no streaming, no ASP hooks, no nothing. It really is an ideal tool for Al Qaeda. They probably don't need it, having devised their own AES/Stego solutions a couple of years ago, but this certainly lowers the bar for any inner-city punk drug gang who wants to communicate their orders safely to their distributors in Canada. Question: Is knowledge dangerous? Has John Walker harmed the world by realeasing this tool, or did he make it better? "If you educate the masses, is this good? You make it harder to screw them, and easier for them to screw you!" The corollary is: If the masses are educated, you can't screw them quite as bad, but since their income level is now so much higher, a smaller screwing now turns a bigger profit, so education is good for everybody!! Just ask your local TV advertiser whether they would rather spend their advertising dollars on a gullible and uneducated public, or on a gullible and educated public. Guess what, the educated public has more money, so they are the better advertising base. Sorry about the off topic. I suppose criminals will always find a way to skirt the law, but one thing is for sure, John's tool makes it reeeeeeallllllll easy. M.O.C.H.A. Norzilla
  • Agreed. I don't (in general) believe in keeping information secret from The Great Unwashed. But in this case it isn't about handing them information (let alone "knowledge"); it's about handing them a tool which they don't understand. Very different ;-) (Glad to finally have some comments on my blog.. I should make more outrageous and controversial posts in the future <g>)
  • I agree with many of your points... however, I recently began using that script for the purposes of communicating certain sensitive content via email to co-workers. Not password sensitive, but "I don't want my bosses reading this" sensitive. It's ideal for that purpose because we've got a few platforms to deal with and we are able to communicate keys beforehand. Is that a poor use? I realize that there are other methods, but without drawing too much attention to ourselves (installing extra software, keeping any keys on our drives) we accomplish our goal.
Page 1 of 1 (10 items)