TLS Prober: What is tls-testing.opera.com and what does it do?

We have written several articles^1,2,3,4 about the results provided by the TLS Prober, and occasionally provided information about specific tests it performs. In this article we will provide more details about what tests are performed.

For new readers, the TLS Prober was created to monitor the patching of the TLS Renego Security Vulnerability, CVE-2009-3555, possibly the most severe vulnerability to affect the SSL/TLS protocol. It allows a Man In the Middle attacker to, for example, inject HTTP requests into the beginning of a user's connection with a vulnerable server and have them performed with the user's credentials (A Proof of Concept demonstration in November 2009 posted the victim's Twitter username and password to their Twitter stream).

To fix this problem, all SSL/TLS clients and servers must be updated to support a new TLS Extension, the Renegotiation Information Extension, documented in RFC 5746. However, before clients can start to become strict about this extension, and thus protect our mutual users against this attack, as many servers as possible need to be patched.

The TLS Prober is one of the projects that is used to monitor this situation. Another project is Ivan Ristic's SSLLabs project, and it is possible that Netcraft has added such testing to their survey.

In addition to monitoring the "Renego" issue, the Prober also tests servers for a number of other capabilities and problems, which can aid the SSL/TLS client vendors in deciding which functionality to support, or which problems to be aware of when maintaining their implementations.

The TLS Prober consists of a group of computers that connect to the Internet via the hostname "tls-testing.opera.opera.com" (213.236.208.19, formerly known as "probes.opera.com").

When running a test these computers run many scripts in parallel, each testing a different secure server, then registering the results in a database.

As mentioned previously, the TLS Prober is based on TLSLite, a Python-based TLS implementation, which has been updated with extra TLS functionality and instrumented to test a number of variants that we have observed in clients and servers.

The weekly run of the TLS Prober is normally performed Monday and Tuesday each week, although the TLS Prober might be configured to run special tests at other times as well.

When probing a server (a single IP address and port is only tested once, even if it has several names), the following tests are performed:

Capability checks:

• SSL v2
• SSL v3
• TLS 1.0
• TLS 1.1
• TLS 1.2
• General support for TLS Extensions (such as Server Name Indication,
  Certificate Status)
• Support for the TLS Renegotiation Indication Extension
• Support for the TLS Session Ticket Extensions
• TLS Session Resumption? (Not having this enabled can cause performance issues for the server)
• Trigger TLS connection renegotiation? (Might indicate a security vulnerability)
• Accept TLS connection renegotiation triggered by the client? (Might indicate a security vulnerability)
• Support of various encryption methods, some of which are weak, and
  therefore could be a security problem.

Checks for correct handling

• Tolerates TLS 1.3? (This is a, currently, non-existent version of TLS, version code 3.4, but next on the list. Not accepting this is astandards violation)
• Tolerates TLS NG.1? (non-existent version, with version code 4.1, not accepting this is a standards violation)
• Uses correct version field in the Client Hello message (some servers
  use the wrong field)
• Does not require one version field in the Client Hello to contain
  specific values before accepting the other.
• Does the server handle the version field in the RSA Client Key exchange correctly?
• Does the server accept that the client sends extra long padding
  in the block cipher modes? The encrypted record must be a multiple of 8 or 16 (depending on encryption method), so it must be padded with anything from 0 to 255 bytes, as long as the total length is a multiple of the block length (8 or 16 bytes).
• Correct handling of bad data in the Renego extension?

A number of these are tested in various combinations, some enabled, others not.

In most cases, once the TLS connection has been successfully established, the Prober will shut it down; only in a few tests will it send a limited request to the server. Some tests use functionality that is not supported by TLSLite, such as the large number of encryption methods it tests for, and in such cases the Prober will shut down the connection as soon as it has all the necessary information, since it cannot complete the full handshake.

The number of tests can range from about 60 to upwards of a couple of hundred, performed one at a time, depending on the capabilities of the server, and how many problems are encountered. If a connection fails, the Prober will retry a couple of times to make sure it was a test failure,
and not something unrelated that caused the connection to be closed. The whole process can take a few minutes depending on network speed and response times.

Additionally the Prober collects data about:

• Name and version of server software, if provided. For a HTTPS site
  this is done by sending a HTTP HEAD request for https://www.example.com/, an action that limits the load on the server, and avoids sending unnecessary data to the Prober since the response is only the HTTP headers, not content. For mail servers the first "hello" line from the server is registered, although it is not a reliable indication of vendor and version.
• Certificates presented by the server
• OCSP Certificate status from extension
• Length of temporary Diffie-Hellman key (DHE-key)

At present the TLS Prober supports the following application protocols:

• HTTPS
• IMAP
• POP
• SMTP

In addition to the Prober, the system also has a scanning functionality that can check various domains (either by name or IP address range) for servers on specific hostnames and ports. This scanner will only do a quick test to see if there is something that looks like a SSL/TLS server on the tested port, and if so, registers it for a full test with the Prober once the scanner has completed its run.

A few system administrators have asked about what tls-testing.opera.com/probes.opera.com does, and we hope the above description satisfies those who wonder about what goes on, and that they have been assured that the Prober is only testing legitimate, or almost legitimate, variations of the TLS protocol, and is not trying to break into, or damage, their servers.

If your server is among those being tested, thank you for your participation (and another thank you if you have patched the Renego issue).