SSL optimization and security

I came across this article about home-made HTTPS accelerator systems (basically a HTTPS proxy to be put in front of proper servers), and one important thing seems to be ignored - the encryption algorithm.


edit: this post was updated in 2012.

I don't have servers that require high TPS rates over HTTPS (we use it mostly for  logins and administrative tasks, regular users don't need it), so I usually just use the default settings that come with Apache. Since I mostly deploy on FreeBSD, the default settings are fairly high - Camellia256 is the default with Firefox, AES256 with other browsers (SSL clients can negotiate what algorithm they want). Only occasionally there is an odd deployment that requires SSL for most of the traffic, and the first thing I do for those is tune the algorithm used.

There is much to be said about various cryptographic algorithms and their relative properties - the (sometimes crazy) denizens of sci.crypt will educate you if Wikipedia fails, but in the broadly general case the following statement is true: RC4 as implemented in SSL (and specifically OpenSSL) is as safe as AES, but an order of magnutude faster. If you have specific security requirements that don't fit with the preceeding statement, you also probaly know the details of why you have them. RC4 is a member of the relatively rarely used family of ciphers called stream ciphers. It has come to have a bad reputation since it was improperly used in some protocols but there are no dangers if  it is implemented properly.

The default FreeBSD Apache SSL configuration includes the following CipherSuite line:

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

It has some unfortunate properties: it pulls in all protocols at the start and then it orders them, it allows SSL 2 which is today considered marginally insecure (though in any case better than nothing), it also allows some weak and old "export-friendly" ciphers (again, bad but better than nothing) and finally, it allows the "null" cipher, i.e. unencrypted connections (only if the client specifically asks for it, so it's not very problematic).

I like to simply trim it to the following:

SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW

In this form, it basically says:

  1. First try the RC4+RSA cipher combination
  2. Then try all the other high-grade ciphers (mostly with 256-bit keys; also includes AES)
  3. Then try "medium-grade" ciphers (mostly 128-bit keys)
  4. Then try "low-grade" ciphers (keys smaller than 128 bit, but not the bad "export" ones)

Note that the distinction between "high-grade" and "medium-grade" algorithms is not very significant in practice, and can be compared to wondering if an unassisted swimmer can swim across the Pacific ocean or the Mediterranean sea in one go - yes, the Mediterranean sea is much smaller but still it's very much impossible. Of course you can always find people paranoid enough to demand extremely strong encryption algorithms. Also, some institutions (like banks) require the highest-grade encryption by default as a business practice, to protect themselves from "due diligence" liability.

As well as improving the security a bit, the most important (for my purposes) change this new cipher suite introduces is higher performance. See these ApacheBench2 results for an example:

First, the default configuration:

Server Software:        Apache/2.2.11
Server Hostname: www.xxx
Server Port: 443
SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256

Document Path: /bla.txt
Document Length: 3959 bytes

Concurrency Level: 4
Time taken for tests: 23.410977 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 4342000 bytes
HTML transferred: 3959000 bytes
Requests per second: 42.72 [#/sec] (mean)
Time per request: 93.644 [ms] (mean)
Time per request: 23.411 [ms] (mean, across all concurrent requests)
Transfer rate: 181.11 [Kbytes/sec] received

Then the new one:

Server Software:        Apache/2.2.11
Server Hostname: www.xxx
Server Port: 443
SSL/TLS Protocol: TLSv1/SSLv3,RC4-SHA,2048,128

Document Path: /bla.txt
Document Length: 3959 bytes

Concurrency Level: 4
Time taken for tests: 4.641983 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 4342000 bytes
HTML transferred: 3959000 bytes
Requests per second: 215.43 [#/sec] (mean)
Time per request: 18.568 [ms] (mean)
Time per request: 4.642 [ms] (mean, across all concurrent requests)
Transfer rate: 913.40 [Kbytes/sec] received

Obviously, this server is very underpowered and not very suitable for HTTPS, but it's easy to see that the new configuration is five times faster than the old one. Think of what this means - five times more TPS by changing a single line. This kind of performance benefit should transfer almost linearily to more advanced configurations.

Note that this compares apples and oranges of crypto algorithms - the first example (which is active by default) is 256-bit AES and the second one (after tuning) is 128-bit RC4 (the numbers are key sizes). Also note that RC4 is actually a stream cipher and can be considered internally a "2048-bit algorithm" (operates on a 256-byte pool) and the "128-bit" is only the arbitrary selected key size (key data is derived randomly in this case),  i.e. not the same as key size in block algorithms. Generally, 128-bit block ciphers are faster than 256-bit block ciphers. Testing of 128-bit AES is left as an excercise for the reader :)


#1 Re: SSL optimization and security

Added on 2009-04-17T11:23 by Tobi

It seem you are comparing RC4 with a key length of 128 bit to AES with a key length of 256 bit. Do you mind to post the results for AES-128?

#2 Re: SSL optimization and security

Added on 2009-04-17T11:46 by Ivan Voras

No, I don't have the time currently. I've updated the post to note that 128-bit block algorithms are generally faster than 256-bit block algorithms.

#3 Re: SSL optimization and security

Added on 2009-04-18T16:04 by Johny

Do you think that http://www.discryptor.net/ is secure? THX

#4 Re: SSL optimization and security

Added on 2009-04-18T17:27 by Ivan Voras

There is not enough information on the Discryptor web site to make any kind of conclusion about its security. There is a list of supported ciphers but all ciphers can be used insecurely.

One product that is recommended because it has gone through significant analysis is http://www.truecrypt.org .

Look for information such as this: http://www.truecrypt.org/docs/?s=modes-of-operation to help decide if software is using cryprography in a secure way.

#5 Dark side of SSLv2 and NUL

Added on 2009-04-19T23:07 by kost.com.hr

It's really dangerous to have NUL ciphers enabled and SSLv2. In such configuration it is possible to perform VERY successful MiTM attack. SSLv2 is vulnerable to downgrade attack and together with NUL enabled, it is possible to force all clients for which MiTM is done to use NUL. Therefore, can sniff all traffic in plaintext. Beware! I have written PoC of this in Perl some time ago. If you want, will gladly demonstrate! :)

#6 Re: Dark side of SSLv2 and NUL

Added on 2009-04-19T23:25 by Ivan Voras

Both SSLv2 and eNULL or is eNULL by itself enough?

(I mean - eNULL is of very limited usability anyway...)

(hi, Kost :) )

#7 Re: Dark side of SSLv2 and NUL

Added on 2009-04-19T23:51 by kost.com.hr

Hello Ivan! Both SSLv2 and NUL configured is dangerous (as described). SSLv2 and LOW ciphers are less dangerous, but still dangerous because of mentioned downgrade attack. For example, with CUDA (http://www.nvidia.com/object/cuda_learn.html), takes waaay less time to crack it.  NUL with SSLv3/TLS should be OK , but still not recommended practice. At least, turn off SSLv2 and LOW/NUL ciphers, even  MEDIUM grade ciphers(consider CUDA - for example) if security is your concern . If not, throw away https and use http - you'll get far more better results and users won't get false feeling of being secure :o)

Comments !

blogroll

social