SSL Certificate Authorities (CAs) are responsible for issuing the SSL certificates which are used to protect billions of secure transactions across the internet against eavesdroppers and impersonators. The CA/B forum — a group of CAs and browser vendors — drew up the Baseline Requirements in 2011 outlining a set of minimum standards to which all CAs should operate.
Since the "effective date" of the document, 1st July 2012, compliance with the Baseline Requirements has been mixed — Netcraft has previously discovered non-compliant certificates, including short RSA public keys and irrevocable certificates. More than a year on and several months after Mozilla incorporated the Baseline Requirements into its CA policy (albeit with a transition period allowed) CAs are still issuing non-compliant certificates.
By examining the certificates found in Netcraft's SSL Survey and evaluating them against a small subset of rules extracted from the Baseline Requirements document, Netcraft found more than 2,500 non-compliant certificates. The non-complaint certificates fall into one or more of the categories described below: some of the problems are serious security vulnerabilities, and others are less critical but are still violations of the Baseline Requirements.
- Short RSA public key — the shorter a public key is; the easier it is for an attacker (such as the NSA) to brute-force the secret private key, and hence decrypt communication. NIST recommended that certificates should not use RSA public keys shorter than 2048 bits after December 2013 and the CA/B forum imposes the same rule.
- Missing OCSP URL — OCSP is one of the two available revocation mechanisms available to CAs to disable the certificate after it has been issued. As web-browser support for certificate revocation varies, non-EV certificates without an OCSP URL are effectively irrevocable in Firefox. Without the ability to revoke certificates, if the certificate were ever to be compromised — by criminals or government agencies — it could be used for up to five years. The Baseline Requirements do allow certificates to omit the OCSP URL if and only if they are used on "high traffic" websites and the website staples the OCSP response to the TLS handshake — none of the websites with missing OCSP URLs highlighted here did so.
- SAN extension — the Baseline Requirements document discourages the use of the Subject Common Name field to contain the hostname for which the certificate is valid. Instead, the Subject Alternative Name extension should be used and it must contain at least one record. Additionally, any hostname in the Subject CN field must also be duplicated in the SAN extension — a multi-domain certificate intended for www1.example.com and www2.example.com must contain both in the SAN extension and at most one in the Subject CN (for backwards compatibility).
- Validity Period — as of the effective date, the Baseline Requirements limit the maximum validity period of a certificate to 5 years (60 months). Whilst exceeding this validity period constraint isn't itself a security problem it slows downs the pace of change within the industry — with a shorter maximum validity period, browsers can rely on legacy behaviour disappearing and can remove insecure functionality more rapidly.
A short key warning for a 512-bit certificate in Google Chrome. This type of warning is proposed to be applied to certificates violating the maximum validity period.
Several large CAs have issued non-compliant certificates since July 2013, a year after the original deadline, including Symantec, Go Daddy, and Verizon Business.
- Symantec — a BMW certificate issued by TC Trust Center (a Symantec company) is missing an OCSP URL and does not include a stapled OCSP response, making it irrevocable in Firefox. An SSL certificate used for online banking was issued by VeriSign on August 2nd 2013 without the required SAN extension.
- Verizon Business — a certificate issued by Etisalat (a UAE-based telecoms provider which operates a Verizon Business signed sub-CA) for ADCO, an onshore oil drilling company, violates a number of Baseline Requirements: it has a short RSA key valid after 31st December 2013, it has no OCSP URL and it does not have the mandatory SAN extension. Etisalat has previously been associated with SSL interception. Cybertrust, operated directly by Verizon Business, has also issued more than its fair share of non-compliant certificates including certificates belonging to Target [Short Key, no OCSP URL], the US Dept. for Homeland Security [no SAN, no OCSP URL], and American Express [an EV certificate without an OCSP URL!]. A number of other sub-CAs signed by Verizon Business have issued non-compliant certificates including Microsoft [missing SAN, no OCSP URL] and Vodafone [missing SAN].
- SwissSign — Nestlé, a customer of SwissSign with its own intermediate certificate, has issued non-compliant certificates including: those missing SAN records and OCSP URLs.
- Go Daddy — a significant number of Go Daddy certificates exceed the maximum permitted validity period of 5 years. These certificates are likely "re-issued" (the meaning of which is debated by Google, see below) and otherwise do not obviously violate the Baseline Requirements. Go Daddy have proposed a modification to the Baseline Requirements to allow such re-issued certificates to be exempt from maximum validity period constraints.
Google Chrome, in the first quarter of 2014, will reject all certificates issued after the effective date, 1st July 2012, which violate the maximum validity period (60 months). A number of CAs have issued such certificates, often as part of a re-issuance process, which Google deems to be non-compliant with the Baseline Requirements.
In the September 2013 SSL Survey, using the criteria from the proposed Google Chrome patch, Netcraft found 3,243 certificates which will be considered invalid in Google Chrome as a result of this change. Go Daddy issued over three-quarters of these certificates (2,498) and Comodo also issued a significant number (606). The longest-lived non-compliant certificate issued by a member of the CA/B Forum and discovered by the SSL Survey has a validity period of over 82 months.
Furthermore, Google's technical enforcement is set to get tougher: Ryan Sleevi has stated that certificates with short public keys – that is, RSA public keys shorter than 2048 bits expiring after 31st December 2013 are “next up” on Google’s list. Google's proposal to use the original July 2012 date as a threshold for enforcement isn't popular with some of the CAs in the CA/B forum: GlobalSign and Comodo have argued that such technical constraints should only be enforced for certificates issued after the announcement.
Despite Google's aggressive stance, many of Google's own certificates did not comply with some of the Baseline Requirements: in the September 2013 Netcraft SSL survey, almost 500 Google certificates did not contain a URL to an OCSP responder or include a stapled OCSP response (making the certificates irrevocable in Firefox). Since the survey ran in mid-August, a large number of Google's certificates have been replaced and now contain an OCSP URL, but a few non-compliant certificates are still in use including one on Zagat.com. The Zagat.com certificate also has an incomplete SAN record (it does not contain the hostname from the Subject Common Name field).
Netcraft has added a Perfect Forward Secrecy (PFS) indicator to the Netcraft Extension for Firefox, Chrome and Opera. This lets users see which websites would allow encrypted traffic to be decrypted en mass at a later date if the site's private key were to be compromised — a danger previously highlighted by Netcraft in June.
PFS, when implemented correctly, ensures that if the long-term private key of a site served over SSL is compromised, historical encrypted traffic cannot be decrypted in bulk. Instead, an eavesdropper would have to break each individual connection independently, which would be incredibly time consuming.
With the recent revelations from Edward Snowden that the NSA is able to read encrypted internet traffic, PFS support is very desirable for privacy-conscious internet users, particularly in countries that also have key disclosure laws.
Currently, most of the major web browsers make it difficult to tell whether or not a website supports PFS. For example, Chrome, Opera 15, and Internet Explorer display information about the current cipher suite in a pop-up, but checking for PFS support relies on in-depth knowledge. Firefox and Opera 12 display part of the cipher suite in their user interfaces; however, they crucially lack the key exchange mechanism, which means it is not possible for the user to tell whether the site supports PFS. Safari fares the worst, as it does not display any information at all about the current cipher suite.
The Netcraft Extension — which blocks phishing attacks and displays metadata about visited websites — now clearly indicates whether the site you are visiting supports PFS. This is displayed in the user interface as a green tick if the site supports PFS, and a red cross if it does not. In addition, in both Chrome and Opera, a small indicator is displayed beside the Netcraft badge when visiting an SSL site which does not support PFS.
The following screenshots show the PFS indicator in the Netcraft Extension when visiting the DuckDuckGo search engine, which enabled the use of PFS cipher suites after the lack of PFS was highlighted in Netcraft's previous analysis of PFS support.
PFS indicator in the Netcraft Extension for Google Chrome™
(The Opera version looks similar)
PFS indicator in the Netcraft Extension for Firefox
The Netcraft Extension is available for Firefox, Chrome and Opera, and can be downloaded from toolbar.netcraft.com. More information about the PFS indicator can be found on the Netcraft Extension FAQ page.
Note: The new version of the Firefox extension is currently awaiting approval from Mozilla; however, it can be manually installed from the version history page by selecting version 1.8.1.
Network Solutions allowed a fraudster to register a deceptive domain name earlier this week: secure-chaseonline.com. Network Solutions also issued a valid SSL certificate for the domain, which was used for a phishing attack which targeted customers of Chase Bank.
Phishing attack targeting Chase bank on secure-chaseonline.com
The phishing site added further credibility to the attack by using an encrypted HTTPS connection. The fraudster obtained a domain-validated SSL certificate from Network Solutions, and, as with the domain, it was valid for one year from 3rd September 2013.
The SSL certificate used on secure-chaseonline.com
Although opportunities were missed to prevent the suspicious domain name being registered and the corresponding SSL certificate being issued, the certificate used by the site does at least support OCSP, which can allow the issuer to instantly revoke the certificate. However, the efficacy of this mechanism largely depends on which browser the victim is using, and how it has been configured. For example, Firefox — which does performs OCSP checks by default — will only display content from https://secure-chaseonline.com if the certificate has not been revoked. Google Chrome, on the other hand, does not perform such checks by default (for non-EV certificates).
However, as Network Solutions was also the registrar of the domain, it would have been more effective to simply suspend the domain, which is what appears to have happened yesterday:
No match for "SECURE-CHASEONLINE.COM". >>> Last update of whois database: Thu, 05 Sep 2013 12:56:58 UTC <<<
The fraudulent SSL certificate was later revoked — the certificate's serial number can be found on Network Solutions' certificate revocation list at http://crl.netsolssl.com/NetworkSolutionsDVServerCA.crl
The CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates [PDF] says that certificate authorities SHALL subject high risk requests — which includes names at high risk of being used in a phishing attack — to further scrutiny prior to issuance. Netcraft's Domain Registration Risk service is ideal for both domain registrars and certificate authorities, as it judges the likelihood of a new domain being used for fraudulent activities. It identifies domains which are deceptively similar to legitimate websites run by banks and other institutions that are commonly targeted by phishing attackers.
While some phishing attacks can be identified prior to domain registration or SSL certificate issuance (such as the one described above), a significant proportion of phishing attacks make use of compromised web sites (often exploiting vulnerabilities in commonly deployed software platforms, such as WordPress). Netcraft can alert registries, SSL certificate authorities, or registrars and hosting companies of phishing sites discovered using their infrastructure to conduct a phishing attack.
Please get in touch (firstname.lastname@example.org) if you would like to try out this service or for subscription information.
When the African nation of Mali announced that it was going to provide free .ml domains from July, their goal was to put Mali back on the map. It appears they have now succeeded, but perhaps not in the way they had intended — thanks to the free domains, Mali now has the most phishy top-level domain of any country in the world.
Nearly 6% of the .ml domains in Netcraft's survey are currently blocked for hosting phishing sites, making it by far the phishiest TLD. In comparison, the second most phishy TLD, .bt (Bhutan), has only 0.7% of its sites blocked for phishing.
.ml domains can be quickly and easily registered at Freenom, which is owned by the Netherlands-based Freedom Registry. Registrants are required to create an account with a valid email address, and a CAPTCHA is used to try and prevent automated registrations. Domains can be registered for between 1 and 12 months initially, with an unlimited number of renewals. Domains which contain more than 3 characters are free.
It is not surprising to see free domain names being used in phishing attacks, but some TLDs have managed to tackle such fraud with astounding efficacy. The .tk TLD was taken advantage of extensively by phishers in 2011, prompting its registrar, Dot TK (another subsidiary of Freedom Registry), to introduce an anti-abuse API to allow trusted partners to shut down sites that use the .tk ccTLD. This dramatically reduced the average uptime of phishing sites which used .tk domains, making it a less attractive platform for fraudsters. Indeed, .tk does not even appear within the top 50 phishiest TLDs today; however, considering .tk and .ml share the same owner, this makes it somewhat surprising to see .ml being so heavily abused already.
A Taobao (Chinese shopping site) phish using a .ml domain, hosted in the US.
Despite the obvious appeal of a free and easily registered domain name when orchestrating a phishing attack, the phishiest TLDs are not always free, nor easy to register. Back in June, Morocco had the phishiest TLD (.ma), although it has since fallen to 12th place. As well as not being free, the administrative contact for an .ma domain must be established in Morocco; however, people living outside Morocco can still register an .ma domain through third parties.
Netcraft provides services to help protect domain registries, brand owners and hosting companies. You can also protect yourself against the latest phishing attacks by installing Netcraft's Anti-Phishing Extension and help protect the internet community by reporting potential phishing sites to Netcraft by email to email@example.com or at http://toolbar.netcraft.com/report_url
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 2008 94.54% Windows Server 2012 1.76% Linux 1.39% Unknown 1.25% Other 1.06%
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 marines.com, an official US Marine Corps recruitment website. m.marines.com 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.
m.marines.com 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/OS Windows Linux Mac OS X iOS Android Google Chrome 28 Yes Yes No No No Firefox 22 No No No N/A No Internet Explorer 10 Yes N/A N/A N/A N/A Safari 6 No N/A No No N/A Opera 12 Yes Yes Yes N/A N/A Opera 15 Yes N/A No N/A N/A Opera Mini N/A N/A N/A Yes Yes Opera Mobile N/A N/A N/A N/A No
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.
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 priority Cipher Suite Real-world usage in SSL Survey 1 AES128-SHA 63.52% 2 AES256-SHA 2.21% 3 RC4-SHA 17.12% 4 DES-CBC3-SHA 0.41% 5 ECDHE-RSA-AES128-SHA 0.08% 6 ECDHE-RSA-AES256-SHA 0.21% 7 ECDHE-ECDSA-AES128-SHA 0.00% 8 ECDHE-ECDSA-AES256-SHA 0.00% 9 DHE-DSS-AES128-SHA 0.00% 10 DHE-DSS-AES256-SHA 0.00% 11 EDH-DSS-DES-CBC3-SHA 0.00% 12 RC4-MD5 16.46%
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.
How is this related to PRISM?
Website Internet Explorer Google Chrome Firefox Safari Opera www.facebook.com RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA www.twitter.com RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA www.yahoo.com AES128-SHA CAMELLIA256-SHA CAMELLIA256-SHA AES128-SHA AES256-SHA www.google.com ECDHE-RSA-AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-RC4-SHA RC4-SHA login.live.com AES128-SHA AES128-SHA AES128-SHA AES128-SHA AES128-SHA www.aol.com RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA www.apple.com AES256-SHA AES256-SHA AES256-SHA AES256-SHA AES256-SHA commerce.paltalk.com RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA
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
Website Internet Explorer Google Chrome Firefox Safari Opera www.cloudflare.com ECDHE-RSA-AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-RC4-SHA RC4-SHA www.duckduckgo.com RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA www.mega.co.nz RC4-SHA RC4-SHA RC4-SHA RC4-SHA RC4-SHA
The negotiated cipher suite for a selection of SSL sites. PFS cipher suites are highlighted in bold and green.
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.