Dear JDisc friends,
with the coming build 5136, we have implemented a new feature to the Security and Dependency Mapping Add-On. As you might know, the Dependency Add-On detects the list of open TCP/IP and UDP ports. A customer asked us whether we could get information about the SSL certificates and encryption algorithms for each listening TCP/IP port. That would be useful information regarding the security of applications and expiring certificates. We have recently implemented a similar feature for SSH connections where we collect the SSH cipher algorithms offered by SSH servers and the used SSH algorithms when connecting.
Checking whether a port uses SSL and, if yes, what certificates and algorithms are used requires that we open a connection to the port and try to start the SSL handshake. If the handshake succeeds, then we also get the list of certificates and the used algorithms. Didn’t sound too complicated. So I started to implement the feature, tested it on one of my Linux servers, and finally, I got all the information I needed. Cool!
Be really careful when using this feature. We are opening TCP/IP ports to test an SSL handshake. This might be triggering intrusion detection systems. So always connect with your security department before enabling this feature!
Then I started to scan my network, and at some point, my printer started to print garbage pages! I was really surprised and scanned the printer again. Same result. It started to print! Hmm. Ok, then I did some more investigations, and I found out that port 9100 was the culprit! Port 9100 is used on many printers for a service called “raw printing”. When not properly secured (which nearly never is the case), it starts printing when you send bytes to this port. The SSL handshaking communication was causing this issue because the handshake started to send an SSL ClientHello packet. The printer started then to print the incoming bytes. There is also a nice article that explains port 9100. Refer to http://hacking-printers.net/wiki/index.php/Port_9100_printing for more details. Finally, we ignore ports 9100-9107 when checking for an SSL port.
Not really funny. Due to possible side effects resulting from poorly written applications with little or no error handling, we do not enable this feature by default. However, you can enable this feature if you are pretty confident that the applications in your network have proper error handling. Use the discovery configuration to enable this feature.
When you enable this feature, a warning dialog explains again what is going to happen, and you can confirm whether you would like to use this feature. We have tested it in our environment with many different operating systems and devices, and apart from the well-known printer ports, we have not seen any issues.
But when you enable this feature, then you will get more useful information:
- in addition to the certificates that are stored within a computer’s local certificate store
- when the Security Add-On is installed in addition to the Dependency Mapping Add-On, you will get the SSL Cipher and the SSL protocol (TLS version).
Enable this feature within our Discovery Configuration dialog.
Once the scan has been completed, you can review the information from the device details dialog for a single device. Check the Open Ports tab to review the SSL-related information. Note that you get that information only when the Security Add-On is installed in addition to the Dependency Mapping Add-On.
The image above shows that some processes are still using TLSv1, which is not considered secure anymore.
There are also overview reports in the menu Software > Security > SSL section that lists the used SSL ciphers and protocols and the number of devices using those algorithms. The SSL Cipher overview report (Software > Security > SSL) lists all SSL ciphers used by devices on the network together with the number of actual devices using this cipher.
The SSL Protocol overview report (Software > Security > SSL) displays all SSL algorithms used by scanned devices.
The screenshot above indicates that three devices use TLSv1, which is considered a weak protocol.
We hope that this feature makes your network a little bit more transparent and secure!