Show HN: Get encrypted data from people that don’t know how to encrypt | Hacker News Reader

Show HN: Get encrypted data from people that don’t know how to encrypt

github.com

275 pointschomponthis93 comments

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.

Your don't need to trust the server. You can implement subresource integrity checks!

Subresource integrity still requires you to trust the server sending the hashes.

Ok so publish the hashes on a blockchain and have the client verify them there

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.

Make the whole page hosted on IPFS, and make your DNS point to it. Then you just need to trust the DNS. So use namecoin.

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?

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

Personally, I find the Whatsapp web version pretty convenient for long-form text

For text yes, but not so much for sending attachments like documents or other arbitrary files.

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.

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.

You can publicly provide the link to the box, e.g., on a Twitter account using keybase for authenticity.

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.

Edit: to fix typo

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.

Anyone got any good solutions to this?

Does a password-protected zip file work?

Password-protected ZIP shared on dropbox, with password communicated via phone or SMS?

I've resorted to this before, but there must be a better way!

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.

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.

This actually looks like it might be the least-worst solution, thanks!

This is the product page: https://www.microsoft.com/en-us/cloud-platform/azure-informa...

Same thing here. This + HawkPost would be interesting.

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.

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.

Interesting. The feature is buried at the bottom of this page: https://protonmail.com/security-details

Could be quite useful. The biggest problem is the recipient not having a compatible decompresser that can decrypt the archive.

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.

Added the suggestion to the discussion issue on github: https://github.com/whitesmith/hawkpost/issues/41

    >  or use the official server (that is running an exact copy of this repo)

Is there any project that attempts to prove claims like this?

I don't know what that would look like; it would probably just move the point of trust, just interested to see it if such a thing exists.

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 somewhat doable with Intel SGX. MSR had a paper on using rented servers to process data in a trust-free fashion.

What you are looking for is called "remote attestation".

(In open source software the solution to this problem is "well, you could always just host your own instance" ;))

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

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.

Like several others I made a similar tool years ago : https://transfer.pw/

It uses client side encryption, dyn. created keys, and the message is deleted after first retrieval.

A slightly different usecase than the OP, still using it for all my clients.

Similar project https://encrypt.to

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.

I built something like this in 2015 that didn't gain a ton of traction: https://privateforms.com

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.

Yeah, it's hard to find a market for this.

One unique proposition that Private Forms has is a form-builder so you can create custom forms rather than just contact forms.

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?

Your point is valid and the project should always run through HTTPS (with HSTS). All assets are served from the local server.

js crypto's trust problem isn't solved yet. One has to trust hawkpost.co to not serve compromised client side js.

Yes, you really need to host your own server and audit the code carefully.

Which moves the threat to state actors willing to substitute certs, and that's the point at which the web fails you totally anyway.

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?

What about SRI?

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

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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

Why not just store all the js locally too?

It's slower but also provides better privacy.

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.

At least with the Debian system it might be possible to get some information about the attackers.

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.

[0]: https://addons.mozilla.org/firefox/addon/hcs-checker/

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.

note: I also have been contributing to hawkpost.

The code is supposed to be self hosted, so if you give someone else this link it will be at https://yourdomain.com/...

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

Here's another very similar project:

https://github.com/Spark-Innovations/SC4

Live demo:

https://sc4.us/sc4/sc4tk.html

SC4 has been through a security audit.

Looks great, this is something that is missing from Keybase (specifically, the email sending part).

Hi, one of Hawkpost contributors here.

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.

http://tomw1808.github.io/rsa-message-sharing/#/

This is really smart, especially with something like protonmail.

Not sure if I understood it correctly, but in essence it lets your users enter some (secret) content which is then encrypted in the browser using PGP.

Except for the message signing and auto-emailing, I've implemented something similar:

Blogpost: https://0day.work/easy-pgp-composer-encrypting-pgp-messages-...

GitHub: https://github.com/gehaxelt/PHP-Easy-PGP-Composer

Demo: http://pgpcomposer.demo.0day.work/

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.

This is excellent and very helpful for my volunteer work.

I feel like you could knock out something similar to this using Vault, from hashicorp.

Vault is an awesome tool, but I'm not sure if it lets an "outsider" submit information in an easy way.

Some sort of integration with vault looks like a nice idea.

Python and PostGreSQL. Not exactly a tiny footprint for a tiny application.

C and flat files would've been a clearly better choice, I agree.

Whoa, Whoa... assembler and raw drive access only...

I'm curious, when is this level of security necessary for civilians?

Always. All the time. Every day.

Lest your unencrypted messages one day be used in a fishing expedition to facilitate oppression at the hands of the current political regime.

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

How is this different from e2e-encrypted webchat?

its store-and-forward?

on hawkpost the encrypted blob only goes through the sending queue and is never stored permanently on the machine.

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>"

I don't think I'm smart enough to infer what you're trying to say. Care to elaborate?

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.

This reminds me of Craig Wright's blog post where he "proved" he is Satoshi, albeit that one was deliberately misleading.

Off-topic, I think in addressing people with 'they' is more polite when the gender is ambiguous, despite the stats being in your favour.

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 think dvh is confused about detached signatures and signatures that contain their payload.

For detached signatures:

    gpg --verify message.sig message

For signed files:

    gpg --verify message.sig
    gpg --output message --decrypt message.sig

It's all documented¹.

Dvh: what are you getting at?

1: https://www.gnupg.org/gph/en/manual/x135.html

I'm just trying to point out that it is easy to make mistake by checking normal signature and detached signature.

I agree that it's confusing.

To get the expected result, the user would have to use either

$ gpg --clearsign

(makes it obvious that the message is part of the resulting message.txt.asc file) or

$ gpg --detachsign

(which creates a .txt.sig file) or

$ gpg -a --detachsign

(which creates a .txt.asc file).

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.

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?"

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.

Reply on news.ycombinator.com