5 ms·
Contact form encrypts message with PGP before sending
- mschuster91 13y agoNice, but how did you port openpgp to Javascript?
- JosephRedfern 13y agoIt must be suck to be Johannes right now... I wonder how many emails containing random gibberish he is receiving?
- joushx 13y agoThey get sent right to trash! ;)
- rorrr2 13y agoAnd 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 13y agoYou 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.
- alternize 13y ago$.get("/static/pgpkey", function (key) { // store key // hook to submit button click event & encrypt before submit }); for the pgp encrypting he's using http://openpgpjs.org/ http://openpgpjs.org/
- deleted 13y ago[deleted]
- fooyc 13y agoIs 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.
- StavrosK 13y agoEh, 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.
- jis 13y agoYour 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....
- mschuster91 13y agoThis 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 13y agoIf 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 13y agoPresuming 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.
- mfwoods 13y agoI'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 13y agoit 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.
- sambeau 13y agoI'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/
- y0ghur7_xxx 13y agoThe 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 13y agoI'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 13y agoI'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.
- joushx 13y agoYeah, that's a point. Maybe i should really do that...
- aluhut 13y agoI love the usability of this. I hope the issue of usability gets more attention in future security tool development.
- st00pid 13y agogoogle cannot translate his form. Why not? If I can see it, so can google.
- joushx 13y agoLooks like gtranslate doesn't support https. Strange.
- schrodinger 13y agoIt's intentional so they don't try and translate, say, your bank statement and end up sending it to google servers.
- true_religion 13y agoI'm on Chrome and it handily translated the form.
- st00pid 13y agogoogle cannot translate his form. Why not? If I can see it, so can google.
- eli 13y agoThis 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 13y agoWhat about: 1) Comparing hash of the js files loaded externally. or 2) Keeping hash authenitcated javascript files from local disk?
- eli 13y ago1) 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.
- cheyne 13y agoNice.. 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