search

element-hq / element-web

A glossy Matrix collaboration client for the web.
https://element.io
GNU Affero General Public License v3.0
11.23k stars 2k forks source link

Feature: E2E Encrypted Bot/Integrations API #4782

Closed ghost closed 2 years ago

ghost commented 7 years ago

This is something that has been implemented by Wire and it makes sense that an end-to-end encryption-focused platform like Riot would have this as well, especially considering that any chat room isn't truly end-to-end encrypted right now if any integrations are added.

turt2live commented 7 years ago

Related: https://github.com/vector-im/riot-web/issues/2277

t3chguy commented 7 years ago

If a bot is e2e capable and in an e2e room then surely the room is no longer e2e secure ss the bot will be decrypting everything out of your control

Nostradamos commented 7 years ago

If a bot is e2e capable and in an e2e room then surely the room is no longer e2e secure ss the bot will be decrypting everything out of your control

The bot is just another end, and to that end, the transportation is secure or at least as secure as it's to all other ends. For sure the bot maybe does shit with it, this is possible, but the same would be for any hacked/spying human member which is in a e2e group chat or something.

Not allowing bots to work with e2e chats is definetly the wrong road to go, because we force any bot communication to be on a less secure transport way. The better approach would be to have a room setting, forbidding bots to join (maybe with even advanced settings like a whitelist/blacklist). This would still let the oppertunity for clients which behave like a bot, but without e2e bots, this would be the only hack to make bots possible in an e2ee chat.

t3chguy commented 7 years ago

If the bot is ran by an untrusted 3rd party as is common then you surely wouldn't want it to have e2e As for bots supporting e2e I think a similar issue should be opened at go-neb ivar2 etc

Nostradamos commented 7 years ago

This is true as long as you don't trust the bot. If it's for example your own bot than it's something you could trust. Even if you have a gif search bot, it's maybe not bad to use the bot in an e2ee chat.

lampholder commented 7 years ago

I'm not sure I understand all of the issues in play here, but to my mind it seems that if we can train users to think of bots as just another participant (to be trusted/not trusted based on a human judgement call) then I see no reason why it wouldn't be advantageous for them to be able to support inclusion in E2E rooms.

uhoreg commented 7 years ago

There are a few possible options for making this happen, and I thought that there was already another issue opened, but I can't find it right now.

  1. allow the bot to decrypt everything (e.g. the hubot adapter can do this). This doesn't require any changes to Riot, but of course requires you to completely trust the bot.
  2. the bot can only read unencrypted messages, but allow the option to send unencrypted messages so that the bot can read messages intended for it. This could be done in some automatic way, such as when the bot is mentioned.
  3. the bot can do e2e encryption, but is blocked by default. Similarly to 2, it can be unblocked when messages intended for it are sent.

Other questions that would need to be answered, if the bot understands encryption, are related to key verification. First of all, if how do you verify the bot's keys? You can't "meet in person" to verify keys like you would with a normal person. One possibility would be to put the bot's keys in an HTTPS site, if you want to trust that. And secondly, how does the bot determine what keys it should trust? If it just trusts everybody, then an attacker would be able to read the bot's responses, which would give them an idea of what was being said in the room.

MTRNord commented 7 years ago

What about making it a feature which only is activated on self hosted bots? In that case you would be able to trust the bot as you run it and not some third party

Nostradamos commented 7 years ago

Other questions that would need to be answered, if the bot understands encryption, are > related to key verification. First of all, if how do you verify the bot's keys? You can't "meet > in person" to verify keys like you would with a normal person. One possibility would be to > put the bot's keys in an HTTPS site, if you want to trust that. And secondly, how does the > bot determine what keys it should trust? If it just trusts everybody, then an attacker would be able to read the bot's responses, which would give them an idea of what was being said in the room.

How about the bot asking the already trusted room members/admins if it can trust the member? The bot could send a message into the room with a message like "New untrusted user/device xyz. Add it to trusted user/devices with !addtrust xyz". An admin/user/whatever depending on permission settings could than add this user/device to the trusted ones.

Or maybe there is a way to automatically synchronize the trusted users/devices with an admin or something.

Not sure if these ideas weaken the general e2e security or are possible to implement.

uhoreg commented 7 years ago

Something like that might work once the bot has already trusted some devices. But it won't work when the bot has nothing to start with. When the bot joins the room initially, it just has a whole bunch of unknown devices. How does it know which devices to trust initially? And even if it somehow figures out which devices to trust, how does it actually verify the keys?

Nostradamos commented 7 years ago

It has to trust the user who invited the bot into the room, verifying the keys won't work without a homepage or something which let's you cross check again the key of the bot (which still is only more work to manipulate), so maybe there's no much better alternative as trusting the first user "blindly"?

uhoreg commented 7 years ago

It has to trust the user who invited the bot into the room

But which of that user's devices does it trust, and how does it verify that user's key?

so maybe there's no much better alternative as trusting the first user "blindly"?

Yeah, in the end, it will probably require some amount of blind trust. So I think some of the broad questions to answer is are:

  1. how to we make it clear to users how much blind trust is involved, and how much inviting a bot may compromise security?
  2. what level of paranoia can actually be supported when you invite a bot?
  3. can we allow users to make a choice how much they want to trade off security vs convenience?

Personally, in the case of bots hosted by a third party, I like the option of being able to send unencrypted messages to an encrypted room that bots can read, since this makes it clear that those messages are not secured at all, and that the replies from the bots are not secured.

The case of a bot hosted by a member of the room would be different. That member could presumably perform some manual setup so that the bot trusts that user's devices, and they could verify the bot's devices. Then perhaps using some sort of WoT-like thing via that user, other users could trust the bot and the bot can trust users.

gsantner commented 6 years ago

are there any updates on this? for me as developer this is one of the most missing parts on Matrix/Riot - unencrypted bot communication.

as said above, in wire this can be done, and in xmpp(omemo) too, with not much code even

ara4n commented 6 years ago

we're hoping to implement e2e for the golang sdk as part of work on https://github.com/matrix-org/matrix-search, at which point go-based bots can use it. Meanwhile, matrix-js-sdk has good e2e support already and there are bots written in node using it today (e.g. https://gitlab.com/argit/matrix-recorder)

gsantner commented 6 years ago

nice :D Is there in some JVM language support too?

ara4n commented 6 years ago

only if someone contributes it, it's not on the core team's roadmap atm.

IF-Adin commented 4 years ago

Could this be revived, please? It's been almost two years and to me, it seems extremely important that bridging bots have the ability to encrypt content. I can sadly not contribute any code, but i would be willing to put a bounty on this.

michaelsmoody commented 4 years ago

Could this be revived, please? It's been almost two years and to me, it seems extremely important that bridging bots have the ability to encrypt content. I can sadly not contribute any code, but i would be willing to put a bounty on this.

https://github.com/matrix-org/pantalaimon is basically a proxy that allows bots to work with E2EE. It's not exactly "run command, profit!", but it does bridge this gap.

IF-Adin commented 4 years ago

https://github.com/matrix-org/pantalaimon is basically a proxy that allows bots to work with E2EE. It's not exactly "run command, profit!", but it does bridge this gap.

Oh, awesome! Thank you!

michaelsmoody commented 4 years ago

You're welcome, and I hope it helps. I too am looking to use it for some bots.

ara4n commented 4 years ago

it works well for bots (eg we use it in production for mjolnir).

the question on whether bots should be smarter about what messages they subscribe to (rather than intercepting everything and so violating e2ee) remains however.

jonathanmmm commented 3 years ago

I was searching for that, how a bot has implications on e2ee. I am thinking, maybe only messages starting with ! are redable by bots and all other messages not, this would protect the e2ee messages. The only thing that someone has to remember is not to start a private message with ! (or the sign that matrix bots use to start a command)

turt2live commented 2 years ago

Closing in favour of spec issue: https://github.com/matrix-org/matrix-spec/issues/1109