3 ms·
At one company where I worked, we ran our own IRC (+SSL) server, and it worked great. Depending on your exact requirements and use cases, that may or may not q
by ken 9y ago
At one company where I worked, we ran our own IRC (+SSL) server, and it worked great. Depending on your exact requirements and use cases, that may or may not qualify as "p2p encrypted".
- walrus01 9y agoSeconding this. You can lock down an irc server pretty thoroughly if it is for company internal use only. First, put it in private IP space that is only accessible from a VPN connection (properly setup openvpn for instance). Have unique vpn public/private keys per device so you can revoke access to a stolen laptop or phone granularly. The ircd server host OS should have no public facing IP. Also configure the ircd to only listen for sessions from a certain range of IP space. Once people are on the vpn, have them ssh into a shell bastion system and run irssi + screen (or tmux) from there, connect to the ircd.
- giggles_giggles 9y agoThis doesn't protect users from snooping by the IRCD admin, which is what e2e encryption/p2p chat is about -- removing the ability of the service provider to see the content of the private messages between users. IMO IRCD in no way qualifies as "encrypted p2p chat".
- Tharkun 9y agoPlenty of OTR-like plugins for your IRC client of choice. IMO IRC is still the best chat experience.
- walrus01 9y agoI was describing more of a multi person chat (not p2p) for company internal use , such as an irc channel with ten or fifteen people. Much harder to do proper forward-secure crypto for one-to-many messages. If you run and control your own ircd the risks of snooping by the ircd admin are about the same as if you unknowingly have a rootkit/advanced peristent threat installed on your end point client workstation.
- ken 9y agoThat's why I said it may or may not qualify. What's the threat model? What's the usage environment? (It's "encrypted p2p" between two users if one of the users is also the admin.) For example, if the purpose of this requirement is to keep a business team's communications out of the hands of other businesses, then local IRC+SSL accomplishes that, even though the local administrator can still snoop on it. Being able to say that company secrets never left the company was a big hit with our investors, and it didn't matter that it was technically possible for our sysadmin to snoop on them because he had physical access to all our workstations anyway. If you don't have a trusted administrator, all is not lost. Each user can run their own ircd on the same VPN. It's less convenient to set up but any IRC client can handle multiple servers. Again, it depends on your requirements. (Are there 5 users, or 5000?) Like any other technology, IRC can be used as part of a secure system. It has the advantage that it's free and easy to run yourself. Without knowing more context, though, it may or may not be practical.
- gruez 9y agosounds unnecessarily complicated when you can just use public ip + TLS client certificates or SASL