Today Cloudflare, one of our infrastructure providers, revealed that they were subject to a security vulnerability which may have resulted in some private IRCCloud data, including passwords and chat history, being leaked between September 2016 and February 2017.
No payment details were affected.
We understand the chances of any information being compromised are very low, but we take these issues very seriously indeed. We are immediately requiring all users to re-authenticate when they next load IRCCloud. We’re sorry for the inconvenience this will cause.
We recommend that all IRCCloud users change their account passwords, and we are reviewing our security in light of this issue.
TL;DR: IRCCloud now supports the IRCv3 Strict Transport Security draft.
We’ve always worked hard to ensure secure access to our service. For instance, we’ve enforced HTTPS in our web and mobile apps from day one. We were also early adopters of an HTTP Strict Transport Security (HSTS) policy that adds even stronger safeguards to secure connections, and our policy is now preloaded in all major browsers.
Employing strict security policies for access to our service is important because it protects users who might otherwise be using an untrusted internet connection. But until now, onward connections to IRC networks haven’t enjoyed the same degree of protection.
As mentioned in a previous post, we’re an active participant in the IRCv3 working group. Recently this has involved developing a Strict Transport Security (STS) mechanism for IRC. A first draft specification has now been published, and we’ve just enabled support in IRCCloud.
This means we’ll verify that IRC servers support STS, and always use secure connections with servers that do. Also, if an STS-enabled server fails certificate validation, we’ll refuse to connect and show errors like these:
This is an important change. An invalid certificate can indicate that a secure connection has been compromised and is no longer secure. Previously, if you chose the “Secure port” option when joining a new network, we made sure to connect using TLS/SSL, but we wouldn’t inform you if any certificate errors are encountered. For servers without STS, we aren’t changing this behaviour straight away.
This decision was made because a significant number of IRC networks are set up to use free, self-signed certificates that can’t be validated. These networks are largely volunteer-run with no budget, but our users still expect to be able to connect to them. If we showed an error message on each of these connections, users would quicky learn to ignore security warnings.
However, that situation is gradually changing. With an increased interest in securing our communication channels, and the emergence of free certificate authorities such as Let’s Encrypt, we’re starting to see more IRC networks switch to validated certificates.
In light of this shift, and along with mandatory certificate validation for servers that use STS, we’ll be looking into ways to better surface certificate errors in future.
In the mean time, the IRCv3 STS specification is still being finalised, and you can keep track of its progress on GitHub.
IRCv3 is a working group of client/server software authors and network operators from the community, set up to advance the IRC protocol.
IRCCloud has been an active participant in the group since early on, and we’ve implemented the protocol enhancements where they’ve made sense.
Today, we gave a big upgrade to our support and we now handle most of the IRCv3.2 specification. You can check our compatibility progress in the client support tables.
We’re excited to be part of the future of IRC, and support for these enhancements represents our commitment to IRC as the best-suited chat protocol for open communities.
Here’s a brief summary of the features we support and what they mean for users:
CAP is the mechanism used to negotiate all other features. IRCv3 specifications are backwards compatible, and enhancements are only enabled if both server and client support them.
SASL is an authentication protocol, which improves the way e.g. NickServ login is performed, allowing connections to be established more quickly.
multi-prefix allows clients to keep track of more than one level of channel mode, so a user that has both op and voice will appear correctly when de-opped.
account-notify lets a client know when users in channels they share become authenticated or deauthenticated with their account (with NickServ for example). A user’s logged in account can be seen by clicking on their nickname.
away-notify lets a client know when users go away or come back, so that the member list can be greyed out accordingly without having to continually poll the server for this status.
extended-join lets a client know the real name and account name of a user when they join a channel. This information is shown when you click on a user’s nickname.
account-tag attaches a user’s account to every message they send, which can be helpful when private messaging someone who doesn’t share any channel with you.
batch allows servers to batch certain messages. This isn’t used for anything yet, but as batch types become available on IRC networks we’ll be able to enable it more easily.
cap-notify lets a client know when a server adds or removes support for a new capability. This is used by bouncer software like ZNC to vary the available features when you detach or reattach to a server.
chghost sends a host change message to a client when they cloak or decloak, instead of faking a quit and rejoin.
invite-notify sends a specific command to channel members with appropriate permissions when someone is invited to the channel.
server-time allows a client to show the actual time a message was received by a server, useful when playing back history from an external bouncer. This is available in newer versions of ZNC (1.2+).
userhost-in-names provides full userhost details for members when joining a channel. This makes it easier to apply bans or ignores by clicking on a user’s nick name, without having to /whois them first.
znc.in/self-message is a CAP used by ZNC that makes sure all connected sessions receive a copy of any private messages sent by any other session.
Not all of these enhancements are supported by all IRC networks yet. For instance, many of you connecting to Freenode won’t immediately be able to take advantage of
away-notify from 3.1 or any of the 3.2 CAPs. But support for these will improve in time.
Take a look at the server compatibility tables, for an idea of how well these features are supported by various IRCd software.
In future, we’re planning to use IRCv3 to enable more enhancements on our team servers, things like user avatars, rich bot payloads and more, and hopefully these will make their way out to the larger public networks to improve the IRC experience for everyone.
Send us an email on email@example.com or join us in #feedback if you’d like to discuss any of these features in more detail.
From today you can pay for 12 months of IRCCloud up front — and we’ll give you 2 of those for free when you do.
That’s $50, £35, or €40, depending on where you are in the world.
Just head over to the upgrade page, cancel any existing monthly subscription you have, and choose the Restore with a new payment method option. If you still have time left on your subscription, your restored subscription will be extended accordingly.
You can either choose to pay on a recurring or one-off basis for annual payments, while monthly payments will remain recurring only for now.
Annual billing gives you all the same benefits as monthly: stay permanently connected to IRC, connect to as many networks as you need, and access private passworded networks. Say goodbye to wrestling with the finance department over invoices every month.
Thanks for your support!
Today we’re launching a design update for the web app. And with it some highly requested features. These updates will make it to our mobile apps in due course.
We’ve retired the header, and links that used to live there and in the sidebar have been reorganised into an account menu in the bottom right.
7 new official dark themes
The settings screen has had an overhaul, most notably to accomodate a range of new colour schemes, a monospace font option, and a switch to move the sidebar to the left.
Next, options that used to be per-channel, like image embedding, can now be set globally.
And for those of you with too many channels to keep on top of, you can now choose to mark channels as read automatically.
We’ve also added more nickname colours, so clashes should be less common—but they can never be fully avoided. A side effect is that colour assignments will have changed.
There are lots of other little changes, let us know your favourites in our #feedback channel or on Twitter.
Oh and ask us on IRC if you’d like to be included in early beta access to these changes on mobile.