Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Scenario

I have many set top boxes that feel sluggish when accessing HTTPS websites. I would like to find out which SSL cipher suites are most appropriate to use for our websites, so that the boxes perform optimally.

Unfortunately the OpenSSL command line tool is not available on it so I cannot benchmark it that way.

In such an environment, how do I go about picking the best cipher suite to use?

share|improve this question
add comment

migrated from crypto.stackexchange.com Dec 19 '13 at 13:04

This question came from our site for software developers, mathematicians and others interested in cryptography.

1 Answer

Generically speaking, performance ought to be measured in a realistic situation, so you should use as client one of these sluggish set top boxes. When you connect to your server, run a network monitor tool on the server (e.g. Wireshark) to get the precise timings of exchanged packets; this will show what cipher suites the client supports (they are listed in the ClientHello message), what the server decides to use (in the ServerHello message), and pinpoint the operations where time is spent.


Performance issues with SSL will occur either during the handshake, or afterwards when actually sending and receiving data.

For the handshake, you may get issues with latency because a SSL handshake is four-way (two roundtrips before client begins to send the actual HTTP requests); however, this occurs only at the beginning of the SSL session. Browsers keep connections open.

At the handshake level, you may get some performance issue related to the asymmetric cryptography, although I don't quite believe it because a set top box which can run a modern Web browser ought to have enough punch to do such cryptography quite efficiently. You may want to make sure that your cipher suite uses a RSA key exchange (i.e. a cipher suite of type "RSA", not "DHE_RSA") because RSA key exchange is very light (computationally) on the client. However, in any case, since connections are kept open and SSL sessions reused, this may matter only for the very first connection from the client to a given server, and should not impact performance in a continuous way.

Another one-time impact is that for the very first handshake, the client must validate the server's certificate, and that can be expensive -- especially if the client must download some intermediate CA certificates, and obtain CRL and/or OCSP responses. You will not be able to change that with a choice of cipher suite. Make sure that your server sends a complete certificate chain to the client.

For continuous sluggishness, the symmetric encryption part would be a more plausible culprit. Roughly said, you want cipher suites which use AES or RC4, not cipher suites which use 3DES. 3DES is known to be slow.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.