4 ms·

> Currently, we do not offer protections against man-in-the-middle attacks. As a result, if someone—a malicious insider or X itself as a result of a compulsory

> Currently, we do not offer protections against man-in-the-middle attacks. As a result, if someone—a malicious insider or X itself as a result of a compulsory legal process—were to compromise an encrypted conversation I assume this means that the "encryption" is about as strong as base64.

mort96 1y ago
I bet they're using WebSocket over HTTPS and calling that "encrypted chat" because it technically is.
- tonyhart7 1y ago
  hey, I literally doing this right now, what's wrong with that?? I mean its just for notification to my app so its not something critical
  - 8-prime 1y ago
    When the message you push out through that websocket are something that server knows about intrinsically, as in, the message contents are produced by the server there is nothing wrong with the approach. When your server facilitates a communication between two clients and just acts as the infrastructure E2EE can become relevant. If the clients want to be able to exchange information withouth the server being able to snoop in on what is being sent, then you'd want to use E2EE. With that the server won't be able to read what is being sent.
    - tonyhart7 1y ago
      - I have public chat that user can chatting in public room (seems like I dont need for this one) - then notification service is probably something I want to E2EE then, but Idk about performance hit cost would be
      - 0xFEE1DEAD 1y ago
        A public chat - like one that anyone can join at any time without needing an invitation? If so, then you really don't need any extra encryption. If not, then it depends on who's using your chat, how they use it, and for what purpose. Are the users of the chat room a small group with occasional users joining or leaving, or are many users expected to join and leave at any given moment? That being said, encrypting the notifications won't bring any real benefits. A bad actor would simply focus on trying to compromise your server. If you do decide that full e2ee would benefit your users, then look for someone who can help you implement it. Implementing real e2ee for a 2 party chat is hard for someone without experience. Implementing e2ee for a group chat is hard even for someone with experience.
        tonyhart7 1y ago
        welp, I am just gonna look at Telegram/Signal source and make a lite version for it
        mort96 1y ago
        I don't think you want to look at the source code, and I don't think you want to look at Telegram. You should have a look at the Signal Protocol: https://en.m.wikipedia.org/wiki/Signal_Protocol https://en.m.wikipedia.org/wiki/Signal_Protocol. It's well documented. Maybe there are libraries which implement it. (Though I still think that "how can I protect against TLS being broken?" is the wrong question and you should instead ask "how can I ensure that TLS doesn't break?".)
  - mort96 1y ago
    If your threat model is such that it's perfectly fine for the server to know everything that's coming from and going to the client, there's no problem at all. That's probably your situation, it's okay that the server knows what notifications it's sending to your app. If your threat model is such that you'd rather not have the server know what's sent to and from the client, it's not enough to just encrypt the data in flight, which is what HTTPS does. With encrypted chat, we typically want what we refer to as end-to-end encryption, where the server can't see the content of messages sent between users.
    - tonyhart7 1y ago
      then what happen if E2EE receiver is server itself??? I want to prevent vector attack such MiTM if TLS is somehow hacked
      - mort96 1y ago
        In a typical server-backed web app architecture, TLS is the protection against MITM. You're gonna have a really really hard time making something which protects against MITM better than TLS. There are things you can do to make it more difficult to hack your TLS connection though, for example you could use key pinning to make sure that your app will only accept a server with the certificate you expect. This would protect against an IT admin installing root certs on their users' devices, or against certificate authorities issuing fake certificates for your domain.
        tonyhart7 1y ago
        Yeah this app maybe don't need that but for things like IoT running websocket connection for long time maybe I need that
      - hiimkeks 1y ago
        Ah, the Zoom Gambit
        tonyhart7 1y ago
- deleted 1y ago
  [deleted]
Hamuko 1y ago
Well, in Musk's defense, he promised Bitcoin-style encryption and it does indeed appear to be as much encrypted as Bitcoin is.
- blitzar 1y ago
  Promises made, promises kept.
- qalmakka 1y ago
  well, in Musk's defence he's been selling BS to people for the better part of the last three decades and people are still giving him money, so...
  - briandear 1y ago
    Those rockets, the ones that went into space, are those BS? Starlink works. Tesla’s were the most desirable electric car until politics came into it. And PayPal? Literally changed the internet.
    - xorcist 1y ago
      I don't think that was intended as an argument that Starlink or Tesla doesn't exist but that there has been many not entirely truthful promises made when building the brands. Tesla exists, but some investors really believed it was to be taken private, or perhaps even that Full Self Driving would be capable of earning money while you sleep, or any other of a thousand more or less realistic promises that has been publicly made. I do wish that the Paypal statement would be a bit more nuanced though. Yes, Musk made a lot of money on the dot-com hype by way of Paypal. And he seems to have built strong friendships from that, weirdly with the same people that fired him. But his involvement in Paypal was that he let it buy the startup he was in and demanded to be CEO. He then only showed interest in throwing out the FreeBSD it was built on and replace it with NT (which was the hottest fad at the time) and to rename the company to "X". Neither happened, and he was quickly let go before the company risked bankruptcy. It's rather far fetched to go from that to "changing the Internet". Paypal won and X didn't.
    - 1y ago

mort96 1y ago

I bet they're using WebSocket over HTTPS and calling that "encrypted chat" because it technically is.

tonyhart7 1y ago
hey, I literally doing this right now, what's wrong with that?? I mean its just for notification to my app so its not something critical
- 8-prime 1y ago
  When the message you push out through that websocket are something that server knows about intrinsically, as in, the message contents are produced by the server there is nothing wrong with the approach. When your server facilitates a communication between two clients and just acts as the infrastructure E2EE can become relevant. If the clients want to be able to exchange information withouth the server being able to snoop in on what is being sent, then you'd want to use E2EE. With that the server won't be able to read what is being sent.
  - tonyhart7 1y ago
    - I have public chat that user can chatting in public room (seems like I dont need for this one) - then notification service is probably something I want to E2EE then, but Idk about performance hit cost would be
    - 0xFEE1DEAD 1y ago
      A public chat - like one that anyone can join at any time without needing an invitation? If so, then you really don't need any extra encryption. If not, then it depends on who's using your chat, how they use it, and for what purpose. Are the users of the chat room a small group with occasional users joining or leaving, or are many users expected to join and leave at any given moment? That being said, encrypting the notifications won't bring any real benefits. A bad actor would simply focus on trying to compromise your server. If you do decide that full e2ee would benefit your users, then look for someone who can help you implement it. Implementing real e2ee for a 2 party chat is hard for someone without experience. Implementing e2ee for a group chat is hard even for someone with experience.
      - tonyhart7 1y ago
        welp, I am just gonna look at Telegram/Signal source and make a lite version for it
        mort96 1y ago
        I don't think you want to look at the source code, and I don't think you want to look at Telegram. You should have a look at the Signal Protocol: https://en.m.wikipedia.org/wiki/Signal_Protocol https://en.m.wikipedia.org/wiki/Signal_Protocol. It's well documented. Maybe there are libraries which implement it. (Though I still think that "how can I protect against TLS being broken?" is the wrong question and you should instead ask "how can I ensure that TLS doesn't break?".)
- mort96 1y ago
  If your threat model is such that it's perfectly fine for the server to know everything that's coming from and going to the client, there's no problem at all. That's probably your situation, it's okay that the server knows what notifications it's sending to your app. If your threat model is such that you'd rather not have the server know what's sent to and from the client, it's not enough to just encrypt the data in flight, which is what HTTPS does. With encrypted chat, we typically want what we refer to as end-to-end encryption, where the server can't see the content of messages sent between users.
  - tonyhart7 1y ago
    then what happen if E2EE receiver is server itself??? I want to prevent vector attack such MiTM if TLS is somehow hacked
    - mort96 1y ago
      In a typical server-backed web app architecture, TLS is the protection against MITM. You're gonna have a really really hard time making something which protects against MITM better than TLS. There are things you can do to make it more difficult to hack your TLS connection though, for example you could use key pinning to make sure that your app will only accept a server with the certificate you expect. This would protect against an IT admin installing root certs on their users' devices, or against certificate authorities issuing fake certificates for your domain.
      - tonyhart7 1y ago
        Yeah this app maybe don't need that but for things like IoT running websocket connection for long time maybe I need that
    - hiimkeks 1y ago
      Ah, the Zoom Gambit
      - tonyhart7 1y ago
deleted 1y ago
[deleted]

Hamuko 1y ago

Well, in Musk's defense, he promised Bitcoin-style encryption and it does indeed appear to be as much encrypted as Bitcoin is.

blitzar 1y ago
Promises made, promises kept.
qalmakka 1y ago
well, in Musk's defence he's been selling BS to people for the better part of the last three decades and people are still giving him money, so...
- briandear 1y ago
  Those rockets, the ones that went into space, are those BS? Starlink works. Tesla’s were the most desirable electric car until politics came into it. And PayPal? Literally changed the internet.
  - xorcist 1y ago
    I don't think that was intended as an argument that Starlink or Tesla doesn't exist but that there has been many not entirely truthful promises made when building the brands. Tesla exists, but some investors really believed it was to be taken private, or perhaps even that Full Self Driving would be capable of earning money while you sleep, or any other of a thousand more or less realistic promises that has been publicly made. I do wish that the Paypal statement would be a bit more nuanced though. Yes, Musk made a lot of money on the dot-com hype by way of Paypal. And he seems to have built strong friendships from that, weirdly with the same people that fired him. But his involvement in Paypal was that he let it buy the startup he was in and demanded to be CEO. He then only showed interest in throwing out the FreeBSD it was built on and replace it with NT (which was the hottest fad at the time) and to rename the company to "X". Neither happened, and he was quickly let go before the company risked bankruptcy. It's rather far fetched to go from that to "changing the Internet". Paypal won and X didn't.
  - 1y ago