Bandit 15 → 16: ask the box which tools speak TLS

Same shape as the last level — a port on localhost, a conversation, a password going up the wire — with encryption wrapped around it. The command it finishes on is one line. Everything interesting here is about how you find that line.

the goal

The password for the next level can be retrieved by submitting the password of the current level to port 30001 on localhost using SSL/TLS encryption.

the approach

The level page links two things to read, and neither of them gets you to the command.

The first is the TLS page on Wikipedia — a spec-and-history article: version history, cipher suite tables, a long catalogue of named attacks. That’s not background for a wargame level, it’s a reference document, and reading one straight through with no question in hand goes nowhere.

The second is the OpenSSL Cookbook chapter on testing with OpenSSL. The one thing it hands you is the name testssl.sh, and chasing that is wrong twice over. It isn’t part of OpenSSL — it’s a third-party bash script — and it isn’t on the box. It’s also the wrong category of tool: testssl.sh audits a server’s TLS configuration, telling you which protocol versions and ciphers it accepts. That’s the same split as nmap versus nc last level. Scanning a service and talking to one are different jobs.

Flags copied off a web page get rejected outright, too — illegal option. Worth recognising that error: it comes from the argument parser, not from the operation. Nothing connected and nothing ran. The tool looked at the flag and said it doesn’t have one by that name, which usually means the documentation describes a different implementation, or a different version, than the binary in your hand.

That’s the cue to stop reading the internet and start asking the machine. The level names ten tools. Every one of them ships a man page, so “which of these speaks TLS” is a question the box can answer directly:

man nc | grep -i -e ssl -e tls

Nothing — which is a definite answer about one tool, arrived at by checking instead of guessing. So ask the other nine at once:

for t in ssh telnet nc ncat socat openssl s_client nmap netstat ss; do
  echo "=== $t"
  man "$t" | grep -i -c -e ssl -e tls
done

Four come back with hits: ncat, socat, openssl, s_client. Ten unknowns down to four candidates, in about a minute, without opening a browser.

The command that finishes it:

openssl s_client -connect 127.0.0.1:30001

Once that’s up, the rest is the previous level again — submit the level 15 password, get the level 16 password back, both redacted here. The whole difference between this level and the last one lives underneath that conversation, not in it.

the takeaway

The brick isn’t openssl s_client. It’s that the box documents every binary on it, so “which tool do I need” is a one-minute question with a definite answer:

man <tool> | grep -i <thing-you-need>

Ten tools interrogated in less time than either linked article takes to read.

A tool’s name tells you nothing about what it does. nc, ncat, socat, s_client — those names are historical accidents, not descriptions. There’s no way to sort that list by reading it. You have to ask.

Read with a question, not for comprehension. Man pages are reference, written for someone who already knows the tool and needs a flag. Trying to understand one top to bottom fails every time. Going in with “does this do TLS, yes or no” works immediately, and everything on the page that isn’t answering that is fine to skip.