The shape of things to come...

TL;DR

Squick is slated to shut off all insecure (default/traditional) IRC connections in the first week of August, 2017. This timetable may even be accelerated if deemed necessary, but we're hoping not to do that.

If you have not yet configured your IRC client to use security (TLS, once known as SSL), it will stop working when that date rolls around.
You should reconfigure your clients to use a secure connection ahead of time so you don't forget. We have guides on this here: https://squick.me/tutorial.html.

If you need help doing this, or if you use a different client than what we've documented and have a guide to contribute, please reach out to Digi.

Background

As most of you are probably aware, Squick is a network that values the privacy and agency of its users. To that end, a shift away from insecure communications has been in the works for some time -- it was the reason the network moved away from its prior IRC server software, and tightened up the cryptographic ciphers in use.

Recent events in the United States and beyond have been casting a shadow over fundamental rights that most of us have taken for granted over the years. Recently, with the deregulation of US ISPs in regards to subscriber data collection and resale, there is a very real threat that all unsecured communications will eventually become filtered, logged, and analyzed in that country, and this is a pattern that seems to be repeating worldwide.

This threat is especially grave with IRC, which like many protocols born in its era, uses insecure plain text packets by default. Without a layer of encryption to obscure that data, anyone sitting at any point along the route can read everything you send or receive on Squick. This list might include your ISP (and your friends' ISPs), those ISPs' partners, backbone datacenters, users on each local network (such as random schmucks on public wifi), and depending on where you live, even state level actors like internal security agencies.

It is the opinion of this network's staff that this sea change is disgusting, and users should be entitled to privacy when they talk with their friends or colleagues. There are both idealistic and practical reasons for this stance, but since it's unlikely anyone loaded this page for an essay, it may be simplest to point to the network's spirit and mission.

We're about to enter a phase where bolder steps will be taken to ensure all communications on the network are as secure as they can be.
Letting users stand defenseless against unchecked spying would be a gross violation of what Squick stands for, even if there may be some growing pains as a result. We hope that you bear with us through them!

(Tentative) Timetable

The current roadmap for ETAs for the transition process is listed below.
This is not final, and both practical and geopolitical factors may result in some of these items being shifted or dropped.

Timeframe Changes
Apr 09 2017 SquickBot's TLS nag module goes live. Users that connect to the network insecurely will receive a warning message, and if they stay connected that long, one reminder roughly every 48 hours.
Jun 01 2017 SquickBot's nag frequency will increase from 48 +/- 4 hours to 24 +/- 2 hours.
Jul 01 2017 SquickBot's nag frequency will increase from 24 +/- 2 hours to 4 +/- 1 hours. Insecure sessions will be killed with a warning after 24 hours.
Aug 0X 2017 A proxy IRCd will be set up for ports 6660-6669. All insecure connections will fail with a warning to switch connection security on and use a secure port.
(Future?) Ports 6660-6669 will be closed. All insecure connections will silently fail.

So what do I need to do?

Sadly, most IRC clients do not prefer secure connections over insecure ones by default, so this will not be something your IRC client will fix for you automatically.
Similarly, unlike HTTP and other protocols, we have no way to seamlessly redirect you to a secure port on IRC.

This means that you'll need to change the way your IRC client is configured to connect to Squick.
By default, most clients will be using port 6667 with SSL/TLS off. You'll need to make your client use port 6679, 6697, or 8067 with TLS on.

We have a guide on how to set up common clients to do this here: https://squick.me/tutorial.html.
(Search engines are also a great resource.)

Help! My IRC client doesn't support this stuff!

That's un-good, and it generally means your IRC client is either misconfigured, ancient, missing essential features, or buggy.
Unfortunately, we can't make any exceptions for IRC clients that aren't up to snuff, because doing so would compromise the security of everyone else on the network.

If you run into trouble setting up a secure connection, here are some potential courses of action, in about the order you should try them:

  1. Update your client, and if your client uses the system OpenSSL library (any Linux or OSX client, or mIRC), update OpenSSL too.
  2. Update your operating system. Security patches sometimes include encryption-related functions.
  3. Reach out to Digi. Include your IRC client name and version number, along with the error message you're seeing. Screenshots of your configuration may be attached to your email, and are a big help when troubleshooting. (Even if you positively know your client is incompatible already, please report it anyway; we're trying to compile a list of these things for our FAQ.)
  4. File a bug report with your IRC client's developer. It might get ignored, but features like this might not get implemented unless you make the demand known. (The developer may also want to support TLS, but be struggling with a genuine bug your report can help them fix.)
  5. Get a new client with modern security features. We have some recommendations.