Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STS support #139

lol768 opened this issue Sep 16, 2016 · 6 comments


None yet
2 participants
Copy link

commented Sep 16, 2016

What 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?


This comment has been minimized.

Copy link

commented Sep 19, 2016

Java 8 update 101 and above supports Let's Encrypt by default as it now trusts IdenTrust.


This comment has been minimized.

Copy link
Member Author

commented Sep 27, 2016

Would like to bag this for hacktoberfest, @mbax can you assign?


This comment has been minimized.

Copy link
Member Author

commented Oct 7, 2016

So! It looks like the folks over at Charybdis aren't going to implement this and have other, non-standard extensions planned which, to be honest, really miss the point (tlswarning doesn't do anything to enforce connections to the TLS service and it relies on users understanding and heeding the warnings, chm_insecure is a nice idea but won't automatically upgrade users to TLS connections and again relies on users understanding what's going on). They're useful tools for transitioning to TLS but don't replace STS at all and during the transition period, networks relying on these extensions and not deploying STS will be less secure as a result. STS will help give us a better standard of security, since like with the HTTP equivalent (HSTS), invalid certificates cannot have on-connect exceptions created and the spec dictates the client properly validates certificates according to the trust store (or else refuses to connect).

I went to ask in their channel on freenode for more details but it's +m so I gave up. God knows why the channel is still mentioned on their site.


Not particularly impressed by the comments from kaniini on that spec issue to be honest, but the issues here on the KICL project are for technical details, not personal opinions on other software and I'm not going to expand here.

I think the way forward for testing this is to either:

  • Fork Charybdis/some other IRCd without STS support
  • Add STS support that follows the spec without worrying too much about code quality and use this to test the Java client


  • Find a better IRCd that supports STS natively
  • Use it for testing purposes


  • Test with a ZNC module again (since I'm familiar with the codebase a little more than a random IRCd)

Since the spec is still a draft, there's no compatibility table available yet so it might be challenging to find server software supporting this.


This comment has been minimized.

Copy link
Member Author

commented Oct 15, 2016

Steps on IRCd side:

  • Fork charybdis on GitHub
  • Get it to compile locally
  • Configure test IRCd
  • Generate self-signed SSL certificates for local test IRCd
  • Configure IRCd to use said certificates
  • Get valid, CA signed certificate for local test IRCd (via Let's Encrypt)
    • Point DNS at valid external host, get certificate, point it back at localhost
  • Familiarise self with charybdis codebase
  • Add hardcoded STS support
  • Recompile, confirm working via wireshark

Script used for SSL:

# Originally written by Patrick "Argure" Godschalk <> in 2014
# Modified by Adam Williams in 2016 to actually work and be more British


if [ $# -ne 1 ]
    echo "You must supply the common name." 1>&2
    exit -1

mkdir -p "${csr_path}"
mkdir "${dh_path}"
mkdir "${ecdh_path}"
mkdir "${pem_path}"
mkdir "${key_path}"

echo "Generating private key and CSR..."
openssl req -new -newkey rsa:4096 -nodes -sha512 -out "${csr_path}"/"$1".csr \
    -keyout "${key_path}"/"$1".key -subj \

echo "Self-signing certificate..."
openssl x509 -req -sha512 -days 365 -in "${csr_path}"/"$1".csr -signkey \
    "${key_path}"/"$1".key -out "${pem_path}"/"$1".pem

echo "Generating Diffie-Hellman file for secure SSL/TLS negotiation..."
openssl dhparam 4096 -out "${dh_path}"/"$1".pem

echo "Generating EC curve parameters..."
openssl ecparam -name secp384r1 -out "${ecdh_path}"/"$1".pem

echo "Concatenating DH and ECDH parameters to certificate..."
cat "${dh_path}"/"$1".pem >> "${pem_path}"/"$1".pem
cat "${ecdh_path}"/"$1".pem >> "${pem_path}"/"$1".pem

echo "CSR is below:"
cat "${csr_path}"/$1.csr

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2016

IRCd support completed: lol768/charybdis@a5f43d4

When connecting over plaintext port (scroll all the way to the right to see the sts capability):

<< CAP LS 302
>> CAP adam LS :account-notify account-tag away-notify cap-notify chghost echo-message extended-join invite-notify multi-prefix server-time sts=port=6697 tls userhost-in-names

When connecting over secure port:

<< CAP LS 302
>> CAP Testing LS :account-notify account-tag away-notify cap-notify chghost echo-message extended-join invite-notify multi-prefix server-time sts=duration=300 tls userhost-in-names 

Now that that's out of the way the client work can begin \o/


This comment has been minimized.

Copy link

commented Dec 29, 2016

@mbax mbax closed this Dec 29, 2016

@mbax mbax modified the milestones: 3.0.0, Future! Dec 29, 2016

@jwheare jwheare referenced this issue Jan 7, 2017


Ratify STS #296

12 of 16 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.