SSL Server Security SurveyEric Murray[email protected]
Abstract:A random sample of 8081 different secure web servers (servers running the SSL protocol) in active use on the Internet shows that 32% are dangerously weak. These weak servers either support only the flawed SSL v2 protocol, use too-small key sizes ("40 bit" encryption), or have expired or self-signed certificates. Data exchanges with all types of weak servers are vulnerable to attack.
Note:An earlier version of this study contained errors (some SSLv3/TLS1 ciphersuites were not counted, making the number of SSLv2-only sites appear larger. This is the corrected version.
Index:
Check the security of an SSL server.
1.0 Introduction:Secure Web Servers use the Secure Sockets Layer protocol to create an encrypted communications channel between the client and server. SSL (I will use "SSL" to represent all the versions of SSL: SSLv2, SSLv3 and TLSv1) is a generic "pipeline" that secures data. It allows the two parties, a client and a server, to negotiate cryptographic algorithms to use, provides a protocol for them to do the negotiation ("SSL handshake") and then exchanges data using the algorithms. Additionally, the server is authenticated to the client during the handshake. The main steps in the SSL handshake are to
SSL is used to protect many different types of sensitive data. The most familiar is the on-line store ("e-tailer") which uses SSL to protect their customers' credit-card numbers. On-line banks, bill-payment services and stock brokers use SSL to protect their customer's account passwords and trading information. SSL is also used to protect data in B2B networks, secure ftp and telnet, and many other uses. In thus study, I generated a random sample of Secure Servers running on the Internet and on each, ran a program that connects to an SSL server, obtains its certificate and determines its security settings. Of the 8081 servers in the sample, 31.53% were found to have weak security, 9.84% to have medium security, and 58.63% to have strong security.
1.1 The Problem With Small Key Sizes:The United States (where the developers of the majority of the servers in this study are based) has a history of restricting the strength of cryptography for export, under the theory that cryptography is a munition. Previous to December 1998, cryptographic products exported from the United States for general use could not legally use more than 40-bit symmetric encryption and 512-bit asymmetric encryption. The 40-bit key size is widely recognized to be vulnerable to attack. In 1996, Damien Doligez, a student in France, used a network of idle workstations to do a brute-force search on a 40-bit SSL key that had been posted as a challenge[Doligez96]. The search took his network of machines 8 days. A distributed brute-force by a group later in 1996 found the second Hal's SSL challenge key in 32 hours. Computers have become faster and cheaper since then. A rough metric is that compute power/dollar increases 10x every five years. Since five years have passed since the original SSL challenge, a very rough estimate would be that the same break would take between 19 hours (using Doligez's setup) and 3.2 hours (using the second group's setup). More recently, public groups have built dedicated brute-force engines. In 1998, a group supported by the EFF built "Deep Crack" a DES-cracking engine [EFF98]. For a cost (in 1997) of about $210,000 they built a machine capable of brute-forcing ("cracking") a single 56-bit DES key in under three days. The possible number of keys in the 56-bit keyspace is 2^56 or about 72,057,590,000,000,000. In a 40-bit keyspace it's 2^40 or about 1,099,511,000,000 -- 1/65536 th of the number of keys that're in the 56-bit keyspace. If the EFF DES-cracker were applied to the much smaller 40-bit key space, it would take about 4 seconds to crack a single key. Asymmetric cryptography (also called public-key cryptography) can also be subjected to brute-force attacks. The most famous is the RSA Crypto Challenge. The most recent was the factoring of the two prime numbers in a 512-bit RSA key in August 1999 [RSA99]. Solving the Challenge took about 5.2 months using 292 computers spread out over the Internet. As a result, RSA Labs now recommends at least 768 bits for security. An effort similar to the DES Deep Crack, where special-purpose hardware was designed to speed up brute-forcing, has not be publically done. Most security exports believe that secret government agencies with large budgets (i.e. NSA) have built such devices.
1.2 SSLv2 Protocol Weaknesses:The SSLv2 protocol has two known flaws. The downgrade attack allows an active attacker (one who can change bits in the messages between client and server) to force an SSLv2 session to use weaker ciphersuites than would ordinarily be negotiated. Since the SSLv2 handshake packets between the client and server are not integrity checked, there's no way for the server to tell if the ciphersuite list has been modified. Once the attacker has forced the SSLv2 session into a weak ciphersuite, the attacker can use brute-force techniques to crack the small key. The truncation attack allows an attacker to stop the SSLv2 session without the server or client knowing that the session was stopped by an attacker instead of by the orher party. If the attacker knows something about the structure of the message and how it is sent in the SSLv3 packets, he can use the truncation attack to change the meaning of the message. For example, Alice the client is sending an order to buy stock to Bob the stock broker's secure server. Mark the attacker can change bits in the communications between Alice and Bob, and Mark wants Alice to lose money. He knows that Alice is sending a buy order, and he knows the format that the buy order will take (simple to figure out, he only has to look as the HTML for the form on Bob's web site). Alice sends "buy 10,000 shares of PBGX". Mark truncates her message to "buy 10,000 shares of PBG". Not being able to tell that Alice's message was truncated, Bob will execute the order to buy 10,000 shares of PBG. If Alice is unlucky, the price of PBG will be much greater than that of PBGX, and Alice will have to go on margin to cover it. At the least, she'll be out the comission and the opportunity cost of not buying PBGX when she wanted to do so. SSLv3 fixed these two defects in SSLv2. The first public publication of SSLv3 was in March 1996. Efforts to produce SSLv3 libraries were at that point underway at a number of companies and also with the open-source SSLeay project. SSLv3 products were shipping (or available for download) by the beginning of 1997.
1.3 Self-signed Server Certificates:SSL uses the X.509 certificate model. X.509 is a hierarchical model, in which there is a trusted Certificate Authority ("CA") at the top, and either other CAs or server certificates below. Each entity signs the certificate of the ones below in the chain. The one at the top has a self-signed certificate, and the relying parties (the SSL client in this case) have a list of CAs that they have decided are trustworthy. Most browsers are shipped with a long list of CA certs in a "trusted certificate database". [in Netscape, click on the "Security" button on the top bar, then on the Security screen click on "Signers" under "Certificates" to see the list of trusted CA certificates]. Most SSL servers use a certificate that has been signed by one of these CAs. When an SSL connection is being negotiated, the server sends it's certificate to the browser. The browser looks in the certificate to see which CA signed the certificate, and then checks it's database to see if that CA certificate is in the database. If it's there, then the browser will trust that the server certificate that it just received in the SSL handshake has been signed by a reputable CA -- the CA has taken some measures to make sure that the server operator is who he says he is and is a reputable entity. For an SSL server operator to set up shop, the server operator sends a certificate request to the CA, who then signs the server's public key and sends back the server's certificate. Because being a CA entails some amount of legal risk, most CAs charge for their services. If an SSL server operator wants to avoid the charge for getting a certificate issued by a CA, he can set up his server to use a self-signed server certificate. There is no CA vouching for the server operator. Anyone can make their own self-signed server certificate, all it takes is some free software. This is a server certificate that is it's own CA, that is the server operator is saying "yes, I trust myself". Therefore a self-signed certificate is essentially worthless. Browsers will accept self-signed server certificates, but only after making the user click on a number of "are you sure?" buttons. So there is at least some notice to the user that they are doing something that is unusual. However in both Netscsape and Internet Explorer, the language in the dialog boxes that tells the user that the certificate is self-signed does not explain that there is a security risk in accepting a self-signed certificate. It only says that you need to accept the certificate in order to continue. Most users, when confronted with dialog boxes that they don't understand, will just click "OK".
1.4 Expired Certificates:The keys embedded in certificates are assumed to have a limited lifetime-- even though they're (supposed to be) large and thus resistant to brute-force attacks, the longer they're used the greater the chance that they have been cracked or that someone has accidentally (or purposefully) revealed them. Beacuse fo this, good security policy dictates that the keys be changed periodically. Thus, X.509 certificates can be set to expire. The server operator is supposed to get a new certificate before the old one expires, and to switch to that new certificate and key. However, not all of them do. When a browser encounters an expired SSL server certificate, it shows a dialog box telling the user that the certificate is expired or the computer's date is wrong. There is no explanation in Netscape or IE of the security risks in accepting an expired certificate.
2.0 MethodologyThe study was conducted by first obtaining a list of web pages that had links to server servers, then connecting to each server to determine it's security. The list of links to servers was obtained by a script that queried a search engine for pages with links to server servers. The script added random words into the query to get the search engine to return links to different secure servers. (see this link for a more detailed explanation of the methods). Once the list of links to secure servers was built, the next step was to query each of the 9754 secure servers to determine their security. 8189 answered, and 8081 of those were able to return certificates. Those servers that returned certificates were used in the study. Of the 8081 servers that returned certificates, 2709 (31.53%) were found to have weak security. 161 (9.84%) had medium security, and 4271 (58.63%) strong security.
2.1 Defining Security Levels
Weak Security Servers:For this study, "Weak" server keys were defined as RSA keys 512 bits and smaller. All servers in this study used RSA for the server public key.A weak server was defined as one having weak public keys, supporting only the broken SSLv2 protocol, having self-signed or expired certificates, or supporting only weak ciphersuites. Almost all servers (99% for SSLv2, 79% for SSLv3, and 75% for TLS1) support at least one weak ciphersuite. Browsers which are configured to use only weak ciphersuites will only be able to use the weak ciphers, making their traffic susceptable to attack. While this study did not attempt to characterize the number of weak browsers, their number is probably significant and would increase the number of weak SSL sessions beyond the 32% of weak servers found in this study. Weak ciphersuites for SSLv2 were defined as:
SSL2_CK_NULL SSL2_CK_NULL_WITH_MD5 SSL2_CK_RC4_128_EXPORT40_WITH_MD5 SSL2_CK_RC2_128_CBC_EXPORT40_WITH_MD5 Weak ciphersuites for SSLv3 were defined as:
SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_RSA_EXPORT_WITH_RC4_MD5 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_EXPORT_WITH_RD4_40_MD5 SSL_DH_anon_WITH_RC4_128_MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA Weak ciphersuites for TLS1 were defined as: TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_RSA_EXPORT_WITH_RC4_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_RD4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA All Anonymous Diffie-Hellman ciphersuites are weak since Diffie-Hellman with no authentication is subject to a Man-in-The-Middle attack. The NULL_WITH_NULL_NULL ciphersuite is not listed since in SSLv3 and TLS, it is not legal to negotiate a ciphersuite of NULL_WITH_NULL_NULL. TLSv1 supports the SSLv3 suites and some new ones added for TLS. None of the suites added for TLS were weak. Medium Security Servers"Medium" security is defined as servers with public keys > 512 bits and medium-security ciphersuites (those with symmetric cipher key sizes greater than 40 bits and less than or equal to 64 bits).Medium ciphersuites for SSLv2 were defined as:
SSL2_CK_DES_64_CFB64_WITH_MD5_1 SSL2_CK_DES_64_CBC_WITH_MD5 SSL2_CK_DES_64_CBC_WITH_SHA SSL2_CK_RC4_64_WITH_MD5 Medium ciphersuites for SSLv3 were defined as:
SSL_RSA_WITH_DES_CBC_SHA SSL_DH_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA Medium ciphersuites for TLSv1 were defined as:
TLS_RSA_Export1024_WITH_RC4_MD5 TLS_RSA_Export1024_WITH_RC2_CBC_MD5 TLS_RSA_Export1024_WITH_DES_CBC_SHA TLS_Export1024_DHE_DSS_WITH_DES_CBC_SHA TLS_RSA_Export1024_WITH_RC4_SHA TLS_Export1024_DHE_DSS_WITH_RC4_SHA
Strong Security Servers"Strong" servers are defined as servers with public keys >= 1000 bits and strong-security ciphersuites (those with symmetric cipher key sizes greater than 64 bits).Strong ciphersuites for SSLv2 were defined as:
SSL2_CK_RC4_128_WITH_MD5 SSL2_CK_RC2_128_CBC_WITH_MD5 SSL2_CK_IDEA_128_CBC_WITH_MD5 SSL2_CK_DES_192_EDE3_CBC_WITH_MD5 SSL2_CK_DES_192_EDE3_CBC_WITH_SHA Strong ciphersuites for SSLv3 were defined as: SSL_RSA_WITH_RC4_MD5 SSL_RSA_WITH_RC4_SHA SSL_RSA_WITH_IDEA_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_FORTEZZA_DMS_WITH_RC4_SHA Strong ciphersuites for TLSv1 were defined as:
TLS_RSA_WITH_RC4_MD5 TLS_RSA_WITH_RC4_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
3.0 Results and DiscussionThe weak SSL servers that this study found were weak because they used only weak 40-bit export-only ciphersuites (27.7% of weak servers), used a 512-bit server key (81%), only used the broken SSLv2 protocol (1.2%), had an expired server certificate (9.9%), or used a self-signed server certificate (2.8%). Most had more than one weakness (which is why the percentages add up to more than 100%). 3.1 40-bit ciphersuites:A significant number (27.7%) of the weak servers discovered in this study use only weak ciphersuites-- the server will not make SSLv3 or TLS1 connections using ciphersuites other than weak ones. (SSLv2 connections using medium or strong ciphersuites do not make a secure server since the SSLv2 protocol is flawed; servers with medium or strong SSLv3 ciphersuites but only weak SSLv3 and TLS ciphersuites were counted as servers with weak ciphersuites.) Small symmetric keys are relatively easy to crack by brute force. Key size is often limited by US export rules. US export rules changed in December 1998 to allow the export of products containing 56-bit symmetric ciphers, and the TLS standard added a number of 56-bit level ciphersuites to take advantage of those export rules. Additionally, there are a number of free SSL servers which implement 56-bit (and better) ciphersuites. Browsers which can use only weak 40-bit level ciphersuites will negotiate an SSL connection as long as there is one or more 40-bit level ciphersuite available from the server. The servers in this study that were judged weak because of weak ciphersuites supported only the weak 40-bit ciphersuites. There is no legal or technical justification for supporting only weak ciphersuites. A criminal who had access to network traffic and was willing to invest $100k or so in a 2000-model Deep Crack machine or a network of PCs could set up a profitable scheme for obtaining credit-card numbers and logins to on-line banking accounts. As Moore's Law drives the cost of computer hardware and chips down, the cost of this type of attack drops significantly every year. Considering the apparent ease with which the perpetrators of the recent Denial of Service attacks against big websites were able to break into many computers to use them to mount the attack, it would be very possible for a criminal group to use the same tactics to set up a distributed key-cracking system using other people's computers.
3.2 Using Only SSLv2:The SSLv2 version of the SSL protocol has serious weaknesses that allow an active attacker (one who can modify traffic between the server and client) to downgrade the ciphersuites to the weakest ones supported by the client. Since that is usually the weak 40-bit export ciphers, it would be possible for most SSLv2-only SSL sessions to be downgraded to a weak ciphersuite and then attacked as a weak ciphersuite.
3.3 Weak Server Keys:Most servers with weak (512-bit) keys also use weak 40-bit ciphersuites-- about 83% of SSL servers use the same strength level of server keys and ciphersuites. While it takes longer to break a weak RSA key, once the attacker has done so, all the SSL traffic to that server can be easily broken. If the attacker has recorded SSL traffic to the victim from before the key was cracked, the attacker can decode most of that too-- all except sessions negotiate with ciphersuites that provide Perfect Forward Secrecy, which are not supported by most servers (the most common SSLv3 ciphersuite that provides PFS is SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA which is supported on 26% of SSLv3 servers). An attack on a weak server key would be to record SSL connections to it while factoring it's key, then using the keying material thus revealed to break all the recorded SSL connections and obtain salable information like credit-card numbers and online-banking accounts. With a secure server that handles many transactions, this could be a profitable attack.
3.4 Self-signed Server Certificate:Self-signed server certificates are often used for testing. Some number of servers with self-signed certificates find in this study are test servers, servers that have recently been set up and are not yet in active use. It's not possible to programmatically determine if a server is a test server or a "real" one. Since all the servers in this study had been around long enough for a web crawler to find them, it's likely that the servers found in this study have been publically available for at least a few days. While there's no direct attack on servers with expired (or self-signed) certificates, they do train users to accept things that they should not accept. This study did not determine how many users, when faced with a dialog box from their browser saying "this server's certificate is not trusted" will still continue with the transaction. Most users, not understanding what "trusted" means in this context, would still hit the "Continue" button. This opens up an attack of setting up a fake site that looks like a valid one, say www.etrade.com, with an expired or self-signed certificate. Using well-known techniques of DNS cache poisoning to divert traffic from the real etrade to the fake site, victims would log in and some number of them would accept the expired or self-signed certificate, and then the criminals running the site would harvest their login/password information and redirect them to the real etrade server.
3.5 Expired Server Certificates:Web servers with expired certificates could be old unmaintained "dead" servers, or secure mirrors of non-secured sites who's operators don't know that there's a secure version also, let alone where the certificate is. It's not possible to programmatically determine if a server is no longer being maintained. As with self-signed server certificates, there's no direct attack on servers with expired certificates but they do train users to accept things that they should not accept.
4.0 Interesting Statistics
Number of hosts surveyed: 8189
Number of servers that returned certs = 8081
Number of weak-secuity servers: 2548 (31.53%)
Number of medium-security servers: 795 (9.84%)
Number of strong-security servers: 4738 (58.63%) servers
Weak servers were weak because:
Expired cert: 254 (9.97%)
Self-signed server cert: 71 (2.79%)
Only does SSL2: 30 (1.18%)
Server key <= 512 bits: 2060 (80.85%)
Weak SSLv3/TLS ciphersuites: 707 (27.75%)
Number of servers with expired certs: 254 (3.14%)
Number that only do SSL2: 30 (0.37%)
Number with self-signed server certs: 71 (0.88%)
Server Certificate Key Sizes:
1024 5653 (69.95%)
512 1870 (23.14%)
768 194 (2.40%)
511 190 (2.35%)
1023 142 (1.76%)
2048 15 (0.19%)
700 2 (0.02%)
950 2 (0.02%)
(all others < .01%)
There's lots more stats on the
the detailed results page.
5.0 Conclusion:Of 8081 randomly-selected secure (SSL) servers, 2548 (31.53%) were found to have weak security. Of those servers, the weakness was because of supporting only weak (40-bit) ciphersuites (27.75%% of weak servers), small (512 bits or less) RSA server keys (80.85%), use of only the flawed SSLv2 protocol (1.18%), expired server certificates (9.97%), self-signed server certificates (2.79%), or a combination of more than one of these weaknesses (which is why the "percentages" are greater than 100%). These weaknesses make the transactions that are protected by these servers easy to attack with modern key-cracking techniques and/or hacking techniques. There is no technical or legal reason to limit secure servers to to using only SSLv2 or to use self-signed or expired certificates. The US export laws that restricted exportable US software to 40-bit symmetric encryption and 512-bit public-key encryption were changed in December 1998, so there is no legal reason to support only 40-bit cipher suites or 512-bit RSA keys. The reasons why so many sites have unnecessarily weak security can only be guessed at. Many sites don't bother to update or patch software, even when it is readily available, until they're forced to do so because someone has broken in. Until then, they are still open to well-known vulnerabilities. This tendency to not update until forced to (the "close the barn door after the horse is gone" approach) means that security software like SSL servers will simply not get updated. Site operators who're constantly busy keeping expanding networks running and putting out fires will put off updating security software, or be told to do so by their management. This means that your sensitive information is at risk with these sites. Your transactions with weak sites be at risk until the operators of the server make updating it a high-enough priority to get it done. One way to do so is to check the strength of the server and complain to the administrators if the server is using weak SSL to protect sensitive information like credit-card numbers or banking or stock trading account logins. 6.0 References:[BXA98]: Bureau of Export Administration docket number 9809-11233-8318-02. http://jya.com/bxa123198.txt [Doligez96]: "I Broke Hal's SSL Challenge". D. Doligez, August 1996. http://pauillac.inria.fr/~doligez/ssl [EFF98]: "Cracking DES". EFF, May 1998. http://www.eff.org/descracker/ [RFC 2459]: "RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile". R. Housley, W. Polk, D. Solo, January 1999. IETF RFC. [SSL3]: "The SSL Protocol Version 3.0". A. Freier, P. Karlton, P. Kocher. March 1996. IETF draft. http://home.netscape.com/eng/ssl3/ [RSA99]: "RSA Crypto Challenge Sets New Security Benchmark". http://www.rsasecurity.com/news/pr/990826-2.html [Wagner97]: "Analysis of the SSL 3.0 Protocol". B. Schneier and D. Wagner, April 1997. http://www.counterpane.com
CopyrightThis paper is copyright © Eric Murray 2000.You're welcome to use part or all of this study as long as you don't pretend that you wrote it and you include my name ("Eric Murray") as the author. |