Assl

[shawn wilson]

Anyone seen this?
http://assl.sullof.com/assl/

Is there any work to get this working with node? Any interest?

[akira]

Very interesting, it would be great to get it to work with Node or
Python. The project looks dormant. It might be taken up again if
interest is shown.

On Apr 28, 10:32 am, shawn wilson <ag4ve...@gmail.com> wrote:
> Anyone seen this?http://assl.sullof.com/assl/

[Oleg Efimov (Sannis)]

Oops:  http://assl.sullof.com/assl/securityfaq.asp

I can't  feign any situation, when it is useful. It is not so problem to buy sertificate and enable HTTPS on server today.

суббота, 28 апреля 2012 г., 12:32:56 UTC+4 пользователь shawn wilson написал:

[akira]

Well, wildcard certs are expensive. Its would be good for apps that
have little or no funding but need security od some kind

[shawn wilson]

right, it might also be good if you want secure transfers but don't
want to buy *any* cert. ie, you don't want the browser to say 'this is
an untrusted site, continue' or whatever. i realize there are inherent
risks in this. but, not much more of a security risk than ssh as long
as you store the pub key in a cookie.

2012/4/28 akira <nhy...@googlemail.com>:

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[mscdex]

On Apr 28, 9:03 pm, shawn wilson <ag4ve...@gmail.com> wrote:
> right, it might also be good if you want secure transfers but don't
> want to buy *any* cert. ie, you don't want the browser to say 'this is
> an untrusted site, continue' or whatever. i realize there are inherent
> risks in this. but, not much more of a security risk than ssh as long
> as you store the pub key in a cookie.

Startssl.com has free SSL certificates.

[Michael W]

Ew. I think this project is harmful because it offers a false sense of security. How is the client-side encryption javascript sent to the browser in the first place? If it's not already sent over SSL, it can be intercepted and modified by attackers to send a copy of the cleartext to the attacker, for example.

The reason why SSL is secure is because it's already baked into the browser and attackers can't tamper with that machinery. This project removes that.

[shawn wilson]

Hummm, that's probably a good point. I can't wait to get back to a computer and see what the code says about that.

--

[Jeff Barczewski]

From the main page, it looks like it is using the server's public key to encrypt the random session key which only the server can decrypt using its private key, then uses the session key with AES for the duration of the session.

So it doesn't sound like anything is sent over in the clear.

However you are correct in that it doesn't have as many safe guards as SSL in that you don't have any independent verification that the server you are talking to really is the legitimate server. All you know is that your communications with this unverified server are reasonably secure. Kind of similar to the same security we have when people generate their own unregistered SSL certs and tell people to just accept the security warning the browser pops up (encryption but not verification).

[Richard Marr]

On 1 May 2012 16:50, Jeff Barczewski <jeff.ba...@gmail.com> wrote:
> All you know is that your communications with this unverified server are reasonably secure

You as the developer of the site might know that the data is secure. Your users would have to take your unverified server's word for it... which I'm sure you agree is a Bad Thing from the perspective of encouraging internet safety.

It's an interesting lib though, it'd work for internal company apps where there's an established level of trust/auditing/accountability.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
Richard Marr

[Felipe Sateler]

On Tuesday, May 1, 2012 11:50:58 AM UTC-4, Jeff Barczewski wrote:

However you are correct in that it doesn't have as many safe guards as SSL in that you don't have any independent verification that the server you are talking to really is the legitimate server. All you know is that your communications with this unverified server are reasonably secure. Kind of similar to the same security we have when people generate their own unregistered SSL certs and tell people to just accept the security warning the browser pops up (encryption but not verification).

You also lose because you cannot control for the fact that it is actually assl that it is running. Code can be injected (dns spoofing, browser extensions, whatever), resulting in text not being encrypted. 

Others have already explained why browser-javascript encryption is doomed to fail, so I leave you this link: http://www.matasano.com/articles/javascript-cryptography/