Chall-Manager-CLI Fails To Respect --insecure Flag

[Bug]: Chall-Manager-CLI Challenge Creation Ignores --insecure Flag

Hey there, fellow CTF enthusiasts! Let's dive into a tricky situation with chall-manager-cli. Specifically, we're looking at a bug where the --insecure flag, which is supposed to tell the tool to ignore security checks (like using HTTPS when it should be using HTTP), isn't working as expected. This can be a real headache when you're setting up challenges and need to connect to registries that might not have proper SSL certificates or are running locally. Let's break down what's happening, why it's a problem, and how we can potentially work around it.

What's the Deal?

The core issue is that chall-manager-cli seems to be stubbornly trying to connect to a container registry over HTTPS, even when the --insecure flag is explicitly set. This flag is supposed to tell the tool, “Hey, don’t worry about secure connections; just go for it.” However, in this case, the tool ignores that instruction. The consequence is a failed challenge creation, which is not the desired behavior. The error log clearly shows the tool attempting an HTTPS connection when it should be using HTTP. This is a problem if your registry isn't set up with a valid SSL certificate, which is common in local development environments or when running a private registry.

Let's clarify what's happening and why it matters. The chall-manager-cli tool is a command-line interface for managing challenges in a Capture The Flag (CTF) environment. It's designed to interact with a chall-manager service, which handles the backend operations for creating, managing, and deploying CTF challenges. When you specify a scenario for a challenge, you're essentially telling chall-manager where to find the challenge's definition (e.g., the Docker image, the challenge files, etc.). The --insecure flag is provided to bypass SSL certificate verification. This is useful when your registry doesn't have a properly configured SSL certificate (or you want to skip the validation). In this particular bug, the command-line tool is ignoring the --insecure flag when creating the challenge.

This is a common issue when working with local development setups, as you won't typically set up a valid SSL certificate for your local registry. Therefore, being able to use the --insecure flag is essential. Without it, you're stuck unable to create challenges unless you configure a valid SSL certificate for your registry. The error messages provided in the logs show that chall-manager is trying to make an HTTPS request to the registry when it is not properly configured to handle HTTPS requests, or when the user specifically wants to skip SSL verification. That causes a connection error that will prevent you from successfully creating your challenge.

The Setup

To understand the bug, consider the scenario provided in the original report. A docker-compose.yml file sets up the chall-manager service, a chall-manager-janitor service, and a registry service (likely a private Docker registry). The registry service is exposed on port 5000. The problem manifests when chall-manager-cli is used to create a challenge. When using the challenge create command, the tool attempts to access the registry over HTTPS, even when the --insecure flag is provided. The provided example configuration illustrates a standard setup where a local registry is used for challenge scenarios. The docker-compose.yml file defines the services required. This setup works in the intended way if there were no security flags or if the registry was properly configured with SSL certificates. However, in this situation, the intended behavior is to bypass the certificate validation and to connect via HTTP.

What Was Expected

The expected behavior here is straightforward: when the --insecure flag is used, chall-manager-cli should connect to the registry without verifying the SSL certificate (or using HTTP instead of HTTPS, if applicable). It should successfully create the challenge, pulling the scenario from the specified registry. The challenge should then be ready to be deployed and made available to the CTF participants. The core issue here is that the tool doesn't honor the --insecure flag. The user is unable to create challenges due to the error that is caused by trying to connect via HTTPS instead of HTTP.

Scope of the Problem

This bug affects the Pulumi deployment aspect, which is related to the infrastructure-as-code. The bug prevents challenges from being created if the registry does not have a valid SSL certificate and/or when a local registry is used. This is a critical issue in any CTF setup that uses chall-manager-cli, particularly during development or testing when secure registries may not be available or are not desired. When developing or running CTFs, it is necessary to quickly deploy and iterate challenges, and this bug interferes with this process. The --insecure flag is supposed to simplify local development by allowing developers to bypass the need for a valid SSL certificate for their registry. When this flag is ignored, it adds an unnecessary configuration overhead.

Version Info

The bug has been observed in ctferio/chall-manager:v0.5.3. The version number is important because it helps track the bug's presence across different releases. If the bug is fixed in a newer version, updating the tool is a simple solution.

Log Dive

The relevant log output pinpoints the problem precisely. Here's a snippet:

chall-manager-1          | {"level":"error","ts":1759338611.5915499,"caller":"global/log.go:28","msg":"decoding scenario","reference":"registry:5000/example:1","error":"internal server error: Get \"https://registry:5000/v2/\": http: server gave HTTP response to HTTPS client","challenge_id":"example-challenge","stacktrace":"github.com/ctfer-io/chall-manager/global.(*Logger).Error\n\t/go/src/global/log.go:28\ngithub.com/ctfer-io/chall-manager/api/v1/challenge.(*Store).CreateChallenge\n\t/go/src/api/v1/challenge/create.go:100\ngithub.com/ctfer-io/chall-manager/api/v1/challenge._ChallengeStore_CreateChallenge_Handler\n\t/go/src/api/v1/challenge/challenge_grpc.pb.go:213\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.75.0/server.go:1431\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.75.0/server.go:1842\ngoogle.golang.org/grpc.(*Server).serveStreams.func2.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.75.0/server.go:1061"}

This error message clearly indicates that chall-manager is attempting an HTTPS connection (https://registry:5000/v2/) to the registry, but the registry is likely configured to use HTTP (as is typical in a local, non-SSL setup). The http: server gave HTTP response to HTTPS client error is a direct symptom of this mismatch. Even though the --insecure flag is set, the tool is not respecting it, causing the connection to fail. This detailed log output is invaluable for diagnosing the root cause of the issue, as it points directly to the HTTPS connection attempt.

Step-by-Step Reproduction

The original report provides a clear reproduction scenario. Here's a breakdown:

1. Scenario Push: Use chall-manager-cli to push a scenario to the registry. This step should work fine, as it is not affected by the --insecure flag, and it is used only to push the scenario.
2. Challenge Creation Attempt 1: Try to create a challenge using chall-manager-cli, specifying the scenario in the registry. This attempt fails with an internal server error because the tool attempts to use HTTPS.
3. Challenge Creation Attempt 2: Repeat the challenge creation, but this time, use the --insecure flag. The error persists, showing that the flag is being ignored.

This detailed reproduction steps allow anyone to easily reproduce the bug and confirm its existence.

Code of Conduct

The original report explicitly states that the user agrees to follow the project's Code of Conduct. This ensures that the issue is reported responsibly and that the discussion around it remains respectful and constructive.

Potential Workarounds and Solutions

While the bug exists, there are a few ways to work around this issue. The best solution would be to fix the bug in chall-manager-cli so it correctly interprets the --insecure flag. In the meantime, here are some options:

• Configure HTTPS on the registry: The most robust solution (if possible) is to configure your local registry to use HTTPS with a valid SSL certificate. While this is more complex, it eliminates the need for the --insecure flag.
• Modify chall-manager-cli locally: If you are comfortable with Go, you could clone the chall-manager-cli repository, modify the code to respect the --insecure flag, and build your own version of the tool. This approach may be complex but may be necessary depending on the urgency of the solution.
• Use an HTTP proxy: If your registry doesn't have SSL certificates, you can use an HTTP proxy. Configure the proxy to forward requests to your registry and to allow you to bypass the certificate validation.
• Check for Updates: Keep an eye on the chall-manager-cli project's repository. The developers may provide a fix in a future update. Check the releases to get the latest versions.
• Contribute a fix: If you are a developer, you could contribute a fix to the chall-manager-cli project. This is the best long-term solution, as it would address the bug for everyone.

By investigating the root cause of this bug, you can improve your skills and contribute to the CTF community by helping to fix the problem.

In summary, this bug highlights the need for chall-manager-cli to correctly handle the --insecure flag. With the error message provided and the reproduction steps, developers can work to correct the code and make the tool work as expected. Meanwhile, the workarounds that have been suggested provide users with the ability to create challenges while the underlying bug is addressed.

For further information, consider checking out these resources:

• Docker Documentation: Docker for learning more about Docker and registries.