Post cover image

June 10, 2026

OverTheWire Bandit Walkthrough — Level 15 → 16 | 30-Day Cybersecurity Learning Journey (Day 15)

Using OpenSSL to submit a password over an encrypted SSL/TLS connection and why understanding the difference between plain TCP and…

William | Cybersecurity & SOC Analyst

6 min read

Using OpenSSL to submit a password over an encrypted SSL/TLS connection and why understanding the difference between plain TCP and encrypted network communication matters in real security work.

Introduction

Day 15. Bandit Level 15 to Level 16. Yesterday Netcat solved the problem by sending data directly over a plain TCP connection. Today the same approach fails. The service on port 30001 requires SSL/TLS encryption. Netcat sends data in plaintext. A plaintext connection to an SSL-encrypted service produces no useful response. A different tool is needed.

This level introduces openssl s_client, a command-line tool that establishes SSL/TLS encrypted connections and lets you interact with the service on the other side the same way Netcat does for plain connections. It is the standard tool for testing, debugging and manually probing SSL-encrypted services from the terminal.

By the end of this article you will understand the difference between plain TCP and SSL/TLS communication, know how to establish an encrypted connection from the command line and recognise what a self-signed certificate warning means and why it appears.

Level Objective

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 official page includes a helpful note: if you see DONE, RENEGOTIATING or KEYUPDATE in the response, read the CONNECTED COMMANDS section in the man page. The suggested commands include openssl, s_client, ncat, socat and nmap.

Approach

I connected to the Bandit server from my local Kali machine using the password retrieved from the previous level:

ssh bandit15@bandit.labs.overthewire.org -p 2220

The full Bandit ASCII art banner loaded and the prompt changed to bandit15@bandit:~$.

None None

With the session open I used openssl s_client to connect to port 30001 with SSL/TLS encryption enabled. The -ign_eof flag prevents the connection from closing when stdin ends, which allows the password to be submitted and a response received cleanly:

openssl s_client -connect localhost:30001 -ign_eof

The SSL handshake completed and the terminal printed a block of connection details confirming the encrypted session was established. The output showed Verify return code: 18 (self-signed certificate). This is expected behaviour on the Bandit server. A self-signed certificate means the certificate was not issued by a trusted certificate authority but the connection is still encrypted. It is not an error.

After the read R BLOCK prompt appeared indicating the server was waiting for input, I submitted the current password:

8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo

The server responded with Correct! followed by the password for Level 16 on the next line. The connection then closed cleanly.

None

Commands Used

# Connect to the Bandit server as bandit15 using the Level 15 password
ssh bandit15@bandit.labs.overthewire.org -p 2220
# Connect to port 30001 using SSL/TLS encryption and keep the connection open
openssl s_client -connect localhost:30001 -ign_eof
# Submit the current level password when the server prompts for input
8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo

Command Breakdown

openssl s_client -connect localhost:30001 Opens an SSL/TLS encrypted connection to port 30001 on the local machine. The s_client subcommand is specifically designed for connecting to SSL/TLS services and interacting with them interactively. It performs the full SSL handshake and then allows you to send and receive data through the encrypted channel.

-connect localhost:30001 Specifies the host and port to connect to. The format is hostname:port as a single argument. This is different from how Netcat takes the hostname and port as separate arguments.

-ign_eof Tells openssl s_client to keep the connection open after stdin closes. Without this flag the tool closes the connection as soon as it finishes reading input, which can cause the server response to be missed. Including it ensures the full exchange completes before the connection ends.

Verify return code: 18 (self-signed certificate) This line in the output indicates that the server's certificate was not signed by a trusted certificate authority. On a production server this would warrant investigation. On the Bandit game server it is expected because the certificate is self-generated for the game environment. The connection is still encrypted regardless of whether the certificate was issued by a trusted authority.

read R BLOCK The server's prompt indicating it is waiting for input over the SSL connection. This is the moment to submit the password.

Lesson Learned

The main technical takeaway is that SSL/TLS encryption wraps a plain TCP connection in a cryptographic layer that protects the data in transit. The underlying workflow is identical to what Netcat does: connect, send data, receive response. The difference is that everything between the client and server is encrypted. Knowing which tool to use for which type of connection is what separates a failed attempt from a successful one.

The self-signed certificate warning is worth understanding properly. A self-signed certificate does not mean the connection is insecure in terms of encryption. It means the certificate was not verified by a third-party authority that both parties trust. In a game environment this is fine. In a production environment it raises legitimate questions about whether the server is who it claims to be. That distinction matters in real security work.

The read R BLOCK prompt is also worth noting. Recognising that the connection was established and waiting for input rather than immediately returning a response shows that the SSL handshake succeeded and the interactive session was open. Knowing what that prompt means prevents the confusion of thinking the command is hanging.

  • openssl s_client -connect host:port — connect to an SSL/TLS service
  • openssl s_client -connect host:port -ign_eof — keep connection open after input ends
  • openssl s_client -connect host:port -CAfile cert.pem — verify against a specific certificate
  • openssl s_client -connect host:port | head — quickly inspect the SSL certificate details
  • nc localhost port — plain TCP connection for non-encrypted services

🔴 SOC Analyst Insight

SSL/TLS is present on almost every production service an analyst interacts with during an investigation. When investigating suspicious outbound connections, understanding whether a service is using encryption is critical for determining what traffic analysis is possible. An encrypted connection cannot have its payload inspected by a network monitoring tool without SSL inspection configured at the perimeter.

# Test SSL/TLS connectivity to a suspicious external host and retrieve certificate details
openssl s_client -connect suspicious-host.com:443 -showcerts 2>/dev/null | head -30

The command above connects to a host over HTTPS and displays the certificate chain. During an investigation into suspicious outbound traffic this can reveal whether the certificate is legitimate, self-signed, expired or associated with known malicious infrastructure. Certificate details including the issuer, validity period and subject alternative names are all visible from this single command without needing to load a browser or a dedicated certificate inspection tool.

Self-signed certificates on external hosts are a significant indicator during threat hunting. Malware frequently uses self-signed certificates for command and control communication because they are quick to generate and require no interaction with a certificate authority. Seeing Verify return code: 18 on an external connection is an immediate flag worth investigating further.

Key Takeaway

SSL/TLS encryption is the standard for any service that handles sensitive data over a network. Knowing how to establish an encrypted connection manually from the command line, interpret the SSL handshake output and recognise certificate warnings is a practical skill that appears in service testing, certificate investigation and incident response. openssl s_client is the direct equivalent of Netcat for encrypted connections and understanding both tools together gives a complete picture of how to interact with any network service regardless of whether it uses encryption.

30-Day Cybersecurity Learning Journey — Progress

🟢 Open Day — Setup & Series Introduction  | OverTheWire Bandit
✅ Day 0.   — Bandit Level 0               | First Login
✅ Day 1.   — Bandit Level 1 → 2           | Special Characters
✅ Day 2.   — Bandit Level 2 → 3           | Spaces in Filenames
✅ Day 3.   — Bandit Level 3 → 4           | Hidden Files
✅ Day 4.   — Bandit Level 4 → 5           | File Types
✅ Day 5.   — Bandit Level 5 → 6           | find with Properties
✅ Day 6.   — Bandit Level 6 → 7           | find across Filesystem
✅ Day 7.   — Bandit Level 7 → 8           | grep
✅ Day 8.   — Bandit Level 8 → 9           | sort and uniq
✅ Day 9.   — Bandit Level 9 → 10          | strings and grep
✅ Day 10.  — Bandit Level 10 → 11         | base64
✅ Day 11.  — Bandit Level 11 → 12         | ROT13 and tr
✅ Day 12.  — Bandit Level 12 → 13         | hexdump and compression
✅ Day 13.  — Bandit Level 13 → 14         | SSH keys
✅ Day 14.  — Bandit Level 14 → 15         | Netcat
✅ Day 15.  — Bandit Level 15 → 16         | SSL and OpenSSL  ← today
⬜ Day 16.  — Bandit Level 16 → 17         | coming next

Follow along with the series as I document each level, command and lesson learned.

Plain TCP and encrypted TLS use the same concept. The difference is one layer of cryptography and one different tool.