TLS Prober: Email surprise

Some of those who follow our TLS Prober articles may have noticed that in our article last week, describing the tests performed by the TLS Prober, we mentioned several email protocols among the protocols tested by the TLS Prober and perhaps wondered why we had never posted any results about that.

Well, the email test functionality was actually only added two weeks ago, and, at the time the above article was published, we were still running the first full scale tests (which also was part of the reason for publishing that article at that time).

Last week, the TLS Prober tested 1.4 million email servers, from a scanned set of 9 million names generated using common hostname prefixes in combination with domain names from several Alexa Top Million site lists from the past 18 months. While this set is dominated by popular domains, there were so very few mail servers tested in the Alexa top 10,000 segment that I cannot consider that segment of the data to be useful; therefore it is not used below. Another bias is that very few SMTP servers on the standardized port 25 were tested, due to access to these ports being blocked (by our network) at the time the test set was generated, 126,000 SMTP servers hosted on the non-standard port used to bypass such blocking was tested, though.

The results of this test was something I looked forward to with some trepidation. The reason is two-fold: first, the main focus of patching the Renego issue until now has been on HTTPS servers, not mail servers, and second, the email protocols are, supposedly, not affected by the Renego issue when properly implemented, due to requirements in their specifications for how they should handle a renegotiation (require re-authentication of the client).

Therefore, I expected that patch coverage for email servers should be markedly lower than the HTTPS webserver patch coverage.

This expectation turned out to be mistaken.

It turns out that, among the email servers scanned in this sample (which is biased towards popular sites), the overall patch coverage is 74.4%, as compared to the 58% HTTPS coverage in our normal test set (the big set's result is probably a bit higher, but not by much).

There was little variance in Renego patch coverage between the various email protocol variants, the largest being normal SMTP at 67.6% coverage (but this set may have been affected by the above mentioned bias, and also had only 40% as many tested servers as the other protocols, the rest of the tested protocol variants kept inside 74.7-75.5% coverage).


What is the reason for this difference between what was expected and the reality?

After discussing this with a few people, it probably comes down to the fact that email servers are relatively simple installations and can easily be updated by pulling in patches from the OS vendor. Web server installations, on the other hand, are more complex, and upgrading them has a much higher potential for running into trouble due to updates of some component, requiring much more testing.

This finding, if it also applies to mail servers in general, indicates that mail servers will be ready for a transition to strict mode for handling the Renego issue earlier than the secure websites will be.

What about other application protocols? The only other protocol that can be used over TLS and that is supported by Opera is IRC, but there may be others supported by other clients. In the case of IRC, my limited information indicates that many of these servers, particularly the secure ones, are located on non-standard ports, although there seems to be a certain convention, but it probably means they will be difficult to discover using anything short of a full portscan.

At present, I am therefore not planning to do any survey of secure IRC servers.

TLS Session resumption

Another interesting thing the prober detected was that very few of the mail servers, just 22.8%, resume TLS sessions (just in case somebody wonders: there is no correlation between this number and the number of Renego unpatched servers; they are just similar). Again, SMTP servers stood out, with just 8.15% that would resume sessions.

As I pointed out in another article, not resuming sessions significantly increases load on the server, something that will particularly be an issue for POP servers, but also IMAP servers, since all clients use multiple connections, and at least one *major* client opens one for each IMAP folder that is checked. SMTP will still be affected by clients, but this depends on how many emails the users send.

What is the reason for this low number of servers that resume sessions? At this time, that would be guessing, but given that the couple of mail server administrators I have been talking to have been unable to find out how to enable it, it could be that this has been left out of email servers, for some reason. What I do know is that the applications based on OpenSSL apparently need to provide a TLS Session cache for the server. Perhaps the email server implementors could post some information about how to enable it?

[Update: Had been using a wrong port for SMTP directly over TLS, removed reference to that port]