August 2013 Web Server Survey

In the August 2013 survey we received responses from 716,822,317 sites, an increase of 18 million. Based on the trends over the last six months, Netcraft expects to see 1 billion responsive sites within the next 18 months.

Apache lost a significant amount of market share this month, tumbling by 5.23 percentage points. Its market share now stands at 46.96%, the lowest since March 2009. This large change was caused by the loss of 28 million Apache sites, a large gain of 26 million sites powered by Microsoft IIS, plus other reasonably significant gains by nginx and Google. Google's growth was primarily due to 3.1 million new sites using Google's App Engine ( infrastructure and 2.7 million new Blogger sites (

The bulk of the changes in Apache and Microsoft web server market share this month can be attributed to a single hosting company: Go Daddy was previously hosting 25 million sites using Apache Traffic Server on Linux, but these are now served by Microsoft IIS 7.5. The machines still exhibit the TCP/IP characteristics of Linux, and are likely reverse proxies, each of which is serving an average of about 150 thousand sites. Apache Traffic Server first appeared at Go Daddy during Netcraft's May survey. At the time, 75% of all sites hosted by Go Daddy were using ATS, which made Go Daddy responsible for hosting 99% of all ATS sites in the world.

Remarkably, this is the first time since December 2009 that Apache has not been used by more than half of the world's websites. During that period, Apache's market share peaked at 66% in July 2011, although its greatest ever market share was observed in November 2005, when it hit 71%.

Despite speculation that the recent PRISM revelations would result in a mass exodus from American data centers and web hosting companies, Netcraft has not yet seen any evidence of this. Within the most popular 10 thousand sites, Netcraft witnessed only 40 sites moving away from US-based hosting companies. Contrary to some people's expectations, 47 sites moved to the US, which actually resulted in a net migration to the US.

This trend is also reflected by the entire web server survey, where a net sum of 270 thousand sites moved to the US from other countries (in total, 3.9 million sites moved to the US, while 3.6 million moved from the US). Germany was the most popular departure country, with nearly 1.2 million sites moving from German hosting companies. This was followed by Canada, where 803 thousand sites hopped across the border to the US.

DeveloperJuly 2013PercentAugust 2013PercentChange
Continue reading

Most Reliable Hosting Company Sites in July 2013

Rank Performance Graph OS Outage
DNS Connect First
1 Swishmail FreeBSD 0:00:00 0.003 0.134 0.076 0.152 0.209
2 ServerStack Linux 0:00:00 0.003 0.096 0.078 0.158 0.158
3 iWeb Linux 0:00:00 0.003 0.146 0.083 0.166 0.166
4 Hyve Managed Hosting Linux 0:00:00 0.006 0.267 0.083 0.166 0.168
5 XILO Communications Linux 0:00:00 0.009 0.230 0.094 0.399 0.561
6 Qube Managed Services Linux 0:00:00 0.012 0.136 0.065 0.132 0.132
7 Virtual Internet Linux 0:00:00 0.015 0.164 0.089 0.383 0.594
8 Datapipe FreeBSD 0:00:00 0.018 0.089 0.031 0.062 0.095
9 New York Internet FreeBSD 0:00:00 0.018 0.142 0.079 0.159 0.491
10 Bigstep Linux 0:00:00 0.018 0.293 0.084 0.174 0.321

See full table

Swishmail had the most reliable hosting company site in July 2013. The New York based company failed to respond to only one of Netcraft's requests during the whole month, and had an average connection time of 0.076s. Swishmail primarily operates as an email hosting provider and uses three different data centers, run by Savvis, Level3 and Globix in New York City. Upstream connectivity is provided by Level3, Savvis, Cogent, AboveNet and Globix.

In second and third place, both also with only one failed request, were ServerStack and iWeb. ServerStack had the most reliable hosting company site during the previous month, and has data centers in New Jersey, San Jose and Amsterdam. iWeb's data centers in Montreal have a total dedicated server capacity of nearly 35,000.

For the second month in a row, none of July's top ten hosting companies were running on Windows operating systems. The most reliable hosting company site, Swishmail, was running on FreeBSD, as were two others sites within the top ten; the remaining seven were running on Linux. In terms of web server software, Apache was used by seven of the top ten sites, while nginx was used by three sites, including Swishmail's.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

Microsoft Achieves World Domination (in OCSP Stapling)

Certificate revocation checking is an essential part of any connection to an SSL site; without it, an attacker can impersonate an SSL site with a compromised certificate until it expires of its own accord — an event which may be 5 years away — even if the issuer of the certificate (the certificate authority, or CA) is made aware of the breach. One of the methods used to check the revocation status, OCSP, requires the browser to make a per-certificate request to the issuing CA as part of the initial connection to an SSL site.

This separate OCSP request can increase the time taken for the browser to connect to an SSL site and imposes a traffic burden on the CA. OCSP stapling is advantageous because it removes the need for a separate request to the CA by bundling the OCSP response with the existing SSL connection.

The proportion of certificates in the July 2013 Netcraft SSL survey served over an SSL connection with a stapled OCSP response.

In the latest Netcraft SSL Survey, more than 22% of certificates were served with a stapled OCSP response. Of those SSL certificates seen with a stapled OCSP response, almost all (96%) were served from computers running Microsoft Windows. OCSP stapling has been enabled by default in IIS since Windows 2008, significantly before its competitors — Apache added support in version 2.4 in February 2012 and nginx added support in version 1.4.0 in April 2013.

Operating System Share
Windows Server 200894.54%
Windows Server 20121.76%

The certificates in the July 2013 Netcraft SSL survey served over an SSL connection with a stapled OCSP response, split by operating system.

More than 99% of the stapled OCSP responses corresponded to a 'good' status, but somewhat surprisingly, there were around 900 responses which corresponded to a revoked status. These include a certificate on a Maybank website (the largest financial institution in Malaysia) and a certificate on the mobile version of, an official US Marine Corps recruitment website. appears to be load balanced across at least two machines, one of which staples a revoked response, the other uses a different non-revoked certificate. in Google Chrome (on Windows) and Safari on iOS6.

Browser support for OCSP stapling is patchy and varies with the operating system. As well as on the server-side with IIS, Microsoft's client-side support for OCSP stapling is good: Internet Explorer supports stapling, as does every other browser tested on Windows except Firefox. Firefox does particularly poorly on all platforms, with no support at all for OCSP stapling in the current release, though support is on its way. Google Chrome uses a patched version of NSS (the same library as Firefox) on Linux which does include stapling support. The upgrade from Opera 12 to Opera 15 on Mac OS X removes support for OCSP stapling, perhaps as a side-effect of the move to WebKit (blink), leaving Mac OS X without support for OCSP stapling when using the latest release of any common browser.

Where OCSP stapling may help the most — on mobile networks where latency may be high — there is no support, at least in conventional browsers which make direct requests. Opera Mini, which uses a proxy to compress responses, does make SSL requests which include a request for an OCSP stapled response, but security conscious users may be reticent to trust their SSL encrypted data to Opera (which proxies SSL connections through its servers) in exchange for OCSP stapling.

Browser/OSWindowsLinuxMac OS XiOSAndroid
Google Chrome 28YesYesNoNoNo
Firefox 22NoNoNoN/ANo
Internet Explorer 10YesN/AN/AN/AN/A
Safari 6NoN/ANoNoN/A
Opera 12YesYesYesN/AN/A
Opera 15YesN/ANoN/AN/A
Opera MiniN/AN/AN/AYesYes
Opera MobileN/AN/AN/AN/ANo

CloudFlare is a vocal supporter of OCSP stapling and claims that stapling can improve the time taken to start an SSL connection by up to 30%. CloudFlare’s implementation of OCSP, though, does not consistently provide a stapled OCSP response. Netcraft took 50 random CloudFlare IP addresses seen in the SSL survey and made 50 sequential requests with OCSP stapling enabled after an initial priming request which was discarded.

The number of CloudFlare IP Addresses responding with OCSP stapled grouped by the request number. 50 IP addresses were connected to with openssl s_client -status, the initial request was discarded and then after a 5 second pause, 50 sequential requests were made.

Fewer than 50% of the CloudFlare IP addresses responded with an OCSP response stapled on the first non-discarded connection attempt. Even after 20 requests, the response rate is not consistent, some IP addresses still fail to staple an OCSP response on each and every SSL connection. This inconsistent behaviour may be down to a number of separate machines responding to the same IP address either in different locations, or behind a load balancer.

OCSP stapling, at least in its current form, does not exempt most browsers from all OCSP requests; even if the OCSP response for the certificate of the SSL site itself is stapled, the OCSP responses from the intermediates certificates — the chain of certificates which link the site’s certificate to a trusted certificate embedded in the browser — are not included. Yngve Pettersen, formerly of Opera, has recently authored RFC 6961 defining a standard which is intended to combat some of the problems with the current generation of OCSP stapling.

July 2013 Web Server Survey

In the July 2013 survey we received responses from 698,823,509 sites, an increase of 25.8M.

Apache and nginx, both open source web servers, have lost market share this month whilst Microsoft gained significantly, up by 2.43 percentage points, to just shy of 20% of worldwide sites. For the second consecutive month, nginx is powering fewer sites than in the previous month's Web Server Survey, which is due, in part, to almost 2M sites moving from nginx and to Apache. Within the million busiest sites, a similar picture emerges: nginx lost over 4,000 busy sites, many of which have moved to Apache.

Windows Azure, Microsoft's own cloud platform, is, as expected, dominated by Microsoft IIS — more than 96% of all sites hosted on the platform are using IIS. Azure is not, however, limited to just the Windows operating system, Linux is also available. This month, Netcraft found 170,000 (13,000 more than last month) sites being served on 18,000 (+1,100) web-facing computers at Azure. Azure had net gains of sites from several of the best known hosting providers including Amazon, Rackspace, SoftLayer, and Go Daddy.

Previous hosting provider Net movement to Microsoft
Go Daddy+594

Sites (hostnames) switching to being hosted at Microsoft from notable providers, June 2013 to July 2013

Amidst continuing uncertainty over the scale of both PRISM and related surveillance programmes, some people have expressed concerns about hosting personal information in the United States. Currently, the United States is a Safe Harbour for European data, which allows American businesses to comply with European data protection legislation. With the European Commission seeking clarification from the US Government regarding the surveillance programme, and hosting companies selling guaranteed European hosting as a feature, the recent revelations might lead to international businesses moving away from US-based hosting providers.

Currently, almost one third of the world's sites are hosted in Europe but the United States has a near majority of 49.5% of all sites. Looking at the top 5 European TLDs by the number of sites (.de, .pl, .nl, .fr, and .uk) only 7% are hosted in the United States and the vast majority are hosted in their home country — for example, 90% of sites within the .de TLD are hosted in Germany — with the exception of the United Kingdom, which hosts 56% at home and almost 20% in the United States. Additionally, the use of open source software is significantly more prominent in Europe: more than 80% of European hosted sites use Apache or nginx and less than 5% use Microsoft IIS. The United States, on the other hand, has more than 25% of its sites running on Microsoft IIS while Apache and nginx have a slim majority of just 53%.

Last month, Netcraft wrote about the meteoric rise of DigitalOcean, a US-based cloud hosting provider. The service, which has been attracting users with competitive pricing and rapid deployment (within a minute), has seen strong growth again this month, the number of web-facing computers is up 31% since last month. Only 7% of the web-facing computers at DigitalOcean are based in their Dutch data centre, down (as a proportion) from 31% at the beginning of this year — perhaps caused by a shortage of available IP addresses.

Previous hosting provider Net movement to DigitalOcean
Shore Network Tech (Linode)+824

Sites (hostnames) switching to being hosted at DigitalOcean from notable providers, June 2013 to July 2013

DeveloperJune 2013PercentJuly 2013PercentChange
Continue reading

Most Reliable Hosting Company Sites in June 2013

Rank Performance Graph OS Outage
DNS Connect First
1 ServerStack Linux 0:00:00 0.007 0.089 0.073 0.146 0.146
2 Codero Linux 0:00:00 0.010 0.234 0.084 0.266 0.528
3 Swishmail FreeBSD 0:00:00 0.014 0.133 0.070 0.137 0.184
4 Virtual Internet Linux 0:00:00 0.014 0.162 0.074 0.329 0.502
5 Datapipe FreeBSD 0:00:00 0.017 0.083 0.018 0.037 0.057
6 Bigstep Linux 0:00:00 0.017 0.289 0.072 0.147 0.228
7 Midphase Linux 0:00:00 0.017 0.246 0.111 0.225 0.380
8 Linux 0:00:00 0.017 0.209 0.129 0.214 0.517
9 Memset Linux 0:00:00 0.021 0.111 0.074 0.146 0.291
10 Iomart Linux 0:00:00 0.021 0.115 0.088 0.181 0.339

See full table

ServerStack had the most reliable hosting company site in June, with only two failed requests. ServerStack provides managed dedicated hosting from data centres in New Jersey, San Jose, and Amsterdam, and counts amongst its clients high-traffic sites such as MTV and academic publisher Elsevier. Over the eight months Netcraft has been monitoring ServerStack's performance, it has appeared in the top 10 five times and been the most reliable hosting company site twice.

Codero and Swishmail took second and third place respectively. Both companies had 100% uptime and just two failed requests separate the top three companies. Both Codero and Swishmail are based in the United States: Codero has a presence in Virginia, Illinois and Arizona, whilst Swishmail operates out of three New York data centres.

Bigstep, which focuses on providing hosting infrastructure for big data companies, started being monitored three months ago and has maintained a 100% uptime record thus far.

For the first time since May 2012, none of the companies in the top 10 Most Reliable Hosting Company Sites were running a version of Windows Server. ServerStack runs Linux, as do seven other hosting companies in the top 10. FreeBSD is used by the remaining two: Datapipe and Swishmail.

Netcraft measures and makes available the response times of around forty leading hosting providers' sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.

From a customer's point of view, the percentage of failed requests is more pertinent than outages on hosting companies' own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.

Information on the measurement process and current measurements is available.

SSL: Intercepted today, decrypted tomorrow

[September 2013: The Netcraft extension — for Firefox, Google Chrome, and Operanow displays whether or not PFS is supported]

Millions of websites and billions of people rely on SSL to protect the transmission of sensitive information such as passwords, credit card details, and personal information with the expectation that encryption guarantees privacy. However, recently leaked documents appear to reveal that the NSA, the United States National Security Agency, logs very high volumes of internet traffic and retains captured encrypted communication for later cryptanalysis. The United States is far from the only government wishing to monitor encrypted internet traffic: Saudi Arabia has asked for help decrypting SSL traffic, China has been accused of performing a MITM attack against SSL-only GitHub, and Iran has been reported to be engaged in deep packet inspection and more, to name but a few.

The reason that governments might consider going to great lengths to log and store high volumes of encrypted traffic is that if the SSL private key to the encrypted traffic later becomes available — perhaps through court order, social engineering, successful attack against the website, or through cryptanalysis — all of the affected site’s historical traffic may then be decrypted at once. This really would open Pandora’s Box, as on a busy site a single key would decrypt all of the past encrypted traffic for millions of people.

There is a defence against this, known as perfect forward secrecy (PFS). When PFS is used, the compromise of an SSL site's private key does not necessarily reveal the secrets of past private communication; connections to SSL sites which use PFS have a per-session key which is not revealed if the long-term private key is compromised. The security of PFS depends on both parties discarding the shared secret after the transaction is complete (or after a reasonable period to allow for session resumption).

Eavesdroppers wishing to decrypt past communication which has used PFS face a daunting task: each previous session needs to be attacked independently. Even knowing the long-term private key does not help as the session key is not available by simple decryption. Conversely, when SSL connections do not use PFS, the secret key used to encrypt the rest of the session is generated by the SSL site and sent encrypted with the long-term private-public key pair. If this long-term private key is ever compromised all previous encrypted sessions are easily decrypted.

Perfect forward secrecy was invented in 1992, pre-dating the SSL protocol by two years, and consequently one might reasonably have expected that SSL would have made operational use of PFS from the outset. Nevertheless, almost twenty years later, PFS usage is not used by the majority of SSL sites.

The use of PFS is dependent on the negotiation between the browser and the web site successfully agreeing on a PFS cipher suite. One might reasonably expect browsers to do all they can to support PFS cipher suites as PFS confers an advantage in privacy for the browser’s user community, and any PFS performance disadvantages may only be a serious issue at the larger scales found on the server-side. On the other hand, there are only a small number of browsers in widespread use, and if a government wished to maximise its influence in restricting the use of PFS in order to facilitate decryption of recorded encrypted transactions it would start with the web browsers.

Browser support for PFS

Netcraft has tested the cipher suite selection of five major browsers — Internet Explorer, Google Chrome, Firefox, Safari and Opera — against 2.4 Million SSL sites from Netcraft's June SSL Survey. The support for PFS varied significantly between browsers: only a tiny fraction of Internet Explorer's SSL connections operated with PFS; whereas Google Chrome, Opera and Firefox were protected for approximately one third of connections. Safari fared only a little better than Internet Explorer.

The actual cipher suites used when connecting to 2.4 Million SSL sites with the cipher suite settings extracted from each browser. *Opera does not include its TLS 1.2 cipher suites.

Internet Explorer does particularly poorly as it does not support any cipher suite that uses both RSA public keys and non-elliptic-curve DH key exchange, which includes the most popular PFS cipher suite. The PFS cipher suites that IE does support have a lower priority than some of the most commonly supported non-PFS cipher suites. Curiously, IE does support DHE-DSS-AES256-SHA, which uses the rarer DSS authentication method, but not the very popular DHE-RSA-AES256-SHA.

Browser priorityCipher SuiteReal-world usage in SSL Survey

Internet Explorer 10's cipher suite ordering and the actual negotiated cipher suite in Netcraft's SSL survey. PFS cipher suites are highlighted in bold and green.

Safari supports many PFS cipher suites but non-elliptic-curve cipher suites are used only as a last resort. As several non-PFS ciphers have a higher priority, web servers respecting the browser's preferences will end up selecting a non-PFS cipher suite even if the web server itself does support some (non elliptic-curve) PFS cipher suites.

Chrome, Firefox, and Opera all do better, preferring PFS cipher suites ahead of non-PFS at any given strength level — for example Opera's preference list starts: DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, AES256-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, AES128-SHA. Netcraft did not include any cipher suites only present in TLS 1.2 which includes many of Opera's PFS cipher suites, so the results for Opera form a lower bound on the number of SSL sites using PFS with Opera.

None of the browsers change their user interface perceptibly to reflect the presence of PFS akin to the way EV certificates are treated to a green address bar. Google Chrome and Opera show the cipher suite used (in popups or dialog boxes), but they rely on a user understanding the implications of wording such as "[..] ECDHE_RSA as the key exchange mechanism".

Web server support for PFS

Despite a browser's best efforts to prefer PFS cipher suites, the key exchange method used is selected by the server and it may either not support any PFS cipher suites or it may prefer to use an alternative cipher suite (and perhaps reasonably so for performance reasons). The use of the Diffie-Hellman key exchange does impose a performance penalty as there is additional computation required to derive the secret key.

Using any browser's cipher suite preference order, at least two-thirds of the SSL connections made in the Netcraft SSL survey did not use a cipher suite with PFS at all.

Connections to 2.4 Million SSL sites in the SSL survey, once for each browser, split by the web server vendor

nginx, an open-source web server originally written by Russian Igor Sysoev, uses strong cipher suites by default, which has caused some to comment on nginx's SSL performance. With the exception of Internet Explorer and Safari, more than 70% of SSL sites using the web server selected a PFS cipher suite when visited with a modern browser.

The usage of PFS amongst SSL sites using Apache is also fair, around two-thirds of the SSL sites it serves use a PFS cipher suite when visited in Firefox, Chrome, or Opera. Conversely, Microsoft's support for PFS cipher suites is notably lacking; both Microsoft IIS and Internet Explorer only rarely use PFS cipher suites — when used together only 111 (0.01%) of SSL connections between IIS and IE used PFS.

Whilst Google uses PFS cipher suites for some Google SSL sites, it appears that many SSL sites hosted on Google App Engine do not.

How is this related to PRISM?

WebsiteInternet ExplorerGoogle ChromeFirefoxSafariOpera

The negotiated cipher suite for a selection of SSL sites belonging to companies implicated in the PRISM programme. PFS cipher suites are highlighted in bold and green.

Many SSL sites of those companies implicated in the PRISM programme do not use PFS cipher suites when visited in any of the major browsers. Google, however, does use a PFS cipher suite in most browsers, with the notable exception of Opera. If PRISM operates by examining SSL traffic, which has been said to be fairly unlikely given its quoted $20M cost, all of the traffic to these SSL sites (except for Google) could have been compromised if the NSA had access to the private key.

Some other noteworthy SSL sites

WebsiteInternet ExplorerGoogle ChromeFirefoxSafariOpera

The negotiated cipher suite for a selection of SSL sites. PFS cipher suites are highlighted in bold and green.

DuckDuckGo, a search engine, has been prominent in the media since the start of the Snowden revelations due to its privacy policy which promotes anonymity. If the private key used by DuckDuckGo were ever compromised — for example if one of their servers were seized — all previous searches would be revealed where logged traffic is available. DuckDuckGo may be a particularly interesting target for the NSA due to its audience and the small volume of traffic (as compared to Google).

CloudFlare has taken a similar approach to Google using ECDHE RC4 or AES cipher suites, but also leave Opera users without the protection of PFS. One of CloudFlare's options for SSL deployment is 'flexible' SSL which encrypts traffic from the browser to CloudFlare but if the content is not returned from its cache, the connection from CloudFlare to the original website is made without SSL. Rather than attempting to decrypt the encrypted content it may be easier to intercept unencrypted traffic between CloudFlare and the original website.

Mega does not use PFS cipher suites, perhaps a risky move given the history of raids on Megaupload's servers by the US Government. With physical access to the servers, it is not implausible that the private keys of any server could be extracted, even if it is from non-persistent memory.


Conspiracy theorists may be unsurprised that:

  • Microsoft’s support for PFS is conspicuous by its absence across Internet Explorer, IIS, and some of its own web sites. Apple’s support for PFS in Safari is only slightly better.
  • Russia, long-time target of US spies, is the home of the developer of nginx, the web server which uses PFS most often.
  • Almost all of the websites run by companies involved in the PRISM programme do not use PFS.

Whilst conspiracy theorists may delight in speculating on the reasons why PFS isn't ubiquitous, one reason may be web sites' (bona fide) performance concerns: Mavrogiannopoulos reports up to a 3x performance penalty starting an SSL connection using DHE-RSA instead of plain RSA. The lack of clear in-browser notifications of the use of PFS cipher suites may persuade popular SSL sites to forgo the protection PFS offers, which typical users do not notice, to instead improve the web site's performance, which typical users do notice.

Without the support of two major browsers and major websites most internet users are missing out on the security benefits of perfect forward secrecy. Without the protection of PFS, if an organisation were ever compelled — legally or otherwise — to turn over RSA private keys, all past communication over SSL is at risk. Perfect forward secrecy is no panacea, however; whilst it makes wholesale decryption of past SSL connections difficult, it does not protect against targeted attack on individual sessions. Whether or not PFS is used, SSL remains an important tool for web sites to use to secure data transmission across the internet to protect against (perhaps all but the most well-equipped) eavesdroppers.

It should be noted that the US Government, along with many others governments, can issue any SSL certificate of its choosing — albeit at the risk of breaking the rules of the programme and at the risk of detection by alert users and by Google (for certain SSL sites). The scale at which an active attack is practical and unlikely to be detected, however, would be significantly smaller than that of a passive eavesdropper exploiting the lack of PFS.

More detail on PFS negotiation

The cipher suite selected for the SSL connection depends on an agreement between the browser and the SSL site. Both browsers and SSL sites can each have independent preference lists for SSL cipher suites. During the handshake the browser sends a ClientHello message which contains an ordered list of all supported cipher suites in preference order. The SSL site can either select the first cipher on that list which it also supports or it can use override the clients preference list with its own. As illustrated in the above diagram, either Cipher A (if the browser's preference order is respected) or Cipher C (if the website's preference order is respected) is used for the connection depending on the settings of the SSL site.

Illustration of cipher suite selection algorithms.

Diffie-Hellman key exchange (DH) and variants of it are used to negotiate a per-session shared secret key between two parties without ever transmitting the key itself. The per-session key can be discarded after the session has terminated (and after a suitable time period for renegotiation) leading to the ephemeral property which PFS relies upon. The security of Diffie-Hellman relies on the difficulty of the discrete logarithm problem to exchange DH public keys whilst making it difficult for an eavesdropper to determine the resulting shared secret. SSL cipher suites support both conventional ephemeral Diffie-Hellman key exchange (often referred to as EDH or DHE) and ephemeral elliptic curve Diffie-Hellman (ECDHE) which uses a similar scheme but relies on the difficulty of the elliptic curve Discrete Logarithm problem. Elliptic curve-based DHE key exchange despite being faster is supported by fewer SSL sites than conventional DHE.