Testing SSL with command line tools
In an post over at the excellent TaoSecurity blog, Richard writes about discovering nssl, an SSL-capable version of netcat. A reader reminded him that the openssl command line utility can also act as an ad hoc SSL client like so
openssl s_client -connect www.example.com:443
The above lets you connect via SSL to a web server and manually type HTTP commands just like you can with non-SSL web servers using plain old netcat and telnet.
The OpenSSL command-line utility is a swiss army knife for encryption protocols. You can use it for far more than just generating keys and connecting to SSL servers. But there are also many other command-line tools that are incredibly useful for SSL testing and discovery purposes:
- Gnu wget can fetch HTTPS URLs, if it has been compiled with SSL support. To view the HTTP response headers, try wget -S
- Lynx and elinks text-based web browsers (again, assume they have been compiled with SSL support)
- Cadaver for SSL-enabled WebDAV servers
- stunnel for tunnelling any traffic through SSL
- ssldump for sniffing and decrypting SSL traffic
SSL tools like these are valuable for assessing more than just web servers. About a year ago we had a contract to do a security assessment of Cisco Security Agent (a host intrusion prevention tool originally developed by "Okena"). After a bit of network sniffing and poking around the server directories, it turned out that CSA client and server communicate using HTTP encrypted with SSL over a non-standard port (a huge number of commercial products use simple HTTP and SSL as their client-server protocol. They just run it on a port other than 443 to disguise the fact).
To evaluate how robust the client and server were to attack, we used ssldump to decrypt and the raw HTTP traffic (this was possible only because the CSA server held the SSL host key).
Once we could capture the raw HTTP and understood how requests were formatted, we used openssl, stunnel and other tools to capture and replay communications between server and client, spoof traffic, impersonate endpoints, and "fuzz" the communications looking for overflows and other obvious vulnerabilities. The product withstood attack fairly well.
Were it not for the availability of these command-line tools, especially ssldump, performing the vulnerability assessment would been much more limited and involved coding a lot of custom SSL clients using something like Perl and the LWP library.
It always bugs me when vendors use the word "secure" when they really mean "encrypted". Encryption is only one tool that can be used in security, and usually it’s not the encryption that’s the weak point. In other products we’ve evaluated, a little sniffing and investigation revealed that while SSL was the method of encryption, the key size was 48 bits or lower, making brute force decryption feasible. Worse, some products ignore the authentication features of the SSL protocol, allowing either the client or server to be impersonated by an attacker with ease. There’s not much point in encrypting traffic when there’s no authentication of the client or server.
Many vendors use encryption to hide how weak their client-server communications really are. It’s a good thing that excellent open source tools like the above make vulnerability assessments of SSL-encrypted communications almost the same level of difficulty as assessing non-encrypted ones.
Related posts: