Developers › Security Group blog
How secure is the secure web? SSL/TLS-server stats, part 1
[Audun Mathias Øygard works with data analysis and statistics in the Products group of Opera Software, mostly with user numbers and other interesting Opera browser related numbers. -yngve]
We have some interesting numbers to share! In between other tasks, the latest weeks (and months) have been spent building a "TLS prober", that is, a system that probes TLS/SSL-servers around the world and collects their vital statistics. We will present some of the most interesting findings here in the coming weeks and months. But first, let's explain the background for the creation of this prober:
As those who are following this blog know, a major SSL/TLS vulnerability linked to the renegotiation part of the protocol was publicized last November. A recommended extension that fixes this vulnerability has already been published by the IETF, and we have also implemented support for this extension in Opera 10.50 on desktop. However, this is not enough, as an attack on the renegotiation-vulnerability may also happen on the server side. Therefore, we need all servers offering secure connections to be patched to support this new extension as well.
Strictly speaking, a server that has not yet been patched to support the recommended extensions can no longer provide a secure connection, even if you connect with a browser that has implemented this fix. It is, therefore, our opinion that users should at least be warned if servers they make secure connections with are not patched for this issue, and, in time, even denied access altogether, as such a server can-not deliver an entirely secure connection, even though it poses as if it can.
In Opera 10.50 we implemented a setting in security preferences that, when enabled, will warn about all sites that have not been patched against the renegotiation vulnerability. This setting should preferably be enabled by default as soon as possible. However, since the recommended extension to the protocol was just published, the amount of servers that have implemented a patch is close to 0%. If we turned on the warning now, we would therefore deliver a warning at every HTTPS-connection, which would be a major annoyance for most users. Therefore, the question is exactly when we can enable this warning by default, without annoying you, our users, too much.
To make this decision, we must know approximately how large a part of secure servers on the Web have been patched, which is not easily available information. Therefore we have decided to set up a system that crawls a list of secure servers, probing each for various information, such as whether the renegotiation patch has been implemented. This enables us to keep track of how many servers that have implemented the patches over the coming months, to decide when this warning should be turned on by default, and to determine when secure connections with unpatched servers should be disabled altogether.
We have already done our first probes of approximately 400 000 secure servers (see how we created this list below). Predictably, the statistics for patched servers looks like this:
To be more precise, we found 8593 patched servers on our last probe, done on the 30th of March. This is up from 151 patched servers four weeks earlier, so we are definitely seeing some positive movement.
We intend to follow and publish these statistics until we find it practical to change our default settings for unpatched servers, hopefully within less than 12 months. However, it is also possible for you to help speed up this process by pushing server-owners to implement patches. You can find out if one of the sites you regularly connect to with a secure connection (for instance, your bank) has applied a patch. If they haven't, you could contact them and ask them to update their servers.
In Opera 10.52 (download latest version here), information about whether the server has implemented the new renegotiation extension is available in the security information dialog, found by clicking the padlock icon on the right end of the address field when you are on a secure server:
If the site has not been patched, you will see the text "The server does not support secure TLS renegotiation. The site owner should upgrade the server." as here:
Phonefactor has created a list of statuses of patches across various vendors , which can be used to check whether patches for a specific vendor has been published.
Apart from checking how many secure servers have implemented the renegotiation patch, the probing also enables us to look at other statistics that might be of interest to the security community, such as which versions of SSL/TLS protocols most secure servers out there support:
It's good to see that most servers support TLS, but the support for versions 1.1 and 1.2 is disappointing - TLS v1.1 was released as far back as in 2006, and TLS v1.2 was released in August 2008. A closer look revealed that the only site in our dataset that supported TLS v1.2 was in fact www.mikestoolbox.net, which some of you may recognize as a TLS v1.2 testserver. 
The list of SSL-enabled servers used here was fetched mostly from the list of Alexa top million sites last December, where we did some clever probing to discover whether any of these sites also supported secure connections with SSL/TLS. While there are a lot of complaints about the ranking of the top sites on Alexa, it is expected that the top million visited sites will give a reasonably representative view of the most used sites on the internet. We also fetched some sites from a crawl of the Open Directory Project . In all, we discovered around 400 000 unique servers that offered secure connections with at least SSL v3 or TLS.
Although it's hard to know the true size of the Internet, Netcraft reported early last year that they got responses from around 2.7 million SSL/TLS-servers worldwide. It's reasonable to assume that this has grown to a bit above 3 million this year - if this truly is most of the servers worldwide, our list includes over 10% of these. This should give a reasonably representative picture of the status of TLS/SSL-servers worldwide, however, the sites that are in the Alexa top million list might be more up to date than the rest of sites on the Web (since popular sites usually are better maintained), so our statistics might be slightly biased towards more up to date sites.
We haven't decided exactly when the next report will be out, although it shouldn't be too long from now. If we see big changes in how many servers are patched, we might decide to report more often.
Other issues we may look at in further reports are:
To be more precise, we found 8593 patched servers on our last probe, done on the 30th of March. This is up from 151 patched servers four weeks earlier, so we are definitely seeing some positive movement.
We intend to follow and publish these statistics until we find it practical to change our default settings for unpatched servers, hopefully within less than 12 months. However, it is also possible for you to help speed up this process by pushing server-owners to implement patches. You can find out if one of the sites you regularly connect to with a secure connection (for instance, your bank) has applied a patch. If they haven't, you could contact them and ask them to update their servers.
In Opera 10.52 (download latest version here), information about whether the server has implemented the new renegotiation extension is available in the security information dialog, found by clicking the padlock icon on the right end of the address field when you are on a secure server:
If the site has not been patched, you will see the text "The server does not support secure TLS renegotiation. The site owner should upgrade the server." as here:
Phonefactor has created a list of statuses of patches across various vendors , which can be used to check whether patches for a specific vendor has been published.
Apart from checking how many secure servers have implemented the renegotiation patch, the probing also enables us to look at other statistics that might be of interest to the security community, such as which versions of SSL/TLS protocols most secure servers out there support:
| Highest supported SSL-version | |
|---|---|
| SSL v3.0 | 1.6% (6177) |
| TLS v1.0 | 98.4% (387979) |
| TLS v1.1 | 0.0% (95) |
| TLS v1.2 | 0.0% (1) |
The list of SSL-enabled servers used here was fetched mostly from the list of Alexa top million sites last December, where we did some clever probing to discover whether any of these sites also supported secure connections with SSL/TLS. While there are a lot of complaints about the ranking of the top sites on Alexa, it is expected that the top million visited sites will give a reasonably representative view of the most used sites on the internet. We also fetched some sites from a crawl of the Open Directory Project . In all, we discovered around 400 000 unique servers that offered secure connections with at least SSL v3 or TLS.
Although it's hard to know the true size of the Internet, Netcraft reported early last year that they got responses from around 2.7 million SSL/TLS-servers worldwide. It's reasonable to assume that this has grown to a bit above 3 million this year - if this truly is most of the servers worldwide, our list includes over 10% of these. This should give a reasonably representative picture of the status of TLS/SSL-servers worldwide, however, the sites that are in the Alexa top million list might be more up to date than the rest of sites on the Web (since popular sites usually are better maintained), so our statistics might be slightly biased towards more up to date sites.
We haven't decided exactly when the next report will be out, although it shouldn't be too long from now. If we see big changes in how many servers are patched, we might decide to report more often.
Other issues we may look at in further reports are:
- How many servers only support 128-bit ARC4-RSA/MD5?
- How many servers use RSA keys with less than 900 bits?
- How many sites use revoked certificates?
- How many sites use expired certificates?
- How many sites use certificates that are self-signed or use an unknown certificate authority?
- How many sites use certificates that are not issued for the domain they are representing?
- ++
Readers' comments 24
Left under the original article, as archived.
About this article
| Published in | Security Group blog |
|---|---|
| Date | April 6, 2010 |
| Author | Audun Mathias Øygard |
| Tags | statistics, TLS, SSL, Opera, TLS prober, browser, vulnerability fix, Security, 512-bit, cabforum, Certificates, MD5 |
| Original | Internet Archive |
TamilTuesday, April 6, 2010 12:07:55 PM
Charles SchlossTuesday, April 6, 2010 1:00:00 PM
GalileoTuesday, April 6, 2010 1:09:41 PM
Terry PWednesday, April 7, 2010 6:24:56 AM
Server Version: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8n mod_bwlimited/1.4 PHP/5.2.13
The Windows version of Opera 10.51 reports this incorrectly as: The server does not support secure TLS renegotiation.
LATER: I have now tested the Linux version of Opera 10.52 build 6302 which correctly reports the server as patched.
Audun Mathias ØygardWednesday, April 7, 2010 9:20:31 AM
UPDATE:
It seems there was a bug in the indicator for secure renegotiation, which causes all servers to be shown as not supporting secure renegotiation, regardless of whether they do or not.
Yngve Nysæter PettersenWednesday, April 7, 2010 9:46:14 AM
iedee cosseWednesday, April 7, 2010 7:53:59 PM
Fred KimballSunday, April 11, 2010 1:03:26 AM
Charles SchlossWednesday, May 5, 2010 4:41:55 PM
CoreRouterFriday, May 7, 2010 9:31:42 AM
How can i supress the warning. I am kinda miffed, that Opera thinks my server is insecure, while IE and FF are happily showing the padlock.. Opera is just showing a question mark :-(
Yngve Nysæter PettersenFriday, May 7, 2010 9:58:58 AM
There is no way for a client to reliably tell that the server have disabled renegotiation, and attacker could just fake the response (cut the connection) to that test.
The indication (which work correctly in 10.52 and later) in Opera is about whether or not the server support the TLS Renegotiation Information (RI) Extension, as that is the only way a client can tell that the server is safe to renegotiate with. Since your server has not been updated to support the RI extension, that is what Opera will indicate.
OpenSSL 0.9.8m (released in late February) or later contain the RI extension support.
Mele20Tuesday, May 11, 2010 10:50:43 AM
My fourth bank, First Hawaiian Bank (www.fhb.com) does NOT show a lock! There is a question mark where the lock should be in the address bar. When I click on the question mark, Opera 10.53 tells me:
Site not secure.
The connection to www.fhb.com is not secure etc.
This server does not support secure TLS Renegotiation, etc.
The certificate for www.fhb.com is from Verisign and is perfectly fine. If I visit the site via Firefox or IE there is no problem. The lock is shown and the certificate is valid. If I visit the site on Opera 1010 I get a lock in the address bar.
Opera 10.53 appears to have a bug that has NOT been fixed regarding this indicator.
Yngve Nysæter PettersenTuesday, May 11, 2010 10:58:28 AM
Mele20Tuesday, May 11, 2010 12:08:03 PM
https://fhbonline.fhb.com does show the padlock. So, maybe you are right. The main site, before you login to online banking is supposed to be secure but maybe something didn't load, etc. like you suggested.
I'll call them probably not until Wednesday though. They may just say that Opera is not supported but we'll see. They may not have even heard of Opera. It may give me a chance to educate them about Opera.
Charles SchlossTuesday, May 11, 2010 1:38:59 PM
Originally posted by Mele20:
Its a tls renegotiation issue, if you click the question mark it tells you what failed
Yngve Nysæter PettersenTuesday, May 11, 2010 3:15:43 PM
Charles SchlossTuesday, May 11, 2010 6:21:55 PM
Mele20Wednesday, May 12, 2010 10:03:23 AM
I have noticed something interesting with fhb.com and some other secure sites that is different with Opera 10.53 than with earlier versions and also different from other browsers at the same sites. For instance, at fhb.com, I get a popup from Opera as the site loads asking what to do about a cert from GoDaddy for stats.fhb.com. I have Opera set to alert me to any sites using GoDaddy certs. What I find interesting is that I did not get that alert from earlier versions of Opera and do not get the alert from other browsers. I can reject the cert and the site still loads with the padlock.
I am assuming Opera 10.53 is simply giving me better information about the certs than earlier versions and more information than I get with other browsers. I had no idea fhb was using a cert from GoDaddy (at least it isn't from Comodo).
Mele20Wednesday, May 12, 2010 10:13:03 AM
caminadaMonday, June 7, 2010 11:50:29 AM
Is this check really working?
Yngve Nysæter PettersenMonday, June 7, 2010 2:39:45 PM
Is the server accessible publicly? (You can PM me with URL)
caminadaWednesday, June 9, 2010 12:24:27 PM
The tool works correctly - the problem was on server-side because openssl was compiled with the flag "-no-tlsext". A re-compile fixed the problem.
adispyThursday, September 30, 2010 7:28:05 AM
thanks
Yngve Nysæter PettersenThursday, September 30, 2010 9:02:09 AM
See http://www.microsoft.com/technet/security/bulletin/MS10-049.mspx for more details.