Strict Transport Security

Strict Transport Security (STS) on IRC can be used to redirect plaintext users to SSL/TLS automatically.

Specification
"Strict Transport Security" is an IRCv3 specification. When used, it will:
 * 1) redirect users with capable clients to the appropriate SSL/TLS port automatically
 * 2) remember this redirection for a period of time (so next time SSL/TLS is used directly, without even trying plaintext first)
 * 3) prevent any unsafe certificate popups

It is basically the same as on the web, where people use an http to https redirect (point 1) combined with HSTS (points 2 and 3).

Client support
Strict Transport Security (STS) is supported by the following clients: mIRC, AdiIRC, IRCCloud, The Lounge, Ambassador, GLirc, CoreIRC, BitBot, Limnoria.

If the client does not support STS then this is no problem, these clients will ignore STS and just continue connecting as usual (eg if you told the client to connect to plaintext, it will continue to use plaintext, if you told it to use TLS then it will continue using TLS).

Enabling STS
To enable Strict Transport Security you need to configure two important things:

Step 1: Get a real certificate
You need a 'real' SSL/TLS certificate, not the default / self-signed certificate that many people use. So: get one for free via Let's Encrypt (tutorial) or buy one.

IMPORTANT: Your users must connect to the server with the same hostname as the hostname in the certificate. So if users use  then your server should have a valid certificate for   (and not, or not only for  ). Possible solutions for this are: wildcard certificates (this too is possible via Let's Encrypt) or using multiple certificates with a Sni block (rarely used).

It is very important for the certificate and naming to be correct. Without STS such a misconfiguration will only trigger a certificate warning on the client, but with STS the clients will be unable to connect. It is a hard error that clients cannot easily bypass. This is because STS integrated 2 things: it redirects from the plaintext to SSL/TLS port but it also tells the client not to do any unsafe certificate popups.

Step 2: Configure the set::tls::sts-policy block
The following will configure a STS policy, redirecting capable clients to port 6697 (which must be SSL/TLS): set { tls { sts-policy { port 6697; duration 5m; /* you can always increase this later */ };   }; };

It is very important to start with a low duration, such as 5 minutes in the example above. Of course, you can easily remove the the set::tls::sts-policy block at any time if there are any problems, however any clients that have already connected and seen the sts-policy will cache the setting for up to set::tls::sts-policy::duration time. Only after duration time has passed the client may try plaintext connections again.

You should gradually raise the set::tls::sts-policy::duration time. This to prevent you inadvertently locking users out due to a misconfiguration:
 * Begin with 5 minutes (5m) during testing.
 * After a week, consider raising it to a day (1d).
 * After a month, consider raising it to it's final setting, such as half a year (180d)

Be sure to enforce the same STS policy on all servers on your network (unless you are only testing).