About a week ago we posted our blog post "Hosted Challenge Deployment Improvements" detailing some of the changes we've been working on for our infrastructure for deploying CTF challenges.
Note that we've also updated our previous blog post to reflect the updates outlined in this post
Since that post, we've received very useful feedback and now have an update to share in response.
Netcat Usage
The most important piece of feedback that we received dealt with using netcat directly on our challenge infrastructure.
On our new infrastructure, netcat could not be used to connect without using a proxy between our encrypted servers and the unencrypted netcat connection.
This design was a mistake.
After rolling out the feature to CTFd administrators it became clear that we needed to support unencrypted connections to challenges. Some users can't install new tools, and for some users requiring new workflows was inconvenient.
So, we went back to the drawing board and came up with a solution for allowing TCP port access to deployed challenges!
Requesting TCP Port
In addition to the changes previously outlined we are now adding the ability to "Request TCP Port" for deployed challenges.
Essentially 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.
Updated Timeline
This improvement to our infrastructure drastically simplifies the migration process. It's just a few clicks now!
As such we're making a few changes to our migration timeline for the challenges.ctfd.io infrastructure.
- 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
In our initial testing with users, we did not find that users were averse to installing new tools to connect to CTFs. However in hindsight, we should have predicted the need for direct TCP access. The ubiquity of netcat can't be understated and although we certainly believe in our new SNI based challenge infrastructure, it's clear that we need to allow for all clients to be useable, not just the ones that we've written.
Thanks again to all the customers and users who provided beta and release feedback on our challenge infrastructure! We might not have had all the features ready at launch but we're always listening to feedback so that we will get there!