The Secure Socket Layer (SSL) and its variant, Transport Layer Security (TLS), are used toward ensuring server security. In this paper, we characterize the cryptographic strength of public servers running SSL/TLS. We present a tool developed for this purpose, the Probing SSL Security Tool (PSST), and evaluate over 19,000 servers. We expose the great diversity in the levels of cryptographic strength that is supported on the Internet. Some of our discouraging results show that most sites still support the insecure SSL 2.0, weak export-level grades of encryption ciphers, or weak RSA key strengths. We also observe encouraging behavior such as sensible default choices by servers when presented with multiple options, the quick adoption of AES (more than half the servers support strong key AES as their default choice), and the use of strong RSA key sizes of 1024 bits and above. Comparing results of running our tool over the last two years points to a positive trend that is moving in the right direction, though perhaps not as quickly as it should.
Cryptography is an essential component of modern electronic commerce. With the explosion of transactions being conducted over the Internet, ensuring the security of data transfer is critically important. Considerable amounts of money are being exchanged over the network, either through e-commerce sites (e.g., Amazon, Buy.com), auction sites (e.g., eBay), on-line banking (e.g., Citibank, Chase), stock trading (e.g., Schwab), and even government (e.g., irs.gov). Communication with these sites is secured by the Secure Sockets Layer (SSL) or its variant, Transport Layer Security (TLS), which are used to provide authentication, privacy, and integrity. A key component of the security of SSL/TLS is the cryptographic strength of the underlying algorithms used by the protocol. It is crucial to ensure that servers using the SSL protocol have employed it properly. For example, it should be determined whether site administrators are using the best practices, are aware of their sites’ vulnerabilities if they haven’t already been addressed, and are promptly reacting to CERT advisories. Poor use of cryptography may be an indicator of poorly-administered security. Experience in related areas of patch management and virus/worm propagation is not encouraging. The recent interest in SSL-based VPNs only increases the need to study SSL.
One key feature of SSL/TLS is that it allows negotiation between two peers. Different implementations will not necessarily support the same cryptographic algorithms. Thus SSL allows two peers to determine a subset of common cryptographic routines. This allows for the interoperability and extensibility of the protocol. For example, SSL allows different algorithms to be used for authentication (e.g., RSA, DSS), key exchange (RSA, EDH), encryption (RC2, RC4, DES, 3-DES, AES), and integrity (MD5, SHA-1). This flexibility allows for new, stronger algorithms to be added over time (such as AES) and reduces dependence on any one algorithm, in case that algorithm is broken or succumbs to brute-force exhaustive search techniques (as with DES).
While this flexibility improves interoperability, it may also compromise security. For example, server administrators may wish to support as wide a range of protocols as possible in order to maximize the number of clients that can access a site. However, they may be lax in removing features that have compromises in security. For example, if a site supports a weak form of encryption, a client may choose to use that algorithm for performance or power consumption reasons (e.g., on a wireless PDA), without recognizing the dangers. This could lead to a session being broken, a customer’s password being cracked, and an empty bank account. While this could be considered simply a case of clients suffering the consequences of their actions, there are reasons to prevent this from happening. This type of experience could alienate a customer, damage the reputation of a business, and perhaps even lead to legal action. More importantly, experience shows that clients do not understand security, and thus steps should be taken to minimize opportunities for clients to make the wrong decision. For these reasons, we believe the bulk of the burden for ensuring security falls on the provider, or server in this case. This then raises the question: do servers deployed in the Internet adhere to current best practices by employing strong cryptography?
This paper characterizes the cryptographic strength of public servers in the Internet running SSL/TLS. We evaluate over 19,000 servers, and present a tool developed for this purpose, the Probing SSL Security Tool (PSST). We use PSST to evaluate which protocols and cryptographic options are supported by the servers, and which are chosen by the servers as a default when presented with several options. We show that a great variety of behavior can be found in the network, with both encouraging and discouraging results. Examples include:
• 85 percent of SSL sites support the SSL 2.0 protocol, even though it has significant security problems. Moreover, a small number of sites support only the SSL2 protocol.
• 93 percent of servers support (single) DES, despite the fact that DES is considered susceptible to exhaustive search. • Many servers support the old export-grade encryption levels, even though US law has changed and these algorithms are considered susceptible to brute-force attacks.
• 765 (almost 4 percent) of the sites use RSA-based authentication with only 512-bit keys, even though RSA has announced that this level of security is insufficient. On the other hand, over 1200 sites use 2048 bits or greater.
• AES is already supported in over 57 percent of sites we probed. Out of these, about 94 percent default to AES when presented with all options (and the vast majority of them use a strong 256 bit key).
We have also run our tool periodically over the last two years, in order to study the evolution of SSL use (and misuse) over time. The overall trend we discovered is a steady, though a little slow, improvement in cryptographic strength of SSL/TLS servers. For example, within the past two years:
• Support of the weak SSL2 protocol has been reduced by over 9 percentage points.
• Support of AES has grown by nearly 16 percentage points.
• Support of weak public key sizes has gone down by nearly 2 percentage points.
• Support of very strong public key sizes has gone up by nearly 2 percentage points.
Thus, our results show that most servers (though not all) support both weak cryptography and strong cryptography, while making the correct choice by default, if given the option. This is in sharp contrast to the situation several years ago, where 20-30 percent of the servers used only weak cryptography. As a concrete example, in 2000 25 percent of servers probed by Murray supported a very weak server key size of at most 512 bits, compared to about 4 percent today. Our results are also useful in highlighting the most prevalent supported choices among the available options, thereby allowing future efforts on improving performance and enhancing security to focus on the most relevant set of cryptographic algorithms. Finally, our tool can be useful for regular security compliance testing, especially by large organizations that own multiple servers.
Homin K. Lee Department of Computer Science Columbia University New York, NY.