Contact form encrypts message with PGP before sending
johannes-mittendorfer.comIs there any benefit of doing this on the client side?
The message is sent through HTTPS anyway.
If HTTPS was compromised, the javascript code signing the message, and the signing key, and everything related to handling the clear text message would be compromised too anyway.
This is redundant with HTTPS, but also useless if HTTPS is MITM.
This can protect against malicious browser extensions recording POST/GET-transmitted data (toolbars!!!), as the content will be encrypted at that stage.
Furthermore, this helps against content disclosure if the server is compromised.
If your browser is untrusted, you are doomed.
> Furthermore, this helps against content disclosure if the server is compromised.
If the server is compromised, openpgp.js is compromised too.
Presuming the private key for the messages is not on the server, then old messages will not be compromised.
A kind of perfect secrecy for messages.
No need to do this on the client side then (that was my point)
You could do the exact same thing on the server, but that's using server's CPU instead of clients?
Forward secrecy with https? https://community.qualys.com/blogs/securitylabs/2013/08/05/c...
yeah its often called perfect forward secrecy - PFS - too.
Eh, it might be a bit useful if there's a passive adversary on the server. They can read traffic, but not change anything. Pretty unlikely scenario, so it doesn't really buy you much.
Your cloud hosting provider can easily be a passive adversary. Altering your data is risky for them (you might notice) so they won't alter your copy of openpgp.js or the public keys you use. But looking at all of your disk and memory and network is something they can do and you would never know. But if the private key is not on the server, they will never be able to decrypt the messages encrypted for you....
The page loads jquery from google cdn, so at least google could inject js in the page and read the message before it gets encrypted.
I know, for a contact form this is very unlikely, but just from a security point of view, if I would write something like this, I would host js loaded by the page on my own server.
I've been wondering about web crypto, and how you can actually be protected from say Google getting your content before it's actually encrypted in the browser. Could Chrome's recent "packaged apps" help with that? Maybe if that part of the web app/extension was actually native/offline (but still inside the browser), it would be secure against that. Of course then you have to start wondering whether Google didn't implement a backdoor inside the browser itself...but maybe the fact that Chromium is open source can help there.
I've been wondering about web crypto, and how you can actually be protected from say Google getting your content before it's actually encrypted in the browser.
Just don't load third party js from a domain you don't own, use tls and you are good.
Yeah, that's a point. Maybe i should really do that...
It must be suck to be Johannes right now... I wonder how many emails containing random gibberish he is receiving?
They get sent right to trash! ;)
This idea (encryption in javascript in a regular web browser) comes up very often on HN. It's not a good idea. Since I have no way to trust/verify that the encryption code itself has not been tampered with (beyond HTTPS) then it is only secure as HTTPS.
You've added a fair bit of complexity for no specific benefit; likely a net loss in terms of security.
What about:
1) Comparing hash of the js files loaded externally.
or
2) Keeping hash authenitcated javascript files from local disk?
1) Compare the hash to what exactly?
2) Then why not just store the files themselves to local disk? They can't be updated anyway. Or, indeed, just install GPG.
I'm not sure what this adds over applying PGP on the server?
The way to intercept the message with the server doing PGP would be to either MITM the connection or breach into the server to intercept before encryption.
In both cases you could just as well modify the javascript served to the browser to defeat the PGP done in the browser as well.
it adds not much. it does make it more complex to intercept because you need to serve diff js. il also means cleartext isnt on the server at all til compromised.
but yeah the design is bypassable. thus not really safe. clients should do it natively i guess.
Nice.. You can also do in browser client and sever side encryption now with https://www.noteshred.com
I'd never seen SocialSharePrivacy either (It's linked in the page code), but it's an interesting idea:
I love the usability of this.
I hope the issue of usability gets more attention in future security tool development.
google cannot translate his form. Why not? If I can see it, so can google.
Looks like gtranslate doesn't support https. Strange.
It's intentional so they don't try and translate, say, your bank statement and end up sending it to google servers.
I'm on Chrome and it handily translated the form.
Nice, but how did you port openpgp to Javascript?
And where's the key stored on the client and how is it shared with the server?
I'm too lazy to parse their JS code.
You don't need a private client key for just encryption, the public key of the recipient is sufficient.
For signing, you'd need a pub/priv keypair, but this is not implemented here.
for the pgp encrypting he's using http://openpgpjs.org/$.get("/static/pgpkey", function (key) { // store key // hook to submit button click event & encrypt before submit });