4 ms·

How does E2EE work here? How can the user know their communication isn't being intercepted?

by tcfhgj 4y ago

Arathorn 4y ago
It’s using normal Matrix olm/megolm double ratchet encryption. To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.
- remram 4y ago
  How does the user check that, if they are running untrusted clients embedded on untrusted sites? Who is the adversary that the addition of end-to-end encryption is supposed to defeat?
  - woojoo666 4y ago
    If the business doesn't want to host the chat server themselves, they can have a 3rd party provider host it (like Matrix.org) without worrying about the 3rd party having access to the messages Edit: sorry I should have clarified that I was answering your second question. As for the first question, the user still has to trust the business to a certain extent
    - lawl 4y ago
      But they host the software, you already have to trust them. This threat model just does not make sense.
      - tcfhgj 4y ago
        The software = chat box? Could be hosted by yourself, too
      - woojoo666 4y ago
        The user has to trust the business no matter what. Even if the chat was e2e encrypted, the business could just choose to share the messages with somebody else. This use case is more for the business, who knows that the chat is hosted by a 3rd party, but is reassured that the 3rd party wont have access to messages.
        eis 4y ago
        The point is that the host can modify the code at will and can therefore access the messages if they wanted to. It defeats the idea of e2ee which is to make it impossible for a middleman to access the messages. With e2ee you have to trust the client. But a client that is running as a website hosted by someone else can't be trusted as the host can modify it and you'd never known because browsers don't have a way to alert you when a site changed. The only way this makes sense is if you (or your business) self-hosts.
        woojoo666 4y ago
        Another option is for the business to host the (open source) chatbox themselves, but the messages are stores and routed through a 3rd party. The chatbox is probably just a plug and play component that can be embedded in any page, and hosted statically by the business. Much easier than self hosting the entire messaging infrastructure. This is one of the major benefits of having an open protocol like Matrix. The clients are separate from the servers. People with more resources and more expertise can host the servers, while regular users just need to download an open source client, and they can rest assured that the messages are secure.
      - memorythought 4y ago
        There are other considerations though aren't there? Assuming that you trust the hosting entity: * You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host * You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy
jimmygrapes 4y ago
This is my question, too. From TFA: >there’s no need for them to register or create an account just because it’s E2EE, and it still supports persistent messaging. How does that work? Arathorn in a sibling comment says that there's out of band something, which I interpret to mean some verification process, but for the life of me I can't imagine what that process might be or how it might work without any sort of account... unless the client generates a unique a key per user session and coordinates the key exchange with a single host server behind the scenes to encrypt that session's data? What am I missing?
hda2 4y ago
Normal users will probably just check that the green padlock in their address bar. I think this is targeted towards securing chat traffic from thrid-party hosting services accidentally leaking or passively spying on you. Think problems that arise from early HTTPS termination like the cloudflair's https leak.

How does E2EE work here? How can the user know their communication isn't being intercepted?

by tcfhgj 4y ago

How does E2EE work here? How can the user know their communication isn't being intercepted?

It’s using normal Matrix olm/megolm double ratchet encryption. To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.

remram 4y ago
How does the user check that, if they are running untrusted clients embedded on untrusted sites? Who is the adversary that the addition of end-to-end encryption is supposed to defeat?
- woojoo666 4y ago
  If the business doesn't want to host the chat server themselves, they can have a 3rd party provider host it (like Matrix.org) without worrying about the 3rd party having access to the messages Edit: sorry I should have clarified that I was answering your second question. As for the first question, the user still has to trust the business to a certain extent
  - lawl 4y ago
    But they host the software, you already have to trust them. This threat model just does not make sense.
    - tcfhgj 4y ago
      The software = chat box? Could be hosted by yourself, too
    - woojoo666 4y ago
      The user has to trust the business no matter what. Even if the chat was e2e encrypted, the business could just choose to share the messages with somebody else. This use case is more for the business, who knows that the chat is hosted by a 3rd party, but is reassured that the 3rd party wont have access to messages.
      - eis 4y ago
        The point is that the host can modify the code at will and can therefore access the messages if they wanted to. It defeats the idea of e2ee which is to make it impossible for a middleman to access the messages. With e2ee you have to trust the client. But a client that is running as a website hosted by someone else can't be trusted as the host can modify it and you'd never known because browsers don't have a way to alert you when a site changed. The only way this makes sense is if you (or your business) self-hosts.
        woojoo666 4y ago
        Another option is for the business to host the (open source) chatbox themselves, but the messages are stores and routed through a 3rd party. The chatbox is probably just a plug and play component that can be embedded in any page, and hosted statically by the business. Much easier than self hosting the entire messaging infrastructure. This is one of the major benefits of having an open protocol like Matrix. The clients are separate from the servers. People with more resources and more expertise can host the servers, while regular users just need to download an open source client, and they can rest assured that the messages are secure.
    - memorythought 4y ago
      There are other considerations though aren't there? Assuming that you trust the hosting entity: * You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host * You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy

jimmygrapes 4y ago

This is my question, too. From TFA: >there’s no need for them to register or create an account just because it’s E2EE, and it still supports persistent messaging. How does that work? Arathorn in a sibling comment says that there's out of band something, which I interpret to mean some verification process, but for the life of me I can't imagine what that process might be or how it might work without any sort of account... unless the client generates a unique a key per user session and coordinates the key exchange with a single host server behind the scenes to encrypt that session's data? What am I missing?

hda2 4y ago

Normal users will probably just check that the green padlock in their address bar. I think this is targeted towards securing chat traffic from thrid-party hosting services accidentally leaking or passively spying on you. Think problems that arise from early HTTPS termination like the cloudflair's https leak.