View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005100 | unreal | ircd | public | 2018-06-03 17:57 | 2018-06-13 08:01 |
| Reporter | HeXiLeD | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Platform | Any | OS | Linux | OS Version | Any |
| Product Version | 4.0.17 | ||||
| Summary | 0005100: Forcing the use of encrypted communication | ||||
| Description | For a long time I have been looking for a way to force communications to be encrypted be default, between users and if possible, the server too. Although we can by default only allow TLS connectivity, this is not what I am looking for. I am looking for is a method which may be achieved by a special module or may actually require some heavy code re-writing which I understand may not be feasible at the moment. The point is that no regular text will be NOT able to be sent to a user and perhaps even the server if it is not encrypted with OTR and or (alternatively) by other methods like blowfish or xsalsa20. Ideally only OTR is what is/should be needed. I also understand that it may be easier or more practicable to just focus the feature towards OTR. The goal is for example, when a user1 opens a query to user2 and inputs text, the server will detect the text as "readable" & "not encrypted" text and will refuse to pass it to the the second user in a similar fashion as mode +Z does and outputting an error message notifying the first user that non OTR messages are not allowed in server. The purpose, is to force the users on both sides to have their irc client ready with OTR and therefore by default to ensure full privacy for the conversation. This method as explained may seem complex to implement and therefore a possible alternative is to force the initial connection to the IRCD to use OTR during the messages exchange between the client and the server in a way that any other private message will be subjected to the same. A good example of what I am trying to explain can be seen with some jabber servers such as calyxinstitute.org A good client to test this is conversations which allows the use of OTR, Omemo and pgp as private chat encryption method. IRC lacks this type of feature to bring it to the next level. | ||||
| Steps To Reproduce | https://www.calyxinstitute.org/sites/all/images/howto/2014-03-29_fig3-tor-tls-otr-encryption.png | ||||
| Additional Information | https://www.calyxinstitute.org/projects/public_jabber_xmpp_server | ||||
| Tags | fish, omemo, otr, privacy, security, UMODE, user mode, xsalsa | ||||
| 3rd party modules | |||||
|
|
So... you want to use OTR. OTR is used if you don't fully trust the server. If that is your mindset, then you shouldn't trust the server to make any right decisions for you with regards to whether something is OTR or not IMO. So.. any such validation should then be done by the client. No? Of course, a module could be made that adds a user mode similar to +Z, to block traffic matching a pattern (or traffic not matching a pattern). Just saying, you shouldn't rely on it for security if you don't trust the server. And you don't trust the server, otherwise you wouldn't be using OTR. |
|
|
Well, it is not exactly that the user does not trust the server but that is also a valid point. Another reason is a user not trusting an admin who can simply trying to spy on users either by using spy modules or other methods. Other reasons include MITM which I am aware of certain cases that have happened and am sure many others happen even when one fully trusts the server. Relying on the client to 'validate' and activate features like OTR is relying on human nature to enhance security voluntarily and that we all know it does not happen, plus it should be up the the admins to have services secure by default for the users without having the users having to bother with it and or wonder about the burdens of security implementation. Other reasons include the prevention of sending clear text messages since the server will only let OTR'ed messages to reach the receptor. Also many people still want and connect to 6667 (no ssl) and therefore OTR should be a must by default. As for SSL'ed servers not self hosted, anyone with access to the hosting service and or box, will have access to the encryption keys and therefore, encryption becomes useless. Another reason is that such feature will also make it difficult for all sorts of bot spam that we are aware that happen on irc networks. (at least for a long while) And perhaps the main reason of it all (for example, in my case) is to protect the server admins from the users. Most admins want to know what is going on the network. Who connects, who is, who was, the ip and so on and so on. This puts the admin under some legal pressure and responsibility, depending on legal jurisdictions and whatever happens on that server done by the users. However, if the users are fully end to end encrypted with functionalities such as OTR, omemo, pgp or equivalent, the admin is not liable for what the users talk about or do, because, the admin has no way to know whats going on even if forced by law to log all activity and or to hand over access to the servers by law enforcement. So let me give you the scope of the idea. Users connect to the server through an hidden service and can only chat with others using OTR which ensures plausible deniability and perfect secrecy. The admin has no control of any user communication and cannot be responsible for what he does not know or has possibility of knowing. Lets not forget also that the encryption provided by the server has limitations when compared to OTR which ensures plausible deniability and perfect secrecy among other details. This is a good enhancement to security :) |
|
|
My point is: If you don't trust anything from outside, such as the server (connection), then you shouldn't trust the server (connection) to make decisions for you :) It's not good protection for users. But, like you said, it could protect admins somewhat in the scenario you painted. |
|
|
I think this is more something for a 3rd party module. It's easy to hook into the message routines. I see you posted in the 3rd party modules forum, good :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-06-03 17:57 | HeXiLeD | New Issue | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: privacy | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: security | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: UMODE | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: fish | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: omemo | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: otr | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: user mode | |
| 2018-06-03 17:57 | HeXiLeD | Tag Attached: xsalsa | |
| 2018-06-06 08:48 | syzop | Note Added: 0020136 | |
| 2018-06-06 22:31 | HeXiLeD | Note Added: 0020137 | |
| 2018-06-11 09:01 | syzop | Note Added: 0020144 | |
| 2018-06-13 08:01 | syzop | Assigned To | => syzop |
| 2018-06-13 08:01 | syzop | Status | new => closed |
| 2018-06-13 08:01 | syzop | Resolution | open => no change required |
| 2018-06-13 08:01 | syzop | Note Added: 0020145 |
