SSL without HTTPS.

[ajaxvador]

aSSL is a library distributed under MIT License (http://www.opensource.org/licenses/mit-license.php) thats implements a technology similar to SSL without HTTPS.

http://assl.sullof.com/assl/



I will try to integrate this module in EXTJS.... to be continued ...

[ajaxvador]

Any idea ... contribution ... \:D/

[mjlecomte]

FYI:
http://extjs.com/learn/Extension:Crypto

[jay@moduscreate.com]

i'm wary of this type of technology.

[ajaxvador]

Why you are wary oh this technology ?

[devnull]

Theres not really any reason to be untrusting of something like this, as it just moves the encryption from the browser itself into the javascript. It seems like it would be only usefull on sites where the author cannot or will not install an ssl cert. It could be considered less secure though, since the javascript code itself would still be traveling in the clear and be subject to various content modification attacks.

[ajaxvador]

Indeed there may be attacks, I can encrypt the code javascript. I need my secure website and retrieve data by the JSON

[Gunmen]

What is the current status of this "aSSL" in combination with ExtJS?

Is this save enough compared with a real https connection?
Or certificate?

Thanks!

[Mike Robinson]

You have this nifty encryption squawk-box. You take your secret messages and put them into the box. You take the secret answers out of the box.

Several problems:

(1) Exactly where is your communication not secret? "Before you put it into the box, and after you take it out." Same as with standard SSL.

(1a) But, exactly where can the communication be tampered-with? Two places! After you have run the data through the encryptor, you must somehow deliver it to the transport to be sent on its way. Thus, the mechanism is both more complicated and more vulnerable than "ordinary SSL," which is built-in to the browser and transparent to you.

(2) "It came in an identical looking box, so you had no way to know that it was a Trojan Horse. It encrypted the packets just like you thought it would, but you didn't know that it was simultaneously sending a copy of those packets to me."

or: (2a) "Well, the problem was, the user didn't install it correctly. So the packets actually went out over the network in the clear. It was a software mistake, but it devastated the merger-and-acquisitions talk and attracted the attention of the SEC."

When you are dealing with encryption, such that it really matters, the last thing you want to do is to "roll your own." The accepted pathways are well-trod, and peer-reviewed. They might have some egregious flaw, but, "probably not." In my mind it would be far better to be able to testify, in your own defense, that you used appropriate, industry standard implementations of well-known, industry standard protocols. That you did exactly what all the other Romans did. And, that you (your company) administered the system with knowledgeable due diligence.