An Experimental Study of TLS Forward Secrecy Deployments

Lin-Shung Huang∗, Shrikant Adhikarla†, Dan Boneh‡, Collin Jackson∗ ∗Carnegie Mellon University, {linshung.huang, collin.jackson}@sv.cmu.edu †Microsoft, [email protected] ‡Stanford University, [email protected]

Abstract—Forward secrecy guarantees that eavesdroppers sim- In response, some sites like Google have deployed forward ply cannot reveal secret data of past communications. While secrecy to protect the privacy of past encrypted communi- many TLS servers have deployed the ephemeral Diffie-Hellman cations [3], using TLS’s ephemeral Diffie-Hellman (DHE) (DHE) key exchange to support forward secrecy, most sites use weak DH parameters resulting in a false sense of security. In or ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key our study, we surveyed a total of 473,802 TLS servers and exchange methods. With these methods, the server’s long- found that 82.9% of the DHE-enabled servers were using weak term secret key is used to sign a short-lived (ephemeral) DH parameters. Furthermore, given current parameter and Diffie-Hellman key exchange message. The resulting Diffie- algorithm choices, we show that the traditional performance Hellman secret is used as the session’s pre-master secret. argument against forward secrecy is no longer true. We compared the server throughput of various TLS setups, and measured Once the pre-master secret is discarded after the session, real-world client-side latencies using an ad network. Our results the session key cannot be reconstructed even if the server’s indicate that forward secrecy is no harder, and can even be faster private key is given. Unfortunately, we discovered in our study using elliptic curve cryptography (ECC), than no forward secrecy. that 82.9% of web sites who support DHE are using DH We suggest that sites should migrate to ECC-based forward parameters weaker than their signature key strengths, resulting secrecy for both security and performance reasons. in a weakened pre-master secret. This suggests an industry- Keywords-TLS; forward secrecy; elliptic curve cryptography; wide misunderstanding of how DHE should be deployed.

Our results. In this study, we performed a survey of TLS for- I.INTRODUCTION ward secrecy deployment across the top one million websites. The Transport Layer Security (TLS) protocol is designed to We then evaluate the performance costs of forward secrecy provide privacy and data integrity between two communicating on servers and real-world clients. Some of our results are as parties. TLS is increasingly used on the Internet to protect follows: users’ emails, credit card transactions and other personal data. We successfully scanned 473,802 websites that use TLS. We briefly describe how TLS protects data from eavesdroppers Over 74% of those sites supported at least one of the two as follows. When a client connects to a TLS server, the client ephemeral key exchange methods (DHE or ECDHE). Unfor- generates a random nonce (the pre-master secret), encrypts it tunately, we discovered that 82.9% of the servers supporting with the server’s public key, and sends it to the server. The DHE used Diffie-Hellman parameters that are weaker than pre-master secret is used by both parties to derive a shared their RSA signature strengths. The resulting sessions are session key for bulk encryption. Since the pre-master secret therefore more vulnerable to a brute-force cryptanalysis attack is encrypted with the server’s public key, only the holder of than if the RSA key exchange (with no forward secrecy) was the server’s private key should be able to decrypt encrypted used. messages. However, the security of the server’s private key We evaluated the throughput of TLS servers and find that is not always as robust as one may wish. An attacker could ECC-based forward secrecy is not much slower, and can even possibly steal private keys from server administrators via be faster, than RSA-based setups with no forward secrecy. social engineering, recover expired private keys from discarded The reason is that with the RSA key exchange, the server must storage devices (that might be less protected), or perform perform an expensive RSA decryption on every key exchange. cryptanalysis with future super computers. In fact, the Heart- With the ECDHE key exchange, the server can RSA-sign its bleed OpenSSL bug [1] makes a point that private keys can be ECDH parameters once and re-use that signature across several silently stolen from servers. Hence, an eavesdropper capturing connections. The server-side online cryptographic operation is encrypted traffic today might be able to decrypt the traffic in then just one elliptic curve multiplication which can be faster the future. A leaked document [2] even suggests that some than a single RSA decryption (of equivalent key strength). governments have surveillance programs to capture backbone Consequently, the traditional performance argument against communications. If a government stores all of the captured forward-secrecy is simply no longer valid given the current traffic and later requests the server’s private key, then past parameter and algorithm choices. Our results suggest that encrypted communications may be decrypted. websites should move to using ECDHE and reap the security and performance benefits. Client Server Lastly, we measured TLS client latencies on thousands of ClientHello −−−−−−→ real-world clients using ad networks. We identified a one- ServerHello time performance issue that occurs when a client first sees an Certificate ECDSA signature. Encouragingly, our TLS latency measure- ServerKeyExchange (optional) ←−−−−−− ments indicate that ECC-based forward secrecy performs no ServerHelloDone ClientKeyExchange worse than plain RSA-based setups on the real-world clients. ChangeCipherSpec Finished −−−−−−→ Organization. The rest of this paper is organized as follows. ChangeCipherSpec Section II provides background and related work. Section III ←−−−−−− Finished presents a survey of TLS servers, which reveals that most DHE servers use insufficient key strengths. Section IV evaluates the Fig. 1: A TLS handshake with no client authentication. The server and client performance of common TLS cipher suites optional ServerKeyExchange message is sent when using that support forward secrecy. Section V discusses the best the Diffie-Hellman key exchange. practices for deploying forward secrecy. Section VI concludes.

II.BACKGROUND order. The server also sends its public key certificate over the In this section, we give a brief introduction to the TLS Certificate message to the client. Since the message may be protocol and forward secrecy. We then survey related work. manipulated by a network attacker, the client is responsible of checking whether the server’s certificate is valid (e.g., A. SSL/TLS issued by a trusted certificate authority, matches the server’s Transport Layer Security (TLS) [4], the successor of Secure hostname, not expired nor revoked, etc.). If the certificate is Sockets Layer (SSL) [5], is an encryption protocol designed to accepted, the client generates a pre-master secret, encrypts prevent network adversaries from eavesdropping or tampering this pre-master secret using the server’s public key, and sends sensitive data, while enabling clients and servers to reliably the encrypted secret to the server over a ClientKeyExchange identify each other. TLS allows application-specific protocols message. At this point, both the client and server can compute such as HTTP to be encapsulated and securely transmitted a common master secret (used to derive the session key) from over the underlying transport protocols such as TCP, and is the pre-master secret and the random nonces. Lastly, both increasingly used by web applications, especially by webmail the server and the client send ChangeCipherSpec messages, and online banking websites. indicating that subsequent messages will be encrypted using The TLS protocol is designed to support an extensible set the negotiated cipher suite and session key, starting with an of cipher suites, where each cipher suite defines a combination encrypted Finished message. of authentication, key exchange, bulk encryption, and message B. Forward secrecy authentication code (MAC) algorithms to be used. Forward secrecy, also known as perfect forward secrecy • Authentication algorithms allow communicating parties to (PFS), is an important security property which guarantees that verify the identities of each other, e.g., RSA and DSA. derived session keys cannot be revealed, even if the long- • Key exchange schemes allow peers to securely agree upon term private key is compromised in the future. Especially in on a session key used for bulk encryption, e.g., RSA and the situation where Internet surveillance is a concern, forward Diffie-Hellman. secrecy lets enterprises argue that eavesdroppers simply cannot • Bulk encryption ciphers are used to encrypt the applica- reveal secret data of past communications. However, in TLS, tion data, e.g., AES and RC4. forward secrecy is not necessarily guaranteed. In particular, • Message authentication algorithms are used to generate the RSA key exchange is only secure as long as the server message digests, e.g., SHA-1. can protect its private key. If the server’s private key is ever Recent versions of TLS now support elliptic curve cryptogra- revealed, an attacker can decrypt all recorded sessions by phy (ECC) [6], including ECDSA authentication and Elliptic deriving the pre-master secret using the server’s private key, Curve Diffie-Hellman key exchange. and basically recover all past session keys. When initializing a TLS connection, the client negotiates There are currently two key exchange methods in TLS the cipher suite and parameters with the server over a TLS that support forward secrecy, including ephemeral Diffie- handshake. Figure 1 depicts a standard TLS handshake using Hellman (DHE) and ephemeral Elliptic Curve Diffie-Hellman the basic RSA key exchange with no client certificates. Ini- (ECDHE). When using DHE or ECDHE, the server’s long- tially, the client sends a ClientHello message to the server to term secret key is used to sign a short-lived Diffie-Hellman provide a list of supported cipher suites (in preference order) key exchange message as the pre-master secret (that is dis- and a client random nonce. In response, the server sends a carded after the session). For example, when using DHE key ServerHello message that specifies the chosen cipher suite exchange with RSA signatures, the server sends an additional and a server random nonce. Note that the server determines the ServerKeyExchange message which contains an ephemeral cipher suite and may ultimately override the client’s preference Diffie-Hellman public key that is signed with server’s RSA private key. Similarly, when using ECDHE with RSA signa- Error Hosts tures, an extra ServerKeyExchange message contains the Connection refused error 163,948 ephemeral elliptic curve Diffie-Hellman public key and its SSL errors 187,532 elliptic curve domain parameters, which are signed with the Timeout 120,068 server’s RSA private key. The server may also replace RSA Invalid hostname error 41,209 signatures entirely with elliptic curve cryptography, by signing Connection reset error 11,915 the ECDHE public key with its ECDSA private key. IP unreachable 1,325 C. Related work DoS-blocked 192 Other errors 9 Several past studies [7], [8], [9], [10] have crawled public websites to measure the prevalence of specific server vulnera- TABLE I: Connection errors during bilities in the wild. For instance, Lee et al. [9] scanned 19,429 TLS survey TLS servers checking support for weak export ciphers and insecure protocol versions. The SSL Pulse project [11] peri- odically scans the top TLS servers for known vulnerabilities list, we tried connecting to port 443 of the naked domain, and such as insecure renegotiation, BEAST and CRIME. Another then the www subdomain (if the former failed). category of TLS surveys [12], [13], [14], [15] analyzed TLS We implemented our scanner based on SSLScan 1.8.2 [22]. certificates of public websites to measure common server mis- By making multiple TLS connections to the host, SSLScan de- configurations. For instance, Holz et al. [13] scanned the Alexa termines the supported SSL/TLS protocol versions, supported top one million sites and monitored TLS traffic of a research cipher suites, and cipher suite preference of a TLS server. network over a 1.5 year period, reporting that roughly 40% of We updated the code to test all of the current TLS cipher the observed certificates failed to validate. In comparison, our suites available in OpenSSL 1.0.1e [23], and modified our TLS survey focuses on studying forward security deployments OpenSSL to expose TLS key exchange details, including the and identifying insecure DHE or ECDHE configurations. actual DH parameters and ECDH parameters from the servers. A number of TLS performance evaluations [16], [17], Since the scanning process is I/O bound due to network [18], [19], [20] have been conducted in the past. Coarfa et latencies, we implemented a Python script that spawns a pool al. [17] profiled TLS web servers with trace-driven workloads of 300 concurrent scanner processes, such that multiple sites in 2002, showing that the largest performance cost on the are scanned in parallel (rather than in serial). In addition, we TLS web server is from the RSA operations, and suggested set a socket connection timeout of 30 seconds. that TLS overhead will diminish as CPUs become faster. In our study, we made no attempt to validate the TLS Gupta et al. [18] showed that TLS server throughput can certificates, thus our dataset may include reused certificates on increase by 11% to 31% when using ECDSA signatures shared hosts, and possibly some configurations of servers not over RSA signatures. Bernat [19] evaluated RSA, DHE and actually in use. This particular subject has been investigated ECDHE key exchanges over 1,000 handshakes and reported a by several existing studies [13], [14], [15], [12]. 15% server overhead for using ECDHE-256 over RSA-2048 key exchange. Subsequently, Mavrogiannopoulos [20] reported B. Results that at equivalent security levels, ECDHE-192 outperforms We successfully performed our TLS scan on 473,802 unique RSA-1776 key exchange. In our work, we are first to conduct hosts out of the top one million sites. Note that distinct an ad experiment to measure client perceived TLS latencies hostnames may share the same IP or physical machine. Table I in real-world. summarizes the connection errors of the 526,198 Alexa entries where both the naked domain and the www subdomain failed. III.SURVEY OF TLS SERVERS Most of connection failures (e.g. timeout, connection refused, We conducted our survey to find out how many servers cur- connection reset) were simply because websites did not run rently support forward secrecy, and whether servers use secure a TLS server on port 443. The SSL errors were possibly Diffie-Hellman parameters. We describe our methodology for caused by server misconfigurations, which triggered TLS alert scanning websites first and then present our results. messages before the TLS handshake has completed. Most of the invalid hostname errors were caused by hostname strings A. Methodology in the Alexa dataset that incorrectly contained a URL path We surveyed the top 1,000,000 global sites (retrieved from component (which otherwise overlaps with valid hostnames Alexa [21] on September 9, 2013) during September 13, 2013 in the dataset). to September 27, 2013. The Alexa dataset is a ranked list of the There were 192 errors that we labeled as “DoS-blocked”, most popular sites on the Internet, and has been widely used which means the site actually accepted our initial TLS con- by several TLS server surveys [9], [13], [15]. Since Alexa’s nection, but stopped responding to our machine before we rankings are not based on TLS traffic, many of the listed sites were able to test all of the available cipher suites. We reason do not actually support TLS, thus we used a simple heuristic that these websites deployed defenses against denial-of-service to discover TLS-enabled servers. For each site in the Alexa (DoS) attacks, which blocked our IP address after making Method Hosts IMC’07[9] Curve Hosts RSA 473,688 (99.9%) 99.86% secp256r1 81,789 (96.1%) DHE 283,647 (59.8%) 57.57% sect233r1 3,123 (3.6%) ECDHE 85,070 (17.9%) sect571r1 316 (0.3%) Fixed ECDH 1 (0.0%) secp384r1 86 (0.1%) secp521r1 73 (0.0%) TABLE II: Key exchange method support on TLS servers sect163r2 26 (0.0%) secp224r1 3 (0.0%) Size (bits) Hosts secp192r1 1 (0.0%) 256 2 (0.0%) TABLE IV: Elliptic curves used for ECDHE key exchange 512 96,559 (34.0%) 768 933 (0.3%) 1024 281714 (99.3%) gle host may support multiple DH parameter sizes, thus adding 1544 1 (0.0%) up the percentages of supporting hosts across different DH 2048 859 (0.3%) parameter sizes may exceed 100%. To our surprise, only 0.3% 3248 2 (0.0%) of the DHE-enabled servers have actually deployed 2048-bit 4096 14 (0.0%) DH parameters! Our results show that as much as 99.3% of the DHE-enabled servers supported 1024-bit DH parameters. This TABLE III: Diffie-Hellman parameter size support for DHE is concerning since CAs and browsers are moving to 2048- key exchange bit (or stronger) RSA authentication by 2014 [25], and 1024- bit Diffie-Hellman may soon be considered insufficient. Even worse, there were 34% DHE-enabled servers that deployed consecutive connections in a short period of time. While there insecure 512-bit DH parameters, mostly due to supporting may be workarounds to this (e.g., acquiring more IP addresses export cipher suites. to open connections from, or lowering our connection rate), We further examine how many TLS servers are using DHE the number of sites affected was not significant. We present with an ephemeral DH parameter size smaller (weaker) than the main results of the successful TLS scans below.1 its RSA/DSA key size. Unfortunately, the majority (82.9%) of 1) Key exchange methods: First of all, we show in Table II the DHE-enabled servers supplied smaller DH parameters. On the key exchange methods supported by websites, comparing 61.9% of the DHE-enabled servers, the server used smaller DH to Lee et al.’s study in 2006 [9]. Since each unique host may parameters and used DHE as server’s preferred key exchange. use multiple SSL/TLS protocol versions, we consider that a In other words, if the browser supports both RSA and DHE, particular key exchange method is supported by a host if it the server would use the weakened DHE by default. worked in at least one of the SSL/TLS protocol versions in use. To explain the widespread usage of weak DH parameters, In our results, RSA is clearly the most widely supported key we cite the fact that popular web servers simply did not exchange method, accepted by over 99.9% TLS sites. There support 2048-bit DHE out of the box (until recently) [26], were 59.8% TLS sites that supported DHE (which barely [27]. For example, Apache (prior version 2.4.7) only supported increased from 57.5% since 2006). However, only 17.9% up to 1024-bit DH parameters [28], and IIS uses 768-bit DH of the TLS sites actually supported ECDHE. One possible parameters [29]. Interestingly, Graham [30] pointed out that reason for the low ECDHE adoption rate is that elliptic curve Tor (prior version 2.4) uses 1024-bit DHE as well. Another cryptography has been intentionally disabled in popular Linux possible pushback against increasing DHE strength on servers distributions (Red Hat / Fedora) due to patent concerns until is that Java clients only support up to 1024-bit DH parameters. 2013 [24]. Fortunately, a recent patch has lifted this limitation [31]. As mentioned in Section II-B, both the DHE and ECDHE key exchanges support forward secrecy while the RSA key Consistent ephemeral ECDH parameters Encouragingly, exchange does not. In all, there were a total of 353,209 out of all the successful ECDHE connections, none of the (74.5%) unique hosts that enabled either DHE or ECDHE, thus ephemeral ECDHE keys were weaker than the RSA signatures supported forward secrecy. Out of the servers that supported in use. This may be explained by the fact that the key strength forward secrecy, we noticed that 287,301 (81%) of these of the most commonly used 256-bit ECDHE is stronger than servers preferred to use either DHE or ECDHE over RSA. the currently recommended 2048-bit RSA signature. Table IV lists the elliptic curves observed over the ECDHE Weak ephemeral DH parameters. In Table III, we show key exchange during our TLS survey when connecting with an the actual Diffie-Hellman parameter sizes supported by TLS OpenSSL client. Most of the ECDHE-enabled sites used the servers that enabled the DHE key exchange. We note that a sin- curve named secp256r1, also known as NIST P-256 [32]. 1Additional data (SSL/TLS versions, encryption methods, and MAC meth- One should expect similar results using browsers, since Fire- ods) from our TLS scan are provided in Appendix A. fox and Google Chrome only support three NIST curves Method Hosts IMC’07[9] Cipher suitea Key exchange Authentication PFS RSA 473,780 (99.9%) ≥ 99.86% RSA-RSA RSA-2048 RSA-2048 No Anonymous 7,750 (1.6%) DHE-RSA DHE-2048 RSA-2048 Yes DSA 22 (0.0%) 0.02% ECDHE-RSA ECDHE-256 RSA-2048 Yes ECDSA 2 (0.0%) ECDHE-ECDSA ECDHE-256 ECDSA-256 Yes ECDH 1 (0.0%) DHE-DSA DHE-2048 DSA-2048 Yes a For brevity, we abbreviated the actual TLS cipher suite names, e.g., TABLE V: Authentication method support on TLS servers TLS DHE RSA WITH AES 128 CBC SHA as DHE-RSA. TABLE VII: TLS cipher suites for evaluation Size (bits) Hosts IMC’13[15] IMC’07[9] ≤ 512 350 (0.0%) 0.1% 3.94% 513 - 1023 20 (0.0%) 0.0% 1.42% IV. TLS PERFORMANCE EVALUATION 1024 87,760 (18.5%) 10.5% 88.35% In this section, we analyze the performance of various TLS 1025 - 2047 20 (0.0%) 0.7% 0.01% cipher suites that support forward secrecy, on the server side 2048 374,294 (79.0%) 86.4% 6.14% and the client side. We conducted two separate experiments 2049 - 4095 251 (0.0%) 0.0% 0.00% to evaluate the performance of various TLS cipher suites. 4096 11,093 (2.3%) 2.3% 0.19% First, we conducted a controlled experiment where we load ≥ 4097 22 (0.0%) 0.0% 0.00% tested our TLS servers over a high-speed internal network. Second, we ran an Ad experiment to measure the client-side TABLE VI: RSA key sizes of TLS server certificates TLS latencies on real-world clients.

A. TLS server setup (secp256r1, secp384r1 and secp521r1), and Internet Ex- In our experiments, we used Apache 2.4.4 compiled with plorer only supports two curves (secp256r1 and secp384r1). OpenSSL 1.0.1e (with 64-bit elliptic curve optimizations [33]) During our scan, we noticed that 34,145 hosts (40.1% of the to run our TLS servers. Abalea’s mod ssl patch [28] was ECDHE-enabled servers) reused their ECDHE public keys for applied to support 2048-bit Diffie-Hellman parameters. 2 We multiple connections, which means that these servers did not used Rackspace virtual private servers (a generic low-end setup re-sign new ECDH parameters for every connection. This may for running modern web servers) equipped with AMD Opteron be a deliberate performance optimization, as long as the server 4170 HE 2.1 GHz CPU, 512 MB RAM and 40 Mbps network re-generates new parameters periodically. bandwidth, installed with Debian Linux 2.6.32-5. We setup 2) Authentication methods: Table V lists the authentication multiple TLS virtual hosts on distinct ports, in which each methods that were supported by websites. As shown, RSA is TLS virtual host enabled only a single cipher suite. by far the most commonly deployed authentication method. We selected five representative TLS cipher suites for eval- This result has not changed much since 2006 [9]. We only uation as summarized in Table VII. All of the cipher suites observed two hosts that supported ECDSA authentication. By in our experiments were uniformly configured to use 128- manual inspection, we observed that one host used a self- bit AES-CBC encryption with SHA-1 HMAC. However, the signed ECC certificate, while the other host used a valid ECC security strengths of these cipher suites were not necessarily certificate signed by Symantec. There was one odd host that equivalent (e.g., ECDSA-256 is stronger than RSA-2048 and used ECDH authentication with a self-signed certificate for the DSA-2048). This is mainly because our server certificates were fixed ECDH key exchange. Unfortunately, we noticed there are issued by a commercial CA, which does not allow configuring 1.6% hosts that still support anonymous cipher suites, which arbitrary certificate strengths. Note that we could not simply offers no authentication at all and are trivially vulnerable to use self-signed certificates, since they trigger SSL certificate TLS man-in-the-middle attacks. warnings on real-world clients in our ad experiment. Table VIII Next, we present the distribution of RSA public key sizes compares the 3 production TLS certificate chains used in our of TLS sites that use RSA signatures in Table VI. Each unique evaluation, listing the signature algorithms, signature hash al- host may possibly support multiple public key sizes. Note gorithms and chain sizes. Different signature algorithms (RSA, that the percentages published by Durumeric et al. [15] are DSA and ECDSA) were not mix-and-matched within the same calculated differently; they represent the distribution of each chain. We point out that there is roughly an one kilobyte size public key size by counting unique trusted certificates, rather difference between the RSA and ECDSA certificate chains. than unique hosts; furthermore, they excluded certificates that This is because the a ECDSA-256 public key plus signature are not trusted by browsers, thus differences from our results is smaller than a RSA-2048 public key plus signature, and can be expected. Nevertheless, we find our results roughly in there are two certificates (leaf and intermediate) transmitted line with their study. Usage of 1024-bit RSA public keys have per chain. Lastly, since none of the major browsers currently significantly dropped since 2006 [9], while 2048-bit keys have increased to 79% of the measured TLS servers. 2Abalea’s patch is obsolete as of Apache 2.4.7 [34]. Leaf certificate Intermediate certificate Root certificate (not transmitted) Chain size (bytes) 1. RSA-2048, SHA-256 RSA-2048, SHA-1 RSA-2048, SHA-1 3,119 2. DSA-2048, SHA-256 DSA-2048, SHA-256 DSA-2048, SHA-256 3,343 3. ECDSA-256, SHA-256 ECDSA-256, SHA-384 ECDSA-384, SHA-384 2,104

TABLE VIII: TLS certificate chains issued by Symantec CA for evaluation support DSA-2048 signatures (despite that some support DSA- DH key (and RSA-signing it) for each ServerKeyExchange 1024), DHE-DSA was not measured in the ad experiment. message. Interestingly, ECDHE-RSA averaged 237 requests per second (when serving simple pages), suggesting that the B. Controlled experiment server performance cost of forward secrecy using ECDHE is 1) Methodology: In the controlled experiment, we mea- not only dramatically cheaper than DHE, but also almost free sured the average server throughput of each TLS server setup compared to plain RSA. by generating large amounts of synthetic TLS traffic towards Next, we look at how different signature algorithms impact the server, from two client machines over a 40 Mbps private server throughput. By comparing DHE-RSA and DHE-DSA, network. We used the ApacheBench tool [35] to send HTTPS we check whether RSA and DSA signature algorithms perform requests continuously, and concurrently (1,000 requests at the differently (using the same DHE key exchange). DHE-RSA same time), from each client machine. We disabled TLS ses- averaged as low as 44.9 requests per second (when serving sion resumption and HTTP connection re-use. We monitored multi-domain pages). Similarly, DHE-DSA averaged as low the server throughput (number of requests per second) and as 44.8 requests per second (when serving simple pages). took the average value over 5 minutes. For sanity check, we Evidently, the performance of DHE key exchange was con- tested each TLS server configuration using GET requests and sistently the worst regardless of using either RSA or DSA HEAD requests, separately. signatures. When using ECDSA signatures (matched with the Since the performance of TLS servers may possibly vary by ECDHE key exchange), we can see that the performance the complexity of web pages, we setup three different types of of ECDHE-ECDSA is the fastest (peaking at 405 requests web pages for our experiments, all mirrored from real websites per second when serving simple pages). ECDHE-ECDSA on the Internet:papp is not only faster than ECDHE-RSA (also using ECDHE key exchange), but even faster than RSA-RSA, which does • Simple page - a copy of one of our author’s home page. The page was static and hosted on a single domain. not provide forward secrecy. Moreover, ECDSA-256 has a higher security strength than RSA-2048, thus one could expect • Complex page - a copy of Amazon.com’s landing page. We downloaded the page along with its sub-resources a larger difference if comparing equivalent strengths. Most (e.g. images, stylesheets and scripts), and hosted the page interestingly, this suggests that enabling forward secrecy may and all sub-resources on a single domain. even improve server performance. In order to reaffirm the observations above (for GET re- • Multi-domain page - a copy of Salon.com’s landing page. After downloading the page, we manually categorized its quests), we compare the corresponding measurements using sub-resources according to their originating domains. We HEAD requests, which skips transmitting the entire page body then setup 10 sub-domains on our site (corresponding to after the TLS handshake. We find that both results were the originating domains) to serve the sub-resources, and consistent. We draw the following three main observations modified the landing page to request its sub-resources from our controlled experiment: from those sub-domains. • DHE-RSA and DHE-DSA performed the slowest. Using 2) Results: In Figure 2, we show the average number of DHE, forward secrecy is very slow. requests per second that the web server can serve when fully • ECDHE-RSA is not far worse than RSA-RSA. Using loaded under each server configuration. First, we observe the ECDHE, forward secrecy is basically free. impact of key exchange schemes on server throughput by • ECDHE-ECDSA performed faster than RSA-RSA. Using comparing the three cipher suites (RSA-RSA, DHE-RSA and elliptic curve cryptography, enabling forward secrecy ECDHE-RSA) that use the same signature algorithm (RSA- actually improves performance. 2048) but different key exchange schemes (RSA, DHE and C. Ad experiment ECDHE). Our results show that RSA-RSA was clearly the fastest of the three regardless of the type of web page, 1) Methodology: To compare the client-side performance peaking at 265.4 GET requests per second (when serving of different TLS cipher suites, we conducted an ad experiment simple pages). Notably, DHE-RSA performed significantly to measure TLS latencies on real-world clients. Ad networks slower than RSA-RSA and ECDHE-RSA, averaging 45.7 have been used by researchers as a platform for measuring requests per second in the best case. This should be due to browser and network characteristics, such as finding security the extra computation required for generating the ephemeral vulnerabilities [36], [37]. In this study, we served our perfor- Simple Page Complex Page Multi-domain Page 400

300 Cipher suite DHE-DSA DHE-RSA 200 ECDHE-RSA RSA-RSA ECDHE-ECDSA 100

0 Server throughput (requests/second) throughput Server GET HEAD GET HEAD GET HEAD Request type

Fig. 2: Server throughput of different configurations under synthetic traffic mance measurement code to thousands of browsers across the interference in between each test. Since modern web clients world over an ad network. are known to cache OCSP responses and we have three Our experiment setup consisted of two machines (with server setups that share the same RSA certificate chain, it separate IP addresses and domain names), one which runs the is possible that whichever RSA-certificate setup tested first TLS servers to be tested (as described in Section IV-A), and may load slower due to performing a fresh OCSP lookup, the other which hosts our advertisement banner page (mainly while subsequent tests may load faster due to enjoying a a blank image and JavaScript code). When our ad banner is warmed OCSP cache. However, we cannot remotely flush the rendered, our code will open TLS connections from the client client’s OCSP cache before each test, nor do we have the to our TLS server by loading each HTTPS test link in an option of switching different intermediate certificates for our IFRAME. For each HTTPS test, our script measures the client- production certificates. As a workaround, we added “cold” side latencies using the HTML5 Navigation Timing API [38] TLS connections in front of our tests to warm the client’s (on supporting browsers). We collected the following client- OCSP cache, such that all of the subsequent tests would be side latency measurements: equally evaluated under a warmed OCSP cache.

• TLS setup time: The amount of time used to establish 2) Results: We purchased 273,533 advertisement impres- a SSL/TLS connection, including the TLS handshake sions from 23 January 2014 to 29 January 2014. We spent time and the certificate validation time on the client. $167.75 in total, including $122.23 on a run-of-network cam- Unfortunately, this measurement is only available in paign (195,214 impressions), and $45.52 targeted on mobile Chrome browsers (using Navigation Timing’s optional devices (78,319 impressions). We note that not all ad im- secureConnectionStart attribute). pressions can convert to valid measurements. We discarded • TCP + TLS setup time: The amount of time used to es- impressions with clients that do not support HTML5 Navi- tablish the transport connection, which includes the TCP gation Timing, and clients that are not viewing our ad for handshake and TLS handshake (and optionally SOCKS the first time. Also, users may leave the web page before authentication). The required APIs (connectEnd and completion of tests. We indicate the number of unique clients connectStart) are currently supported in three major that successfully performed each test in Figures 3a-c and 4a-c. browsers (including Chrome 6+, Firefox 7+ and IE 9+). Since the measured client-side latencies may contain outliers, we visualize our results with a box plot showing the 10th, Upon completion, the timing measurements are sent back via 25th, 50th (median), 75th and 90th percentiles for each setup. a GET request to our log server. When receiving network requests, our log server immediately discards the client’s IP TLS setup times. Figures 3a-c show the TLS setup times of address (to avoid storing information that might individually different cipher suites in Chrome browsers on Windows, OS identify the viewer of our advertisement). The experiment did X and Android (note that other browsers do not support this not require any user involvement. If the user navigated away measurement). When comparing client-side latencies, smaller (e.g. closed the tab) during the experiment, or if the TLS values mean better performance (less waiting). As mentioned connection failed, our servers still received partial results. in Section IV-A, DHE-DSA was not measured since no major As mentioned in Section IV-A, all HTTPS tests used sep- browser supported DSA-2048. Out of the four different cipher arate server ports with TLS session resumption disabled. The suites tested, two cipher suites were tested an additional time test pages were loaded in serial on the client to reduce the for the purpose of warming the OCSP cache, labeled as RSA- 22000 6000 23000 21000 22000 Cipher suite Cipher suite Cipher suite 21000 20000 ECDHE−ECDSA_COLD ECDHE−ECDSA_COLD ECDHE−ECDSA_COLD 20000 19000 5000 19000 RSA−RSA_COLD 18000 RSA−RSA_COLD RSA−RSA_COLD 18000 17000 17000 DHE−RSA 16000 DHE−RSA DHE−RSA 16000 15000 ECDHE−RSA ECDHE−RSA 4000 ECDHE−RSA 15000 14000 14000 RSA−RSA 13000 RSA−RSA RSA−RSA 13000 12000 12000 ECDHE−ECDSA 11000 ECDHE−ECDSA 3000 ECDHE−ECDSA 11000 10000 10000 9000 9000 8000 8000 7000 2000 7000 6000 TLS setup time (milliseconds) 6000 TLS setup time (milliseconds) TLS setup time (milliseconds) 5000 5000 4000 4000 1000 3000 3000 2000 2000 1000 1000 0 0 0 30000 1500 3000 20000 1000 2000 10000 500 1000 Count 0 Count 0 Count 0 (a) Chrome - Windows (b) Chrome - OS X (c) Chrome - Android Fig. 3: Comparison of TLS setup times in Chrome browsers on Windows, OS X and Android. The box plots show the 10th, 25th, 50th, 75th and 90th percentiles of measured TLS setup times for each cipher suite. The corresponding bar charts show the number of unique clients that successfully completed each test.

RSA COLD and ECDHE-ECDSA COLD. The number of certificates should consider choosing ECDHE-RSA over DHE- unique clients for ECDHE-ECDSA COLD appeared to be the RSA for both client compatibility and performance reasons. highest because it was always tested first (and many users do TCP + TLS setup times. Since TLS setup time measurements not stay on the page long enough for other tests to complete). were only available in Chrome browsers, on other browsers we Upon first glance at Figure 3a (Chrome on Windows), fall back on collecting TCP + TLS setup time measurements. an obvious observation is that the medians of ECDHE- The coarser TCP + TLS setup time includes not only the ECDSA COLD and RSA-RSA COLD are both substantially TLS handshake but also the TCP handshake, thus may show a slower than the other configurations. Unsurprisingly, the two slightly longer delay (and possibly more noise incurred by the “cold” connections may need to perform OCSP lookups, extra round-trips). We compare the TCP + TLS setup times resulting in longer latencies, while the subsequent tests may of different cipher suites in Figures 4a-c for Chrome, Firefox enjoy a warm OCSP cache. We compare DHE-RSA, ECDHE- and Internet Explorer browsers on all platforms. In Figure 4c, RSA, RSA-RSA and ECDHE-ECDSA after warming the we do not have any results for DHE-RSA since it was not OCSP cache. supported in Internet Explorer. While the performances of the 4 different cipher suites (not As a sanity check, the TCP + TLS results for Chrome labeled “cold”) were not too dissimilar, we noticed that the in Figure 4a were basically in line with the TLS results ECDHE-ECDSA setup consistently performed the fastest of in Figure 3a, where the ECDHE-ECDSA was the fastest of all setups, resulting in a median of 366 milliseconds (and all cipher suites. For Firefox, we did not observe significant a 90th percentile of 1088 milliseconds). This suggests that differences between the client latency medians for each ci- deploying ECC-based forward secrecy actually improves per- pher suite in Figure 4b. We did not find any cipher suite formance on the client over RSA-based setups with no forward that performed particularly slower. Unlike Chrome (where secrecy. Encouragingly, we observe very similar trends on ECDHE-ECDSA COLD took roughly 4 seconds longer than OS X (in Figure 3b) and Android (in Figure 3c), where other cipher suites in median), the performance of ECDHE- the medians of TLS setup times for ECDHE-ECDSA were ECDSA COLD in Firefox (a median of only 389 millisec- consistently the smallest. In particular, the measurements on onds) was not significantly slower than the fastest ECDHE- Android provide an interesting data point showing that mobile ECDSA (a median of only 274 milliseconds). Upon further devices (typically with less computational power than desktop investigation, we believe that “cold” connections in Firefox clients) might also benefit from ECC-based forward secrecy. were often faster than other browsers because Firefox main- On the other hand, DHE-RSA performed the slowest on tains its own root CA store (rather than rely on the operating Android mobile with a median of 820 milliseconds (and a system’s root CA store). The underlying cause is that not all 10th percentile of 525 milliseconds). Moreover, DHE-RSA is legitimate root CA certificates are pre-installed on popular not supported in one of the major browsers, Internet Explorer. client systems like Windows. When other browsers (using Servers that want to support forward secrecy using RSA the system’s CA root store) encounter an unseen root CA 23000 10000 36000 35000 22000 Cipher suite Cipher suite 34000 Cipher suite 21000 33000 9000 32000 20000 ECDHE−ECDSA_COLD ECDHE−ECDSA_COLD 31000 ECDHE−ECDSA_COLD 19000 30000 RSA−RSA_COLD 8000 RSA−RSA_COLD 29000 RSA−RSA_COLD 18000 28000 17000 27000 DHE−RSA DHE−RSA 26000 DHE−RSA 16000 7000 25000 24000 15000 ECDHE−RSA ECDHE−RSA 23000 ECDHE−RSA 14000 6000 22000 RSA−RSA RSA−RSA 21000 RSA−RSA 13000 20000 12000 19000 ECDHE−ECDSA 5000 ECDHE−ECDSA 18000 ECDHE−ECDSA 11000 17000 10000 16000 15000 9000 4000 14000 13000 8000 12000 7000 3000 11000 10000 6000 9000 5000 8000

TCP + TLS setup time (milliseconds) TCP + TLS setup time (milliseconds) 2000 TCP + TLS setup time (milliseconds) 7000 4000 6000 3000 5000 1000 4000 2000 3000 2000 1000 1000 0 0 0 30000 4000 4000 3000 3000 20000 2000 2000 10000 1000 1000 Count 0 Count 0 Count 0 (a) Chrome (b) Firefox (c) Internet Explorer Fig. 4: Comparison of TCP + TLS setup times in Chrome, Firefox and Internet Explorer browsers (on all platforms). certificate, the system automatically attempts to fetch the that a weakness with this specific curve will some day be root certificate over the Windows Update mechanism [39]. discovered. Given the popularity of this curve, this will impact In particular, we confirmed that Symantec’s ECDSA root most sites on the Internet. Although secp256r1 could be a certificate was not pre-installed on Windows 8 or Windows fine curve to use for the foreseeable future, it is worth pointing Server 2012. As a result, the ECDHE-ECDSA COLD setup out that we are putting many eggs in that curve’s basket. performs slower in non-Firefox browsers on Windows because they may need to fetch the ECDSA root certificate on-the-fly RSA vs. ECDSA authentication. Our survey shows that when first seeing the ECDSA certificate. common practice today when using ECDHE is to use elliptic Nevertheless, fetching a new root certificate is a one-time curves for key exchange, but use RSA signatures for server- cost. As more TLS servers deploy ECDSA certificate chains, side authentication. The reason is that sites mainly have clients will eventually have downloaded the ECDSA root certificates for RSA public keys. From a security standpoint certificate after visiting any of those sites and will have this is an undesirable setup: a weakness discovered in either payed off this one-time cost. From measurements on real- algorithm will defeat the security of TLS at the site. A- world clients, we discovered that without the root CA update, priori, the likelihood of a weakness discovered in one of two forward secrecy using ECDHE-ECDSA was not any slower algorithms is far greater than the likelihood of an attack on a than that using RSA-RSA. single algorithm. Consequently, due to the desire to move to ECDHE key exchange, there is a strong argument for sites to V. DISCUSSION move to certificates for ECDSA public keys. Forward secrecy deployment. Our experiments suggest that To understand the risk of using both RSA and ECDHE the performance-based arguments against deploying forward (called ECDHE-RSA) compared to only relying on elliptic secrecy are no longer valid. ECDHE-based key exchange, curve cryptography (as in ECDHE-ECDSA), consider the which provides forward secrecy, can be faster than basic following three possibilities: RSA-2048 key exchange which does not. The reason for the 1) both RSA and the NIST curve secp256r1 provide performance improvement is the replacement of an expensive adequate security, RSA-2048 decryption with faster secp256r1 elliptic curve 2) curve secp256r1 is secure, but RSA is not, operations. As we transition to longer RSA keys, such as RSA- 3) RSA is secure, but curve secp256r1 is not. 3072 or RSA-4096, the performance advantage of ECDHE Table IX lists the resulting security of ECDHE-RSA and will become even more pronounced. These results suggest ECDHE-ECDSA in each of the three cases. The table suggests that sites should migrate to ECDHE (when possible) for both that ECDHE-ECDSA incurs less risk than ECDHE-RSA since security and performance reasons. there is a scenario where ECDHE-ECDSA is secure, but The elliptic curve monoculture. We were a bit surprised to ECDHE-RSA is not. The converse cannot happen. Given the find in our study that 96.1% of sites that support ECDHE com- desire to use ECDHE, Table IX is an argument for moving to monly use the NIST curve secp256r1. While we currently elliptic curve public keys for server-side authentication. know of no specialized attacks against this curve, it is possible To properly move to ECDSA signatures, CAs will need to ECDHE-RSA ECDHE-ECDSA RSA and secp256r1 both secure secure secure secrecy using elliptic curve cryptography is actually free in the secp256r1 secure, RSA insecure insecure secure face of traditional RSA algorithms. Lastly, we analyze client- RSA secure, secp256r1 insecure insecure insecure side latencies in the wild measured from our ad experiment, and observe that ECC-based forward secrecy is also free on the TABLE IX: Comparing ECDHE-RSA and ECDHE-ECDSA client-side (although some Windows clients may experience a one-time delay for downloading the root certificate). To conclude, we recommend websites to move away from the sign those certificates with ECDSA signatures along the entire RSA key exchange to provide forward secrecy, and deploy certification chain. The security of TLS key exchange will then the ECDHE key exchange over the much slower DHE. only depend on the hardness of a single algebraic problem instead of two. Only time will tell whether the elliptic curve ACKNOWLEDGMENTS discrete logarithm problem (on the NIST curve secp256r1) We thank Rick Andrews, Kaspar Brand and Ivan Ristic for is indeed as hard as we currently believe. providing feedback on drafts of the paper. This work was Note that moving to ECDSA public keys means that during supported by NSF and a grant from Symantec. the ECDHE key exchange the server will need to generate an REFERENCES ECDSA signature. The ECDSA signature algorithm requires [1] Codenomicon, “The HeartBleed bug,” http://heartbleed.com/, 2014. strong randomness: bias in the random generator can lead [2] J. Ball, “NSA’s Prism surveillance program: how it works and what to exposure of the secret signing key [40]. Therefore, when it can do,” http://www.theguardian.com/world/2013/jun/08/nsa-prism- moving to ECDSA public keys servers will need to ensure an server-collection-facebook-google, 2013. [3] A. Langley, “Forward secrecy for Google HTTPS,” https://www. adequate source of randomness. An alternative proposal, which imperialviolet.org/2011/11/22/forwardsecret.html, 2011. is not frequently used, is to derive the ECDSA randomness by [4] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol applying a PRF such as HMAC to the message to be signed, Version 1.2,” RFC 5246 (Proposed Standard), Internet Engineering Task Force, Aug. 2008. where the PRF secret key is stored along with the signing key. [5] A. O. Freier, P. Karlton, and P. C. Kocher, “The Secure Sockets Layer (SSL) Protocol Version 3.0,” RFC 6101 (Historic), Internet Engineering DHE misconfiguration. Finally, our survey shows that there is Task Force, Aug. 2011. an industry-wide configuration problem with the deployment [6] S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, and B. Moeller, of DHE key exchange. While 79% of web sites moved to “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS),” RFC 4492 (Informational), Internet Engineering RSA-2048 (compared to 6.14% in 2007), the vast majority of Task Force, May 2006, updated by RFC 5246. [Online]. Available: sites who use DHE set their Diffie-Hellman prime to 1024 bits. http://www.ietf.org/rfc/rfc4492.txt As a result, recovering one computed session key by a brute- [7] E. Rescorla, “Security holes... who cares?” in Proceedings of the 12th conference on USENIX Security Symposium, 2003. force cryptanalytic attack requires breaking a 1024-bit Diffie- [8] S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage, “When Hellman problem, not 2048-bit RSA. By 2014 the CA/Browser private keys are public: results from the 2008 Debian OpenSSL vul- Forum will regard 1024-bit security as inadequate. We rec- nerability,” in Proceedings of the 9th ACM SIGCOMM Conference on Internet Measurement, 2009. ommend that whenever possible, sites abandon DHE in favor [9] H. K. Lee, T. Malkin, and E. Nahum, “Cryptographic strength of of ECDHE using an elliptic curve with (presumed) security SSL/TLS servers: current and recent practices,” in Proceedings of the comparable to RSA-2048. 7th ACM SIGCOMM Conference on Internet Measurement, 2007. [10] N. Heninger, Z. Durumeric, E. Wustrow, and J. A. Halderman, “Mining One could argue that 1024-bit Diffie-Hellman parameters your Ps and Qs: Detection of widespread weak keys in network devices,” are justified in this context because the Diffie-Hellman values in Proceedings of the 21st USENIX Security Symposium, Aug. 2012. are ephemeral and only used for a small number of sessions. [11] Qualys SSL Labs, “Trustworthy Internet Movement - SSL Pulse,” https: //www.trustworthyinternet.org/ssl-pulse/. Therefore, attacking a specific 1024-bit Diffie-Hellman prob- [12] Electronic Frontier Foundation, “The EFF SSL Observatory,” https:// lem will only expose a small number of sessions. The difficulty www.eff.org/observatory. with this argument is that, if for whatever reason an attacker [13] R. Holz, L. Braun, N. Kammenhuber, and G. Carle, “The SSL land- scape: a thorough analysis of the x.509 PKI using active and passive decides to target a particular high-value session, that session measurements,” in Proceedings of the 11th ACM SIGCOMM Conference only enjoys 1024-bit security. In other words, even though on Internet Measurement, 2011. only one session may be broken, that single session may be [14] D. Akhawe, B. Amann, M. Vallentin, and R. Sommer, “Here’s my cert, so trust me, maybe?: understanding TLS errors on the web,” in all the attacker needs. Proceedings of the 22nd international conference on World Wide Web, 2013. VI.CONCLUSION [15] Z. Durumeric, J. Kasten, M. Bailey, and J. A. Halderman, “Analysis While the need for TLS forward secrecy has become more of the HTTPS certificate ecosystem,” in Proceedings of the 13th ACM SIGCOMM Conference on Internet Measurement, 2013. widely discussed over the recent years, it is critical that servers [16] G. Apostolopoulos, V. Peris, and D. Saha, “Transport layer security: are configured and implemented correctly, and not otherwise, How much does it really cost?” in Proceedings of the IEEE INFOCOM, achieving a false sense of security. In this paper, we first 1999. [17] C. Coarfa, P. Druschel, and D. S. Wallach, “Performance analysis of TLS investigate the deployment of various cryptographic algorithms Web servers,” ACM Trans. Comput. Syst., vol. 24, no. 1, pp. 39–69, Feb. of 473,802 TLS sites and reported that the majority of DHE- 2006. enabled sites are configured with weak DH parameters. We [18] V. Gupta, D. Stebila, S. Fung, S. C. Shantz, N. Gura, and H. Eberle, “Speeding up secure web transactions using elliptic curve cryptography,” ran two performance experiments to evaluate various cipher in Proceedings of the 11th Annual Network and Distributed System suites that support forward secrecy, and point out that forward Security Symposium, 2004. [19] V. Bernat, “SSL/TLS & Perfect Forward Secrecy,” http://vincent.bernat. TABLE X: Protocol version support im/en/blog/2011-ssl-perfect-forward-secrecy.html, 2011. [20] N. Mavrogiannopoulos, “The price to pay for perfect-forward se- Version Hosts SSL Pulsea IMC’07 crecy,” http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward. html, 2011. SSLv2 105,239 (22.2%) 26.9% 85.37% [21] “Alexa Top 1,000,000 Sites,” http://www.alexa.com/topsites. SSLv3 470,409 (99.2%) 99.7% 97.92% [22] I. Ventura-Whiting, “SSLScan - Fast SSL Scanner,” http://sourceforge. TLSv1 471,458 (99.5%) 99.3% 98.36% net/projects/sslscan/. [23] The OpenSSL Project, “OpenSSL: The open source toolkit for TLSv1.1 79,890 (16.8%) 15.4% SSL/TLS,” http://www.openssl.org. TLSv1.2 84,406 (17.8%) 17.8% [24] T. L. MEUR, “Bug 319901 - missing ec and ecparam commands in a SSL Labs [11] surveyed 168,088 sites as of August 2013. openssl package,” https://bugzilla.redhat.com/show bug.cgi?id=319901. [25] CA/Browser Forum, “Baseline requirements for the issuance and man- agement of publicly-trusted certificates, v.1.0,” https://www.cabforum. org/Baseline Requirements V1.pdf, 2011. B. Encryption methods [26] A. Langley, “How to botch TLS forward secrecy,” https://www. imperialviolet.org/2013/06/27/botchingpfs.html. Table XI compares the percentage of unique hosts that [27] I. Ristic, “Increasing DHE strength on Apache 2.4.x,” http://blog. support each encryption method and key size. We show, in ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html. a separate column, the percentage of including all protocol [28] E. Abalea, “Bug 49559 - Patch to add user-specified Diffie-Hellman parameters,” https://issues.apache.org/bugzilla/show bug.cgi?id=49559. versions, and the percentage for TLSv1.2 specifically. Overall, [29] K. Bhargavan, “Re: OpenSSL client DH group limits,” http://marc.info/ we observe that 3DES is currently the most supported cipher. ?l=openssl-dev&m=138373503327957. Both RC4-128 and AES-128 have more than 90% adoption. [30] R. Graham, “Tor is still DHE 1024 (NSA crackable),” http://blog. Interestingly, 256-bit AES has no less adoption rate than 128- erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html, 2013. [31] Oracle, “JDK-6521495 : Lift 1024-bit long prime restriction on Diffie- bit AES. Comparing to the survey in 2006 [9], we observe a Hellman,” https://bugs.openjdk.java.net/browse/JDK-6521495. dramatic increase in AES-128 adoption from 2.05% to 90.3%. [32] NIST, “Digital Signature Standard,” in Federal Information Processing Also, support for DES and RC2 have dropped significantly. Standards Publications, FIPS PUB 186-2, 2000. [33]E.K asper,¨ “Fast elliptic curve cryptography in OpenSSL,” in Proceed- ings of the international conference on Financial Cryptography and TABLE XI: Encryption method support Data Security, 2011. [34] K. Brand, “[Apache-SVN] revision 1527295,” http://svn.apache.org/ Method Hosts TLSv1.2a IMC’07 viewvc?view=revision&revision=1527295. [35] The Apache Software Foundation, “ab - Apache HTTP server bench- 3DES-168 446,119 (94.1%) 81,085 (96.0%) 97.50% marking tool,” https://httpd.apache.org/docs/2.4/programs/ab.html. RC4-128 436,994 (92.2%) 77,271 (91.5%) 98.58% [36] C. Jackson, A. Barth, A. Bortz, W. Shao, and D. Boneh, “Protecting browsers from DNS rebinding attacks,” in Proceedings of the ACM AES-256 428,176 (90.3%) 82,191 (97.3%) 56.37% Conference on Computer and Communications Security, 2007. AES-128 428,011 (90.3%) 82,420 (97.6%) 2.05% [37] L.-S. Huang, E. Y. Chen, A. Barth, E. Rescorla, and C. Jackson, “Talking DES-56 153,243 (32.3%) 10,400 (12.3%) 62.29% to yourself for fun and profit,” in Proceedings of the Web 2.0 Security and Privacy, 2011. Camellia-128 150,421 (31.7%) 26,656 (31.5%) [38] Z. Wang, “Navigation timing,” http://www.w3.org/TR/navigation- Camellia-256 150,443 (31.7%) 26,637 (31.5%) timing/, 2012. RC4-40 127,209 (26.8%) 7,725 (9.1%) 91.75% [39] Microsoft Support, “Windows root certificate program members - RC2-40 124,890 (26.3%) 7,677 (9.0%) 90.31% how windows updates root certificates,” http://support.microsoft.com/kb/ 931125#MT5. DES-40 114,036 (24.0%) 7,715 (9.1%) 66.55% [40] P. Nguyen and I. Shparlinski, “The insecurity of the elliptic curve SEED-128 85,272 (17.9%) 16,837 (19.9%) digital signature algorithm with partially known nonces,” Design Codes RC2-128 81,570 (17.2%) 0 (0.0%) 83.78% Cryptography, vol. 30, no. 2, pp. 201–217, 2003. [41] T. Duong and J. Rizzo, “BEAST,” http://vnhacker.blogspot.com/2011/ AES-GCM-128 56,098 (11.8%) 56,098 (66.5%) 09/beast.html, 2011. AES-GCM-256 55,614 (11.7%) 55,614 (66.5%) [42] N. J. Al Fardan and K. G. Paterson, “Lucky thirteen: Breaking the IDEA-128 37,735 (7.9%) 8,807 (10.4%) TLS and DTLS record protocols,” in IEEE Symposium on Security and Privacy, 2013. Null 443 (0.0%) 30 (0.0%) a This column shows results for only TLSv1.2.

APPENDIX Unfortunately, almost a third of all TLS sites still support A. SSL/TLS protocol versions DES-56, which is considered insecure. Roughly a quarter of all TLS sites support 40-bit encryption, including RC4-40, Table X presents the percentage of unique hosts that support RC2-40 and DES-40. We even found 443 sites supporting null each SSL/TLS protocol version (out of 473,802 unique hosts ciphers. Lastly, we observe that the new AES Galois Counter that completed our TLS scan). Each unique host may support Mode (AES-GCM) cipher is enabled on 66.5% of the TLSv1.2 multiple protocol versions. In comparison to Lee et al.’s survey sites. AES-GCM is immune to BEAST [41] and the Lucky 13 in November 2006 [9], the most significant difference is that timing attack [42]. SSLv2 support has dramatically reduced from 85% down to 22%, while TLSv1.1 and TLSv1.2 have slowly gained some C. Message authentication methods adoption. Our results of TLS adoption roughly match a recent Table XII shows the website support of different message survey by SSL Pulse as of August 2013 [11]. authentication methods. SHA-1 is pervasively (99.9%) sup- ported, while MD5 has dropped from 99.83% to 72.3% since 2006 [9]. Here, the Authenticated Encryption with Associated Data (AEAD) method means that the message is encrypted and authenticated using a single key (as for AES-GCM) rather than a separate HMAC.

TABLE XII: Message authentication method support

Method Hosts IMC’07 SHA-1 473,462 (99.9%) 99.47% MD5 342,618 (72.3%) 99.83% SHA-256 69,266 (14.6%) AEAD 56,200 (11.8%) SHA-384 40,915 (8.6%)