NOTE: We've slightly updated this blog post to reflect our follow up post regarding netcat usage
It's been 3 years since we initially released our Hosted Challenge Deployment functionality!
We've made some changes over the years but the main functionality has been the same. Take a CTF challenge server and run it on our infrastructure with as little friction as possible.
To better achieve that goal while improving the security and reliability of the system, we're making some changes.
TL;DR
- We're deprecating the existing flow of receiving a unique port on
challenges.ctfd.io- We will no longer provide unique ports on
challenges.ctfd.ioby July 12th - We will copmletely deprecate
challenges.ctfd.ioby August 2nd
- We will no longer provide unique ports on
- Instead, deployed challenge services will receive an unique subdomain with an encrypted connection (SSL/TLS) on
chals.io(e.g.demo-challenge.chals.io) Because these services communicate over an encrypted connection you can't simply netcat to them so...- Administrators can request TCP ports for their service for users to connect with tools like netcat
- We're also releasing a new tool to make it easier to establish encrypted connections to these services!
If you have concerns about any of this please reach out to us and we'll see how we can help.
Read on for the full details!
Server Name Identification (SNI)
SNI is a way for an SSL/TLS client to specify to a server what underlying resource that it wants. For those familiar with managing web servers, it's very similar to the Host header.
Similar to the Host header, SNI allows a server to route a connection to an underlying service by looking at a hostname specified by the connecting client.
You can read more about SNI at the following pages:
- https://en.wikipedia.org/wiki/Server_Name_Indication
- https://www.cloudflare.com/learning/ssl/what-is-sni/
SNI for Challenge Services
Currently, we deploy a given challenge service by allocating it a unique port on challenges.ctfd.io (e.g. challenges.ctfd.io and 12345).
This was done primarily to support the typical netcat style CTF challenge where you run a command like nc challenges.ctfd.io 12345.
We're now moving our challenge deployment infrastructure over to an SNI based setup where challenge services will be deployed behind a unique subdomain on chals.io. For example, demo-challenge.chals.io.
Connecting to the service would simply be a matter of providing the appropriate hostname via SNI. Most browsers actually automatically do this when connecting to a website.
For example, if a web challenge service was deployed on demo-website.chals.io. You could simply open https://demo-website.chals.io in your browser.
However, this isn't as simple with netcat or TCP based challenges. You can't just do nc demo-challenge.chals.io 443. Netcat by design doesn't support any type of encryption in its connections.
But fear not, we have a solution!
If you'd like users to use an unencrypted tool (like netcat), you can request a TCP port for your challenge.
Connecting to TCP based challenges
Instead of using netcat directly with a port we've come up with a few alternative solutions to connect to a challenge service using SNI.
snicat
snicat is a tool that we're releasing that makes it just as easy to connect to SNI services. It's designed to be very similar to netcat and can be easily run on Linux, Mac, and Windows.
For example:
❯ sc demo-challenge.chals.io
(connected to demo-challenge.chals.io:443 and reading from stdin)
...netcat
For users to connect to challenge services with an unencrypted tool like netcat, you will need to "Request TCP Port".
Once a challenge is deployed, you can click on a button and our servers will allocate a hostname and port where your service will be accessible to tools like netcat directly.
This workflow is summarized in our documentation page here.
Other means of connecting to our challenge infrastructure can be found on our documentation.
Deprecation Schedule
We know that most challenge services are still in use through their current server & port connections so we are providing an approximately two month migration/deprecation period.
Throughout this period we will communicate these changes to make sure customers are aware of the change. Our first communication stream is this blog post. Subsequently we expect to regularly email our customers until and after the deprecation date.
Timeline
We have changed the following timeline after releasing the "Request TCP Port" feature as discussed here: https://blog.ctfd.io/a-follow-up-to-hosted-challenge-deployment-improvements
1. We will no longer allocate unique ports on challenges.ctfd.io beginning July 12th.
2. We hope to completely deprecate and remove the current challenges.ctfd.io infrastructure by August 20th.
- We will no longer allocate unique ports on challenges.ctfd.io beginning July 12th
- We will request TCP ports for all challenges currently on challenges.ctfd.io on July 12th
- We will completely disable challenges.ctfd.io on August 2nd
We hope that we've done a lot of the setup, planning, and testing to make this change as seamless as possible. However, it's entirely possible that we've missed something. If you believe this change will negatively affect you, please reach out to us.
Thanks again to our customers and users for supporting the CTFd project! The user experience for our products is always our priority and we thank you for your support. These changes and improvements would not have been possible without you!