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.
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.
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.
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.
On Apr 30, 2012 2:53 PM, "Michael W" <hotdog...@gmail.com> wrote:
> 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.
> On Saturday, April 28, 2012 2:32:56 AM UTC-6, shawn wilson wrote:
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).
On Monday, 30 April 2012 13:53:51 UTC-5, Michael W wrote:
> 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.
> On Saturday, April 28, 2012 2:32:56 AM UTC-6, shawn wilson wrote:
On 1 May 2012 16:50, Jeff Barczewski <jeff.barczew...@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.
On 1 May 2012 16:50, Jeff Barczewski <jeff.barczew...@gmail.com> wrote:
> 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).
> On Monday, 30 April 2012 13:53:51 UTC-5, Michael W wrote:
>> 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.
>> On Saturday, April 28, 2012 2:32:56 AM UTC-6, shawn wilson wrote:
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/
