STS support
See original GitHub issueWhat is it?
It’s similar to HSTS (HTTP Strict Transport Security) on the web, and it can be used by a server to tell the client “Hey, you! Don’t connect to me over an insecure connection!”.
Why do we need it?
The internet is a scary place now. We can’t afford to do things in plaintext anymore, and IRC is no exception. There’s been great success with HSTS on the web (although it’s not as widespread yet as I would’ve hoped) and IRC should follow suit.
Servers and clients that support this new capability will connect in a secure manner, even if the user misconfigures the client to connect over a plaintext port. It will also allow server operators/admins to seamlessly upgrade users to a secure connection if they haven’t yet rolled out TLS.
How’s it related to the tls
CAP?
It’s not, really. The STS spec says:
In practice, switching protocols in the middle of the stream has proven to be complicated enough that only a small number of clients bothered implementing STARTTLS.
The reality for KICL is that it wasn’t implemented because STARTTLS is actually a really, really awful idea easily defeated by an active MitM - not because the concept was “too complicated”.
The sts
system effectively replaces the tls
capability and is actually a sane idea.
Okay, how’s it work?
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (6 by maintainers)
Java 8 update 101 and above supports Let’s Encrypt by default as it now trusts IdenTrust.
https://github.com/KittehOrg/KittehIRCClientLib/commit/3d097ecaa23127b662b66ca32463405b14f677f7