TLS everywhere

[slingamn]

IRC is commonly still used in plaintext over the public Internet. This is extremely bad --- in my opinion, one of the most severe and pressing issues facing the platform --- and we should be trying to change it. Some ideas:

1. Legacy clients (and servers) can use external TLS termination proxies, in particular stunnel which is cross-platform FOSS. How adequate is this as a solution? Should we write documentation/guides that cover this?
2. What are the prospects for lobbying existing networks to disable plaintext access?
3. Can standardizing the ircs:// URI format, as in #8, provide an effective way to communicate to clients that they should exclusively use TLS for connections?
4. What is the proper role of STS in this initiative? (Given the currently poor levels of client support, I'm relatively bearish on STS.)

[Herringway]

My thoughts on 3:

• irc:// and ircs:// both should be secure
• add an explicitly insecure URI format (ircu://?) for those that need it for some reason

Security ought to be opt-out, not opt-in.

[RyanSquared]

I can reword some things here and recommend that clients default to port 6697 and then have the option to fall back on port 6667 if it is not available. As of right now, it is recommended that the client informs the user that a secure connection is possible if it is not already the default.

[slingamn]

I don't want to let the perfect be the enemy of the good here, but "try 6697 and fall back to 6667" has the same properties as opportunistic encryption, in that it's vulnerable to MITM (attacker denies service on 6697 and waits for the fallback).

I'm after something more radical, where clients have to explicitly opt in to plaintext. I can understand if it's not realistic to deliver that, it's just what I'm hoping for.

Hopefully I'm not reopening any old wounds, but I agree with the first comment here: "The real solution for secure IRC usage must be TLS from the first byte." (Which I would read as "mandatory TLS".)

[Herringway]

Just want to put it on the record that even a fallback with big scary alarm bells would not work out - alarm fatigue is real and very easy to cause.

[Herringway]

Networks would likely want to be able to migrate from plaintext(+TLS) to TLS only. I could see such a migration going like this:

1. Ensure TLS port is stable (verified certificate, no expiry issues, etc)
2. Network enables STS.
3. Once supermajority (maybe >90%? >99%?) of users are using TLS, disable plaintext.

This migration could take quite a bit of time as clients gain support and users update to those clients, but it is doable.

[TingPing]

IRC is commonly still used in plaintext over the public Internet.

Do we have analytics over this from the big networks?

[slingamn]

This is an excellent question and something I'd like to see numbers on --- it would shed light on how far we are from being able to recommend that servers disable plaintext.

However, I misplaced the emphasis: I meant something like "IRC servers commonly make their services available in plaintext over the public Internet", which is bad because it implies that users (even those who have opted into TLS) cannot be certain that their user data will not be relayed in plaintext. This is an issue even if actual use of plaintext by clients is no longer common.

[RyanSquared]

I'm not sure of the exact statistics but I know many clients make TLS opt-in and disabled by default.The HexChat installed on my computer has a list of servers preconfigured, none of which have TLS enabled by default. WeeChat requires an extra flag -ssl and specifying the port when running /server add

[MetaNova]

I have a plain, fresh install of HexChat and I see many servers pre-configured to use TLS.

[RyanSquared]

none of which that I tested*, it looks like several servers do, several servers don't. Some of those servers now probably support TLS.

[slingamn]

dx made the following points:

1. The community had this discussion in the past and STS was the outcome; we should be cautious about reinventing an inferior wheel, and maybe the correct answer here is just "implement STS for real"
2. One case STS handles is people who aren't updating their client configs, but who are updating their client software (via distribution package managers or the like): for these users, STS silently and nondisruptively upgrades them to a secure (MITM-resistant) way of connecting

Personally I still want to move to more aggressive measures.

[RyanSquared]

The community had this discussion in the past and STS was the outcome; we should be cautious about reinventing an inferior wheel, and maybe the correct answer here is just "implement STS for real"

:+1:

One case STS handles is people who aren't updating their client configs, but who are updating their client software (via distribution package managers or the like): for these users, STS silently and nondisruptively upgrades them to a secure (MITM-resistant) way of connecting

:+1:

And, I do agree that we should move to more aggressive measures. What would be some good first steps? Something I've proposed in the past - but has always been shut down - is to try and determine whether or not a server supports IRC+TLS based on whether or not port 6697 is open and whether or not it has a valid certificate should be checked on connection. If the connection is able to be opened, but can't be verified - which was one of the issues - then this would at least expose that there is a problem with the connection.

[slingamn]

Standardizing (or at least recommending a value for) a TLS-only channel mode ("only users with TLS may join this channel") could help, in that it would make IRC increasingly difficult to use over plaintext, pushing clients to migrate.

[slingamn]

emerson reports that approximately 70% of freenode's userbase is using TLS, dropping to 60% if irccloud and Matrix are excluded from the count.

[DanielOaks]

Something that's been mentioned on the channel and around a few times, may be useful to keep in mind that TLS alone doesn't necessarily equal "secure", and we should be careful when using that word, particularly exposing it to end users. Especially with things like E2E encryption that we're messing with, we might want to use that word more carefully in the future. Shouldn't affect much until we get to actively writing specs with recommended language though.

[Alexendoo]

My thoughts: STS could do with a push, few networks offer it and fewer still offer a preload key (there's also no registry for clients to pull a preload list from). It should be a much easier sell than asking networks to outright disable their cleartext ports.

STS with preload is an effective way to get TLS from the first byte without causing breakage to users, but it would need a push for both networks and clients to support it.

To draw a parallel, the improvements in TLS adoption on the web has been in no small part due to constant outreach by browser vendors, other web developers and users.

[TingPing]

@RyanSquared Feel free to submit a patch to HexChat, the list was certainly up to date last time it was checked.

[slingamn]

State of modes as a solution to this problem:

1. Unreal sets +z on users who are connected via TLS; the user mode +Z prevents you from messaging or being messaged by users who are not using TLS; the channel mode +z prevents users who are not using TLS from joining the channel; the channel mode +Z indicates that all users currently in the channel are using TLS (and is automatically unset by the server if this changes?!)
2. Freenode sets +Z on users who are connected via TLS; the channel mode +S prevents users who are not using TLS from joining the channel
3. On Inspircd, the channel mode +z prevents users who are not using TLS from joining the channel
4. Oragono sets +Z on users connected via TLS

I'm mainly interested in setting conventions for:

1. A channel mode that prevents non-TLS users from joining
2. A user mode that prevents the user from exchanging messages with non-TLS users

since a user mode for users who are connected with TLS seems largely redundant with 671 RPL_WHOISSECURE.

Someone mentioned that ISUPPORT can be used in situations like this, i.e., to communicate to clients which mode to use?

[slingamn]

Since it's come up, I have no problem with treating Tor, or networks that are trusted at layer 3 (like VPNs or trusted LANs), as though they were TLS. The condition I'm trying to pick out is "does not send plaintext over the public Internet".

[SadieCat]

A channel mode that prevents non-TLS users from joining

A user mode that prevents the user from exchanging messages with non-TLS users

InspIRCd already does this with +z as a channel and user mode.

https://docs.inspircd.org/3/modules/sslmodes/

[KoraggKnightWolf]

UnrealIRCd has similar functionalities via the +z chanmode (same as on InspIRCd) and the umode is +Z (as +z is used as indicator for a secure connection instead). It even uses chanmode +Z to show "this channel only has TLS users" (auto set by the server when the criteria is met, cannot be (un)set by users or even opers). Most IRCd's seem to use chanmode +z or +S for "tlsonly users may join".

https://www.unrealircd.org/docs/Channel_Modes

https://www.unrealircd.org/docs/User_Modes

[DanielOaks]

I think the main thing on that side is just letting clients know that those modes exist? Which feels like either named modes proper or ISUPPORT tokens like TLSCHAN=z TLSUSER=z` or whatever?

[slingamn]

Initial proposal: new ISUPPORT token called TLSMODES, taking a value of the form x,y, where x is the channel mode expressing "only TLS-connected users may join this channel", and y is the user mode expressing "only TLS-connected users may send private messages to me, or receive them from me". So Unreal would send TLSMODES=z,Z, Inspircd would send TLSMODES=z,z, and Freenode would send TLSMODES=S,.

I considered something that would make you unable to speak on a channel that didn't have the TLS-only mode, but decided against it because (a) it's not currently implemented by any ircd (b) clients can implement themselves it by querying the channel mode.

[slingamn]

smoerk points out that although the TLS-only channel modes have the same semantics with respect to new joins, they have significantly different semantics with respect to current participants:

1. Unreal appears to preemptively kick everyone when the mode is set
2. Inspircd will not let you set the mode if there are currently non-TLS participants
3. Freenode notes explicitly that "users already in the channel are not affected"

This is probably a dealbreaker in terms of promoting a single isupport token that ratifies the existing behavior. But I'm not sure what the best way forward is. (For what it's worth, my personal preference is for preemptive kicking.)

[jwheare]

Fwiw, we are now publishing our STS preload list here:

https://www.irccloud.com/chat/sts-preload

[slingamn]

In order to prevent discussion of the TLSMODES isupport token from drowning out other important conversations around TLS adoption, I've spun it off to a separate ticket, #46.

[realJoshByrnes]

• irc:// and ircs:// both should be secure

@slingamn It's important to realise that IRC specifies the protocol, it's far better if a client drops protocol support, than sending users on a different protocol, that often won't work. eg. irc://irc.example.com:6667/#ircv3 Would the client try TLS on 6667? Would the client force 6697? This is a bad idea.

For servers; it would be far better to add a bot to message a non-TLS user to let them know their connection is insecure, how to enable TLS, and/or that limited services may be available due to their insecurity.

For clients; Default port 6697 and have a 'Allow insecure connection' checkbox, rather than defaulting 6667 and having a 'Secure' checkbox might be a good option. It might also be good to display a padlock on secure servers, and a red 'not secure' display on insecure ones (such as Google Chrome does).

I'm all for restricting channel entry/creation (perhaps even by default, such as with +nt channel modes)

IRC is a simple protocol, one of the concerns I have is that we lose people who want to play around with their first IRC bot, etc. (this is probably all of you at some stage) A quick Google for irc bot example shows me a result that won't work with TLS only servers.

With that said, I think if we're to disable non-TLS support completely, we should do just that; Stop listening on port 6667.

[slingamn]

@slingamn It's important to realise that IRC specifies the protocol, it's far better if a client drops protocol support, than sending users on a different protocol, that often won't work. eg. irc://irc.example.com:6667/#ircv3 Would the client try TLS on 6667? Would the client force 6697? This is a bad idea.

The suggestion was that irc:// should refer to IRC-over-TLS, and IRC-over-plaintext should get a separate protocol identifier like ircu://.

[realJoshByrnes]

The suggestion was that irc:// should refer to IRC-over-TLS

Which is what I'm saying, it would break every link that ever existed for IRC (with the exception of those that use the +port to specify SSL/TLS). It would be better to just drop support for irc:// links, rather than trying to re-define the protocol in the link.

[Herringway]

changing irc:// to TLS by default would allow most URLs to keep working in a post-plaintext world. That's better than zero URLs working.