
Contact form encrypts message with PGP before sending - joushx
https://johannes-mittendorfer.com/kontakt
======
fooyc
Is 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.

~~~
mschuster91
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.

~~~
fooyc
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.

~~~
willvarfar
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.

~~~
fooyc
No need to do this on the client side then (that was my point)

~~~
willvarfar
You could do the exact same thing on the server, but that's using server's CPU
instead of clients?

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

~~~
devx
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.

~~~
y0ghur7_xxx
_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.

------
JosephRedfern
It must be suck to be Johannes right now... I wonder how many emails
containing random gibberish he is receiving?

~~~
joushx
They get sent right to trash! ;)

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

~~~
willholloway
What about:

1) Comparing hash of the js files loaded externally.

or

2) Keeping hash authenitcated javascript files from local disk?

~~~
eli
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.

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

~~~
zobzu
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.

------
cheyne
Nice.. You can also do in browser client and sever side encryption now with
[https://www.noteshred.com](https://www.noteshred.com)

See [https://www.noteshred.com/client-side-
encryption](https://www.noteshred.com/client-side-encryption)

------
sambeau
I'd never seen SocialSharePrivacy either (It's linked in the page code), but
it's an interesting idea:

[http://panzi.github.io/SocialSharePrivacy/](http://panzi.github.io/SocialSharePrivacy/)

------
aluhut
I love the usability of this.

I hope the issue of usability gets more attention in future security tool
development.

------
st00pid
google cannot translate his form. Why not? If I can see it, so can google.

~~~
joushx
Looks like gtranslate doesn't support https. Strange.

~~~
schrodinger
It's intentional so they don't try and translate, say, your bank statement and
end up sending it to google servers.

~~~
true_religion
I'm on Chrome and it handily translated the form.

------
mschuster91
Nice, but how did you port openpgp to Javascript?

~~~
rookonaut
I guess he used this lib:
[https://github.com/openpgpjs/openpgpjs/](https://github.com/openpgpjs/openpgpjs/)

~~~
joushx
Yes, that's true.

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

~~~
mschuster91
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.

