Skip to content

Instantly share code, notes, and snippets.

@RyanSquared
Last active September 4, 2016 20:56
Show Gist options
  • Save RyanSquared/8cb0e1e6a457a939d414 to your computer and use it in GitHub Desktop.
Save RyanSquared/8cb0e1e6a457a939d414 to your computer and use it in GitHub Desktop.
Possible changes for IRCv3.3
title layout copyrights
IRCv3.3 TLS Enforcement
spec
name period email
Charles Heywood
2016
charles@hashbang.sh

Description

Because TLS is commonly available, servers should attempt to persuade users to use TLS rather than plaintexdt. This can be implemented by adding channel modes which could only allow users to join a channel if they are connected via TLS by default. Servers should also advertise what ports they use for TLS.

Clients should also implement features and notifications to attempt automatically connecting to the server via TLS.

Details

Clients

Clients, in a configuration created after the implementation of this specification, MUST automatically attempt connecting to port 6697 using TLS if there is no port specified. Clients MUST NOT require users to enter a port manually, to allow for using 6697 if one is not specified, but instead allow for a blank or default option to be used. Clients SHOULD notify user if an automated connection fails, and SHOULD prompt users to either continue with a non-secure connection - and the program MUST mention that it is non-secure - or to stop attempting connections to the server. Clients MUST NOT automatically downgrade to plaintext without displaying via some method, whether it be via a server log, that the attempt failed.

When connected to a server, the client SHOULD also notify the user, whether by icon or some other format (such as the lock on Chrome for https-enabled sites) that the user is connected securely to an IRC server.

If a client already has an existing configuration, then the configuration SHOULD NOT attempt automatically using a TLS connection and SHOULD prompt the user to manually add in the option.

Bots SHOULD notify if a connection with TLS is unavailable but SHOULD NOT require verification in order to continue connection, and, if notifying that a connection is not available, MUST notify that the connection will be tried using the port 6667.

Client interaction with non-TLS connections

Clients MUST, when unable to connect securely to a server, display that a secure connection could not be established. Clients MUST NOT automatically connect to the server using a plain connection, unless prompted at least once for the specific server's address. Clients SHOULD prompt users, after a TLS connection is unavailable, to connect using a plain connection.

Automated plain connections

Clients SHOULD prompt users to automatically use a plain connection and store the address of the server when connecting. Clients SHOULD NOT connect to the address using a plain connection without the user specifying to always use this form of connection. Clients SHOULD continue to check for a TLS connection, and if one is found, notify the user, upgrade the connection, and FORGET ALL automated plain-connection configuration for the server.

If a TLS 005 message is received from the server describing available TLS ports, the client MUST attempt connection to the IRC server on these ports. Once a connection is established, the client MUST drop the previous connection if it hasn't already and use the new port instead. If the client's configuration does not call for a port when connecting, the port can then be configured to use the port with TLS.

If the connection is unavailable, the client SHOULD notify the user as indicated above.

===

Servers

Servers are defined as any piece of software that can be deployed on a hardware server and run, such as UnrealIRCd, Charybdis, or InspIRCd.

Servers MUST have the ability to enable TLS support and SHOULD encourage server operators to enable TLS for both clients and leaf servers. Servers MUST notify clients who are connecting from a non-TLS connection that they are doing so, and MUST provide a port to connect to when doing so.

When connecting multiple servers, a secure connection MUST be used between the two servers if TLS is enabled on either of the two servers.

Servers SHOULD add limitations for users who join on an unsecure connection if TLS is available. For example, servers could implement a channel mode, settable by either channel operators or server/network operators, which only after this mode is set to allow users not connected securely to join this channel.

Adding certificate chain and private key files

Servers SHOULD make it as easy as possible to add the required files for TLS, preferably in a dedicated folder. Servers SHOULD also provide information explaining how to enable TLS.

RPL_ISUPPORT broadcasting ports

RPL_ISUPPORT should include a comma (,) separated list of ports with the key name TLS, which values are valid ports that users can connect to the server on using a secure connection. This MUST be included, and servers SHOULD send a NOTICE message to be displayed by the client.

:irc.example.com 005 Alissa TLS=6697,16697 :are supported by this server
@RyanSquared
Copy link
Author

@zadr has recommended omitting notifications when connections fail. I personally believe that it should be an option that can be turned on. @KellerFuchs, do you have an opinion? Either way, notifying users that a secure connection isn't available should not be the default until it is a guarantee that every deployed IRC server supports TLS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment