CVE-2022-2663 defence-in-depth: Specify CTCP PING character limits about ircv3-specifications HOT 4 OPEN

This is probably more appropriate for Modern IRC's draft CTCP RFC than IRCv3. That said, we should really be pushing to obsolete plaintext IRC. There's just no reason to not use TLS in 2022.

In InspIRCd v4 I have made it mandatory to build with at least one TLS module and TLS will be required to link non-local servers. I'm also considering making it so TLS is required by default for logging into a server operator account. I'd recommend that other server devs do something similar.

Client developers can also move towards TLS as the default by making it so connecting with TLS is the default behaviour (i.e. require -insecure for plaintext instead of -ssl for TLS).

from ircv3-specifications.

Note I disclosed this in advance to libera.chat and they have implemented network side filtering, so it's worth mentioning it is possible to filter this at the server side too.

from ircv3-specifications.

Very cool result, thanks :-)

I have put a recommendation for client authors that they should consider dropping "^A" within PING responses.

What octet(s) is this?

from ircv3-specifications.

lol it's the linksys bug all over again

I have put a recommendation for client authors that they should consider dropping "^A" within PING responses.

What octet(s) is this?

It's the same 0x01 that begins/terminates a CTCP message, except apparently in this case it shows up in the middle of a response (where Linux mistakenly picks it up as the beginning of a real "DCC" CTCP).

(So you have to be careful to not over-filter it as the 1st or last octet of a message, because that'd break CTCP in general.)

(I don't believe IRCv3 has really considered DCC, one interesting point is many clients implement DCC, but don't necessarily implement encryption for it, so it might be interesting to consider specifying a warning when establishing a plaintext DCC session if the connection to the IRC server itself is encrypted.)

So why is TLS not a thing for DCC yet? Several other systems are successfully using TLS-PSK to bootstrap a new (D)TLS connection without needing certificates on either side – but just generating a cert on the fly and including its fingerprint in the CTCP request would probably work as well (there are again systems which do that, I believe I've seen it in WebRTC).

I mean, client-side warnings are mostly outside of what IRCv3 does, but specifying a new DCC-TLS protocol would work.

from ircv3-specifications.