Executive summary: The TLS Prober is a tool that gathers information and statistics about the state of the SSL/TLS protocol security features and vulnerabilities across the internet. It does nothing that will harm your server.
The TLS Prober is a tool I developed while I worked I worked at Opera Software, originally to track the progress of the TLS Renego problem, and which I was allowed to take with me when I left Opera in early 2013. It is primarily used to scan a set of 23 million hostnames, most of the names derived from Alexa top million domain names, resulting in tests of about 500000 unique servers, for their support of SSL and TLS features, as well as checking for various interoperability issues and vulnerabilities.
Similar tools are also in use by others, such as the Qualys SSL Labs prober.
The TLS Prober is written in Python, and based on a modified TLS Lite library with a lot of instrumentation for the various tests added to the library. The source code as of the time I left Opera can be found at GitHub.
Since leaving Opera I have expanded its functionality somewhat, adding new tests, and started scanning again at variable intervals, from a few weeks apart, to several times a week, depending on what is going on. A scan of the entire IP v4 address range is under consideration.
The TLS Prober is currently hosted on the IP address 195.159.233.44 and is called tls-testing.tlsprober.net.
What kind of tests does the TLS Prober do?
- It tests for support and tolerance of all defined SSL and TLS protocol versions, including obsolete versions (some that should be blocked), as well as tolerance for future versions.
- It tests for support and tolerance of a number of existing TLS Extensions
- It tests for support of many encryption methods defined for TLS
- It tests whether the server is patched for specific issues, or tolerates clients that are patched for other issues, examples include TLS Renego, BEAST, Heartbleed, the OpenSSL CCS issue, and most recently, POODLE.
- Some of the tests include sending bad data to the server, to check if the server correctly refuses to accept the message, or if it incorrectly accepts it.
- Usually the Prober will shut down the connection immediately after it has successfully established the connection. In some cases it will be performing smoketests to detect support for features or methods that are not implemented, and in such cases the connection will be shut down as soon as the necessary information has been gathered.
- It does ask the server to complete a few HTTP requests, all of which are for “/” and usually sent as a HEAD requests to reduce the load on the server
- In total, the Prober will usually perform these tests using 100-300 connections, one at a time. The number of connections will depend on the responses from the server, and using more connections usually means that the Prober is either detecting a lot of features or there are problems with the server.
- While primarily used to scan HTTPS servers, the TLS Prober can also perform similar scans for email servers.
In no circumstance does the Prober send data that will harm the server, or that, in most cases, could be considered an attack. An exception might be tests like the Heartbleed test, when it is necessary to simulate the problem, but this particular test is intentionally coded to only try to get 512 bytes, which is enough to determine if the server really is vulnerable, but not enough to get any useful data, and the returned data is in any case never stored or inspected.
There have been a few questions about what the scanner is doing, and I hope this answers your questions and that you have been assured that the TLS Prober is not trying to break into your server.
If your server is among those being tested, thank you for your participation.
A previous article about the TLS Prober, from the Opera period, is available at the WayBack machine.
