A contact form that is hosted on a HTTPS protected website already does the job. The main difference is that it is usually (but not necessarily) only transmitted encrypted, not stored in encrypted form.
Here's a tip: If you generate an email from the content of the contact form anyway, why not make it an encrypted mail? It's rather easy if you use mailx from the heirloom-mailx package that is part of Debian, Ubuntu and probably a lot of other Linux/BSD/UNIX distributions. Here are the required steps:
In ~/.mailrc:
set smime-ca-dir=/home/user/smime
set smime-ca-file=/home/user/smime/1_Intermediate.crt
set smime-encrypt-user@example.com=/home/user/smime/2_user@example.com.crt
Then every mail sent to user@example.com using "mailx" will be encrypted using S/MIME.
Got no local MTA installed? You can make mailx send the mail directly via SMTP:
$ echo mail body | mailx -s "subject" -S smtp=mail.example.com:25 -S smtp-use-starttls user@example.com
That's still vulnerable to coldboot style attacks. If the data is never unencrypted unless you're readining it that's technically safer. But yes you are right that would work as well.
Hawkpost (the project introduced here) is also vulnerable to a coldboot attack - if the server that sends the page with the javascript is compromised, all bets are off.
You need to trust the server at some point. Assuming you do then it doesn't matter if the at-rest encryption is done in the browser or on the server.
I'd be happy with HTTPS upload and PGP encryption before writing to disk or forwarding. I think the biggest risk of a secure upload server is a vulnerability exposing a disk full of secure content in the future.
Not a bad idea, but this isn't a thing browsers currently do, and the average person can't do that with ease. Especially considering this web app is aimed at non-tech savvy individuals.
The weakest link I can identify here is MITM attacks when you're sending the link.
Imagine:
Alice generates a link.
Sends the link to Bob over an unencrypted/unauthenticated link.
Mallory intercepts the link. Generates his own link and send that link to bob.
Bob enters the confidential information on Mallory's link.
Mallory sees the confidential information, and then sends it to Alice's original link.
The only way to prevent this type of attack is sending the link over a secure channel. But if you already have a secure channel - what's the use case?
The channel does not need to be secure, only authenticated. So e.g, you could send them a Slack message then have them call you to confirm you just sent that link and not someone who hacked your Slack account.
It's fine to have someone snoop and see the link, as long as they can't change the link in transit.
>But if you already have a secure channel - what's the use case?
You can use Whatsapp, or some other E2E-encrypted service that is easy to use, and then transmit the sensitive data over encrypted email, which is more convenient for long-form text.
You are right on this one. The only protection against this situation implemented (right now), is that the email address to where it will be sent and the fingerprint of the key that will be used to encrypt, are shown to the user of the link so he is able to verify it. This way mallory's email address will show up on the page and the user can see he is not be sending to the right person.
This might not be enough for the app use cases, but we are working on more solutions so the user can be sure that it is going to the right person.
Regarding the last statement, lets assume the "secure" channel they have is chat app, like slack, for example, it will store the content indefinitely and will be there in clear text, not only slack can see it but if a smartphone/computer is lost,stolen or accessed by someone else they will be able to see all history and content sent through it.
Hi, I'm one of the contributors of the project and we started this because of the need to deal with clients sending us information through insecure channels. We have been using it for a while at Whitesmith and it entered our team's workflow smoothly.
Please feel free to ask any question and I will try to answer the best I can.
Note: The project is open-source so you can self-host it. Contributions are welcome.
It would be lovely to have keybase integration! I've just copy/pasted my GPG public key and fingeprrint from the keybase website into the hawkpost settings, and it works great!
Agree. Currently keybase can be used as the key-sever url supplied by the user, but in the future making a real integration to take advantage of some cool keybase features would be nice.
This is a great idea but I often have this problem the other way around.
I regularly want to send encrypted data to companies that don't know how to decrypt it. The number of firms that ask for sensitive info to be emailed across (or not much better - use dropbox) is crazy.
Protonmail has the ability to send a password-encrypted message to anyone. They just get a link and you have to give them the password through other means.
All encryption is handled client-side in js (they recently became maintainers of that library as well, iirc). The message can also expire after x days and the recipient can reply.
I'm not sure if I like how they're basically inventing their own encryption scheme for emails instead of supporting pgp, but for these use-cases it's quite slick.
This is the most basic step, but even this is non-trivial. There are multiple ways of password protecting a zip, ZipCrypto is insecure and not all software supports AES-256. Self-extractors will get stopped by AV and sometimes even password protected zips (as the AV can't read them).
You then have to communicate the password out-of-band, as emailing it would defeat the purpose. It may be hard to read over the phone and you have to trust it was not written down and the file is not then stored/forwarded unencrypted. Explaining the process to someone non-technical may be challenging.
Symmetric crypto is a mess, asymmetric would be great if secure key exchange could be easy. If only the software was as ubiquitous as zip handling is in the OS.
Microsoft solves this with RMS for Individuals: https://portal.aadrm.com/ (also called the RMS Sharing App, now getting rebranded to Azure Information Protection).
The recipient's identity is the key to opening the content - no need to communicate anything out-of-band. Depending on the file format chosen, you get DRM features limiting granular actions on the file beyond view/edit.
To open the protected files, your recipients will have to download/install the (free) app from Microsoft. This is generally pretty painless.
Definitely worth checking out, especially good for consultants' workflows.
That is essentially corporate policy at my workplace. We use in-house file-sharing system, and I think the recommendation is to prefer 7z over vanilla zip. Typical channel for sending password is via SMS.
Its not elegant, but in the end I find it reasonably good compromise between security and practicality.
Thats an use case that we also encounter often, we are still thinking about a solution (be it through Hawkpost or something else).
The other way around is definitely an harder problem, if we want to keep it simple for the non-tech savvy user.
> In open source software the solution to this problem is
> "well, you could always just host your own instance"
That doesn't always work though - end-users can't trust you more because you host it instead of using the version hosted by the OSS team for whom it's the main focus. (Arguably they should actually trust the latter more!)
Consider Keybase for example. If someone builds a service on top of Keybase, their end-users can't trust them with their private keys* if they host it themselves instead of using upstream hosting.
*I know this is not required in order to use Keybase - I use it with gnupg and keep my keys local. It's the easiest example of needing to trust Keybase, though.
That is something I already though about but never found anything about it on the Internet, or any discussion that might lead to a way of solving that problem. It might be an interesting project.
Either way, I added that line to the readme so readers could easily test the project.
Yep, I wasn't criticising you or saying it was a problem - I just think it's interesting that for security-related software there's so much emphasis on a need for open source code, when actually showing that that is in fact the source code is much harder.
This is actually an extremely common kind of enterprise security product --- though none of them do the Javascript/PGP dance.
Enterprise security teams know, of course, that email is insecure, and that partners and clients want to send sensitive stuff via email. So they buy these products and stand them up, and then instruct their partners to follow a link to upload their documents or sensitive emails, rather than using their email client.
The box itself forwards the email to user inside the enterprise.
I think there's something useful here, but, like 'Tepix said: a simple form on an HTTPS site is already doing 99.999% of the useful work here (that's all the expensive enterprise products do, too).
A direction you can take this to be even more useful is to strip and sanitize attachments, as a way of quarantining malicious email.
This is handy but I don't find it particularly pleasant that my email address would be written in plain text on the web page. A service like keybase.io helps with the key discovery and encryption part while not revealing my email address in such a way.
That looks cool. I think you might get better traction by selling it to businesses such as solicitors and brokers. You could white-label it with their branding and host it for them on a sub-domain - upload.low-tech-accountants.com.
If you can get the library to the sender's browser without security problems then it probably can securely encrypt the text and send it to the target. But is it always secure to send someone the library that you want to use?
I've written a Firefox plugin [0] that checks hardcoded hashes (which can of course only work if the code doesn't change often) and a not-yet-published Chrome plugin that checks the source against the version on GitHub (which requires you to trust that either the webserver or GitHub will not be compromised).
@chomponthis: hit me up if you want to work on making either or both plugins work for HawkPost, email in profile.
thanks, I didn't had the time to carefully see the provided link, but the concepts looks interesting. The code is still changing with some frequency, when it starts to slowdown, we will come back to this.
But the person has to trust that you understand security well enough to prevent your server being compromised, which is not trivial.
That is, it's much easier for an average developer to install this on their server than it is for them to understand the security well enough to guarantee that no one else is snooping on said server. Right?
The alternative, using local encryption software has its own risks. As a user, I'd much rather run some code in a browser sandbox than on my desktop, where it has potentially far more access (even if not run as root).
Yes, there is no JS source signing in the browser yet. Then again, do you check the (compiled) code that is delivered to you via source repositories with which you sign/encrypt your GPG messages? How many people read the OpenSSL source code? How trustworthy are the signatures on Debian packages?
"Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched file must match."
SRI is a great way to make an html page that loads all the js from a server, tell the user to store that locally, and be sure that the loaded js files will never change (otherwise they won't get loaded).
Purely for UX, it's easier to say "save the page you're currently viewing" than "save this page and also these files". It's not a huge difference, though, as you noted.
We actually use Keybase as well, and that was one of our inspirations for the exact same reasons! Since one of our main use-cases was to receive secure data from non-tech-savvy people we wanted to remove as much friction as possible, and that included sending the encrypted blob. We're actually thinking of ways of integrating Hawkpost with Keybase.io, namely fetching/verifying keys (as we already do with keyservers).
Ha, the use-case reminds me of something I wrote a few months back.
A complete in-browser RSA encrypted message sharing for one-time use. Like transferring passwords via unsecure channels (aka Skype).
It generates a keypair in the browser (offline) and guides also unexperienced users through the process. Frankly, its a dirty hack, but it does the job haha.
I usually use a burn-after reading paste in 0bin.net for that, but I like the idea of sending an email. Altough it could be use for spam don't you think ?
That was one of our concerns, to receive information you can setup different "boxes" with an expiration date. Each box as an hard to guess url (such as https://hawkpost.co/box/19f1e7b9-f200-47ec-b5ff-918a9483a546), so only the people you shared it with, will know how to access it.
You can also set the maximum number of messages you wish to receive through that box.
I think these measures will help users avoid spam.
In my opinion when it is possible to secure the data. People often need to share secrets such as passwords or keys to access some service or server. When compromised depending on the key it can bring some serious consequences (example: http://www.theregister.co.uk/2015/01/06/dev_blunder_shows_gi...)
Nothing is stored and probably the most relevant difference is the medium, you might not have those contacts in a secure e2e encrypted chat (probably they only use skype), but almost everyone uses email.
$ echo "Hello world" > message.txt
gpg --sign message.txt
$ gpg --verify message.txt.gpg
gpg: Signature made Wed 19th october 2016, 12:19:19 CEST using RSA key ID D9AE6E9E
gpg: Good signature from "John Smith <john.smith@example.com>"
$ echo "evil" > message.txt
$ gpg --verify message.txt.gpg
gpg: Signature made Wed 19th october 2016, 12:19:19 CEST using RSA key ID D9AE6E9E
gpg: Good signature from "John Smith <john.smith@example.com>"
He's saying that, even though he changed the message, the signature still validated. He doesn't realize that the resulting GPG file contains the message, so it's verifying it against its own, stored copy.
That's what I thought, but couldn't confirm. Basically he's verifying a valid file and inferring it relates to a different file.
Sounds like a UX problem than a technical one. It's equivalent to me zipping up a folder, changing the contents of that folder, then expecting the zip file to have the change as well.
Funny you mention 'they'. I usually do that but noticed in one of my replies I used 'he'. Turns out I reciprocate what other's say without thinking about it.
I use pgp daily with my email. I value it. It's good software.
But let's be honest, SSL and pgp are the best we can do to secure comms from http to smtp today?
Key/cert management is an epic fail from a usability pov. Is it done? Yes, because there is NO other choice. But pgp will never ever be anything but a niche application for the paranoid.
SSL? I don't think anyone is going to argue it doesn't need to be scrapped and rewritten from scratch or replaced entirely.
Encryption must be transparent for it to be ubiquitous. We're not there yet. I know this is a hard problem to solve but someone eventually will.
GPG - without trying to devalue the good work put into it - is also one of the tools with one of the worst command line interfaces I know; by default it prints a confusing amount of wholly irrelevant, debug level information, to the point where it's hard to see where the actual output is (eg. --verify success). A slew of different key identificators (short ID, long ID, fpr, name, email, ...) that are all mixed in a bunch of places and only sometimes interchangeable etc. etc.
The UX is just horrendous, and none of the GUI tools improve on that.
PGP-People often talk about a "web of trust". Sometimes I wonder if any of them ever saw a web (like a spider web)? From the UX of popular PGP tools I can only assume no one did, because none of them can answer basic questions (and indeed, the data model doesn't support it, either), like "What's the relation of key XYZ [from an untrusted source, say keyserver] to my key?"
Here's a tip: If you generate an email from the content of the contact form anyway, why not make it an encrypted mail? It's rather easy if you use mailx from the heirloom-mailx package that is part of Debian, Ubuntu and probably a lot of other Linux/BSD/UNIX distributions. Here are the required steps:
In ~/.mailrc:
Then every mail sent to user@example.com using "mailx" will be encrypted using S/MIME.Got no local MTA installed? You can make mailx send the mail directly via SMTP:
$ echo mail body | mailx -s "subject" -S smtp=mail.example.com:25 -S smtp-use-starttls user@example.com