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.
Furthermore, this helps against content disclosure if the server is compromised.
> Furthermore, this helps against content disclosure if the server is compromised.
If the server is compromised, openpgp.js is compromised too.
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.
Just don't load third party js from a domain you don't own, use tls and you are good.
You've added a fair bit of complexity for no specific benefit; likely a net loss in terms of security.
1) Comparing hash of the js files loaded externally.
or
2) Keeping hash authenitcated javascript files from local disk?
2) Then why not just store the files themselves to local disk? They can't be updated anyway. Or, indeed, just install GPG.
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.
but yeah the design is bypassable. thus not really safe. clients should do it natively i guess.
I hope the issue of usability gets more attention in future security tool development.
I'm too lazy to parse their JS code.
For signing, you'd need a pub/priv keypair, but this is not implemented here.
$.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/