pete > courses > Crash Course in System Security (CSCI 1005), Winter 2025 > Day 13

New tools

• s_client (openssl)
• browser Developer Tools

DOS-ifying netcat/s_client

When you hit the Enter key whilst providing input to, say, netcat or s_client, the newline character ('\n', ASCII 0xa) will be entered. I haven’t found a super-convenient way to enter the linefeed character (’\r', ASCII 0xd) that many text-based application-level protocols expect. You can, however, ask sed to sneak a linefeed in before every newline character you enter:

$ sed -ue 's/$/\r/' | nc hostname port

$ sed -ue 's/$/\r/' | openssl s_client hostname:port

The latter won’t actually work, however, because s_client terminates once it has reached the end of its input—this does not permit enough time for the output to arrive. We can insert a pause to manage this:

$ (cat request ; sleep 2) | sed -ue 's/$/\r/' | openssl s_client hostname:port

(Note: apparently, HTTP/2 has subtleties that make it not work with this method: use HTTP/1.1 instead.)

Exercises

See go/ in action

Use the tools we have discussed to observe the various steps (DNS and HTTP) involved in visiting a go link.

Verify HTTP

Fetch my webpage using a graphical browser. Observe the operation using Wireshark. Verify that you understand the meaning and importance of each packet. Understand why the packets are sent (ie, what computation the browser is performing that causes each packet to be sent).

Manual HTTP (client)

To continue our theme of avoiding fancy programs that do all the work for us, use netcat (likely along with the sed trick above) to manually construct and send an HTTP request. Observe the traffic in Wireshark.

Manual HTTP (server)

On the flip-side, set up netcat to behave as an HTTP server and point your browser at it (you can use an IP address instead of the hostname in the URL). Type random-ish responses to the browser, see how it responds.

Messing with TCP: sequence numbers

Extend your Scapy-based TCP connection program from last week to mess with sequence numbers; see how the remote host responds. Try higher or lower than expected values; try much higher or lower than expected values. Record your results. Draw conclusions about how the TCP protocol is supposed to work.

Messing with TCP: timing

Extend your Scapy-based TCP connection program from last week to delay expected responses such as ACKs; see how the remote host responds. Measure the behavior you see. Draw conclusions about how the TCP protocol is supposed to work.