Can true private messages be implemented?

feature
#11

Sign with what key? HTTPS assures that the JavaScript you get is the JavaScript the server sent, but this is about a malicious admin who modifies Discourse to send insecure JavaScript code. If you sign part of the script (which would then need to be distributed pre-packaged, in a “sort of” binary form) with an “official” key owned by the Discourse devs, the site admin could simply remove the signature check or deliver a different public key.

No, effective security that protects against admins must be done outside of the webapp, based on stable, audited code that can’t be modified remotely without the client’s permission – because you absolutely must remove trust in the site admin from the equation.

5 Likes
#12

I would just suggest to people to use WebOfTrust or something https://www.mywot.com to make sure things are as they should be.

1 Like
#13

Web of Trust is a website reputation and review service. (And that’s a straight quotation from their about page.) It has nothing to do with key trust or identity validation. It will not protect you in any way if a site’s admin goes rogue or has their account compromised.

#14

Yeah but its likely the only way you’re going to know if someone is compromising the security of the deployment. Theres really no other way to do this and its likely way beyond the scope of what the developers of Discourse will be doing. If you’re going to shady websites than its your fault if they’re stealing your passwords.

#15

I don’t think we’re talking about the same topic. ¯\_(ツ)_/¯

This is about designing a crypto protocol that allows users of a Discourse site to exchange private messages in a way that will prevent the site’s admin staff from revealing the private message contents. We should assume that the site looks and behaves benign in any way other than that an attacker with a legitimate user account, admin privileges, root-access to the server, motivation and good technological knowledge is trying to read users’ private messages.

Now, how exactly is WoT going to help defeat or reveal this specific attacker? :smiley:

1 Like
#16

What I was referring to.

The problem

#####Bob Alice and Chuck
Alice is the host of a deployed copy of the web app.
Bob is the developer of the web app.
Chuck is the visitor/end user of the web app.

Bob is not going to be able to deploy code securely to Alice’s servers. For example if Bob is giving Alice a deployable copy of his web-app (Discourse), that Bob has gone to great lengths to secure against tampering, listening(MITM) or other exploits. If Alice as the admin of your site tampers with Bob’s code theres no way that the Chuck can trust the code.

##Codesigning
Unless Bob can guarantee that the web-app is unmodified from the Bob to Alice’s specific deployment than you’re never going to have this guarantee. If you code signed said crypto stack in some specific way then maybe you could potentially trust it. Realistically you can’t trust crypto that you don’t control which from what I understand is the goal here. What you can do is hope that there are people reviewing websites which you visit for exploits and MITM problems. This is where my suggestion for WOT comes into play because its a third party review site where if you can’t trust a site you report it. Its about as best as you can get. Otherwise I’d be afraid that this would be just a rabbit hole of dependencies and complex problems that this project isn’t intended for.

##Currently available solutions/tools
There are many tools for verifying the authenticity and integrity of a session like Perspectives Calomel SSL Validation Https Everywhere and even something as simple as LastPass which isn’t technically TNO. Basically the words Secure and Hosted are essentially incompatible. The only remaining issue is that basically we don’t want to have to install a bunch of dependency plugins in browsers because the normal users won’t be doing this for only one site.

#17

Yes, which is exactly why, from the start, Sam was requiring signed binaries and I was playing with the idea of having a companion plugin provided by the Discourse devs that contains the sensitive code and UI.

Edit: I should amend this; I did (and still do) consider an imperfect implementation that relies on unmodified code. At the very least, such a feature would protect against wholesale theft of private data.

#18

it could be first implemented in js correctly, and later repackaged, but all the patterns need to be correct from day 1. So you would not send unencrypted passwords to the server, for example.

#19

Keep in mind that many teams of very capable security researchers have worked on this problem, and continue to work on it. It’s not in any way unique to Discourse, although Discourse might add some unusual twists. The general problem of providing end-to-end encrypted communication between two parties without any ability for a party in the middle to access the content (or even metadata about the content, which can also be revealing; witness recent revelations in the Snowden documents), while simultaneously making this tool easy to use and frictionless as possible is a very, very hard problem.

3 Likes
#20

Very true. I think this falls outside of the scope of Discourse. IMO user-to-user messages are just a side-feature of Discourse.

With one of the prior discussions about “private” messages, I added to the forum guidelines of The Seasteading Institute:

Be aware that the forum admins can view all site content, including user-to-user messages.

and posted an administrative announcement notifying the users of the updated guidelines and why.

5 Likes
#21

Its actually a pretty well-solved problem PGP has been with us for quite a while, the issue around private conversation is that its just too technically challenging to participate in it cause the toolchains and software to facilitate it are terrible.

#22

What if we did have asymmetric keys. They have passwords on them why not have a system where the private key is SSL’d over to your browser from the server where you decrypt the Private key client side. Which then allows you to decrypt 1v1 conversations. But if you want to exit the realm of a 1v1 conversation it then is stated clearly as viewable by the mods/admins?

The password then becomes the weak link so if someone did obtain the PGP private key from the server and your password from you then you have a problem. From what I understand solutions like hush mail and other things like that have had something like this for ages.

#23

Wouldn’t it just be easier to Message a member with
“Can I email you about something private?”

1 Like
#24

Putting myself in danger of sounding like a smug ass, I’ll quote a few relevant tidbits. Hopefully this doesn’t come off poorly.

I mean as it stands its not really within the scope of what I imagine this project is about. Its not intended to be a safe haven forum software but it would be really nice to have.

#25

My point is if the concern is that Admins aren’t trusted, take care with what is posted.

If you want 100% privacy, well, welcome to the 21st century. Unless you keep it in your head it’s “out there”

1 Like
#26

I see “private conversation” as a completely different feature, it can be done, it is done daily by many people, but there are very few pieces of software out there that allow you to engage in private conversation without jumping through enormous amounts of hoops.

4 Likes
#27

You are correct, GnuPG and other PGP-based systems can be used to accomplish much of what is requested here. However, you reiterated the point that I made: these tools are far from easy to use, and most importantly, there is nothing hosted. Making a hosted system that provides enough ease of use for your Aunt Martha to be able to use it, but still provides the desired level of security, is the real challenge.

3 Likes
#28

I haven’t read everything here, but if it is an external plugin, you could leverage something like this:
https://www.tbray.org/ongoing/When/201x/2014/03/19/Keybase

Keybase solves the issue of verifying keys, so maybe the plugin could hook into keybase and only users that have hooked up their profile from keybase could verify each other.

4 Likes
#29

Closing this as yes this is both possible and done!

7 Likes
#30