We’re skipping the LAN Turtle module that would have been show cased this week in favor of a short post. On the bright side, I got 1804 words written for my first day of NaNoWriMo 2016. On the less than shiny side, I’m oncall this week at work, and I’m short on time for the Wednesday post. So let’s get to it.
Today’s topic is a tool that some people may not realize can be used in the same vein as telnet, netcat, and socat for connecting to ports and testing them with manual manipulation of whatever the plain text protocol might be (such as HTTP or IRC, for example.) It can also be used to stand up a temporary SSL enabled service for testing how clients behave, similarly to how a netcat listener might be used.
To test connectivity, use the “s_client” module with the “-connect” flag. The target of the -connect flag should be an IP or hostname with a port, and separated by a colon. For example:
openssl s_client -connect google.com:443
Once you connect, you should see some information about the certificate along with a status code to indicate what the problem is if the certificate doesn’t meet expectations. It will then sit and wait for you to send whatever commands you might like just like a telnet or netcat connection would do. It handles the actual SSL handshake for you.
The listening option is the “s_server” module with the “-accept” flag. The target of the -accept flag is just a port number. Of course, the listening service should probably also be given a certificate to use for the listening connection, so use the “-cert” flag to pass a certificate to this command for use on the listening socket. You can set up a listening socket without a cert by using the “-nocert” flag, but this is kind of pointless.
Again, the primary focus of this for most people will be the s_client module, so that SSL enabled ports can be probed for banners and such. Alternatively, shell scripts can be written that call this in order to automate certain kinds of connections with intentionally malformed requests to test how the server behaves, or to pass known vulnerable requests to the server, and so on.
Of course, it can also be used to look at the server’s certificate and settings in case there is a vulnerability there, such as a weak cipher list, for example. Perhaps the certificate is due to expire, soon. A man in the middle situation might be easier to set up during that window between certificate expiration and certificate renewal if the site owner allows the cert to fully expire before renewing. Possibilities are almost endless.
That’s all for now. Thanks for reading!