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.
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:
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: