4 ms·

It's also worth noting that many clients now have LibOTR (Off The Record - end-to-end encryption) plugins available. For group chat, the best option seems to b

by davb 11y ago

It's also worth noting that many clients now have LibOTR (Off The Record - end-to-end encryption) plugins available. For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc).

notalaser 11y ago
> For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc). Exactly, at the end of the day you're still depending on people not to leak these things anyway.
- laumars 11y ago
  This is the thing that's gets me about encryption on public communication platforms. On the one hand, I do want my authentication to be secured, but as much as we might discuss securing chat, it's all posted in the public anyway. It's like standing on a street corner and shouting your personal details and hoping that's every stranger adheres to the implied NDA. At the end of the day, as long as your authentication is secured, then that keeps your password safe. The fact that your communication to the server is also secured is a bonus as it means that any eavesdroppers can't tell which user your are not even which channels you hang out on. But anything more than that is just pointless given you can't trust all clients to be secure. I'm not entirely sure this is a problem that can be solved in any way either. If the text can be read, then it can be ripped and logged. Much like the Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not exactly the same, but definitely some overlap)
  - lawl 11y ago
    I don't buy that argument. It's like saying we don't need TLS because in the end we still need to trust the server to not publish our password.
    - notalaser 11y ago
      That argument is made in the context of IRC networks, where the same server can have clients over both encrypted and unencrypted connections. If your own connection is encrypted, an eavesdropper listening at your router's exit can't see what you're typing. However, clients over unencrypted connections will get your message -- unencrypted! -- so an eavesdropper can just as well listen there, and he'll get your messages. He won't get your password, but will get your data. The argument holds for every similar system. E.g. TLS connections to a SMTP server mean that an eavesdropper won't see what you're asking the SMTP server to send, but if that server then relays your message over an unencrypted connection, all that TLS mumbo-jumbo won't help a bit, because the server just published your data in plain sight. Your password is safe, sure, but your data is in plain view, so if someone wants to spy on you, they don't even need your password anymore. So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.
      - lawl 11y ago
        Some ircd's implement channel mode +z which only lets SSL clients join. > So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections. Yes I'm saying that if you have confidential conversations you need to trust everyone to not publish the logs (and use SSL/set +z). No matter how good the crypto is. It's a case for having end to end crypto in IRC if anything.
        laumars 11y ago
        That's the problem though, you simply cannot trust other clients. If you need end-to-end encryption then you need secure clients as well, otherwise an attacker could: 1) just hack the PC and read the logs straight from the file system / messages from RAM 2) impersonate a trusted user (since clients don't send fingerprints beyond the basic ident information) 3) and there's no guarantee that even if the client is connected to the server via SSL (eg set +z on the channel) or end-to-end encryption is builtin, that the "client" still isn't anything more than an IRC bounce (eg ZNC) that users primarily connect to via clear text. So while I'm all in favour of encrypting IRC comms, the other links in the chain are so weak that pragmatically end-to-end encryption wouldn't offer you any significant privacy guarantees. So as much as I do love IRC, I honestly don't think it makes practical sense trying to leverage it as a secure platform for confidential conversations. There's better mediums for that; just as IRC excels in other areas where many other communication platforms fall short (eg openness, protocol simplicity, automation via IRC bots, etc).
  - HerraBRE 11y ago
    Encryption isn't just about keeping secrets. When correctly deployed it also prevents tampering; when your comms are insecure, it's quite easy for a MITM to inject or remove content. This is not hypothetical, although most of the large-scale attacks of this nature have focused on the web. What sort of havoc can someone cause in your organization by injecting fake chat messages? :-)
    - laumars 11y ago
      Indeed. However my point wasn't that we shouldn't have TLS connection to the server, but rather than end-to-end encryption (ie client to client) doesn't make a whole lot of sense on public channels since the comms are public.

by davb 11y ago

notalaser 11y ago

> For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc). Exactly, at the end of the day you're still depending on people not to leak these things anyway.

laumars 11y ago
This is the thing that's gets me about encryption on public communication platforms. On the one hand, I do want my authentication to be secured, but as much as we might discuss securing chat, it's all posted in the public anyway. It's like standing on a street corner and shouting your personal details and hoping that's every stranger adheres to the implied NDA. At the end of the day, as long as your authentication is secured, then that keeps your password safe. The fact that your communication to the server is also secured is a bonus as it means that any eavesdroppers can't tell which user your are not even which channels you hang out on. But anything more than that is just pointless given you can't trust all clients to be secure. I'm not entirely sure this is a problem that can be solved in any way either. If the text can be read, then it can be ripped and logged. Much like the Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not exactly the same, but definitely some overlap)
- lawl 11y ago
  I don't buy that argument. It's like saying we don't need TLS because in the end we still need to trust the server to not publish our password.
  - notalaser 11y ago
    That argument is made in the context of IRC networks, where the same server can have clients over both encrypted and unencrypted connections. If your own connection is encrypted, an eavesdropper listening at your router's exit can't see what you're typing. However, clients over unencrypted connections will get your message -- unencrypted! -- so an eavesdropper can just as well listen there, and he'll get your messages. He won't get your password, but will get your data. The argument holds for every similar system. E.g. TLS connections to a SMTP server mean that an eavesdropper won't see what you're asking the SMTP server to send, but if that server then relays your message over an unencrypted connection, all that TLS mumbo-jumbo won't help a bit, because the server just published your data in plain sight. Your password is safe, sure, but your data is in plain view, so if someone wants to spy on you, they don't even need your password anymore. So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.
    - lawl 11y ago
      Some ircd's implement channel mode +z which only lets SSL clients join. > So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections. Yes I'm saying that if you have confidential conversations you need to trust everyone to not publish the logs (and use SSL/set +z). No matter how good the crypto is. It's a case for having end to end crypto in IRC if anything.
      - laumars 11y ago
        That's the problem though, you simply cannot trust other clients. If you need end-to-end encryption then you need secure clients as well, otherwise an attacker could: 1) just hack the PC and read the logs straight from the file system / messages from RAM 2) impersonate a trusted user (since clients don't send fingerprints beyond the basic ident information) 3) and there's no guarantee that even if the client is connected to the server via SSL (eg set +z on the channel) or end-to-end encryption is builtin, that the "client" still isn't anything more than an IRC bounce (eg ZNC) that users primarily connect to via clear text. So while I'm all in favour of encrypting IRC comms, the other links in the chain are so weak that pragmatically end-to-end encryption wouldn't offer you any significant privacy guarantees. So as much as I do love IRC, I honestly don't think it makes practical sense trying to leverage it as a secure platform for confidential conversations. There's better mediums for that; just as IRC excels in other areas where many other communication platforms fall short (eg openness, protocol simplicity, automation via IRC bots, etc).
- HerraBRE 11y ago
  Encryption isn't just about keeping secrets. When correctly deployed it also prevents tampering; when your comms are insecure, it's quite easy for a MITM to inject or remove content. This is not hypothetical, although most of the large-scale attacks of this nature have focused on the web. What sort of havoc can someone cause in your organization by injecting fake chat messages? :-)
  - laumars 11y ago
    Indeed. However my point wasn't that we shouldn't have TLS connection to the server, but rather than end-to-end encryption (ie client to client) doesn't make a whole lot of sense on public channels since the comms are public.