I'm developing a system consisting of a mobile application and an embedded device that talk to each other. I'm using mbed TLS (formerly known as Polar SSL).
The problem is that the embedded device performs the TLS handshake in about 7 seconds, which is too much for our use case.

  • Better MCU necessary? Changing the MCU (ESP8266) for a more powerful one is the obvious solution. However, could the TLS handshake also be speded up without changing the MCU?

  • Caching maybe? I read about session caching, how much would this speed things up? I have to assume that a device will be controlled by multiple users, so various sessions would need to be cached. I can't waste memory.

Authentication is not a problem, I'm using 1024 RSA. Could other algorithms (such as Diffie-Hellman or ECC) speed things up?

Handshake breakdown

Step by step handshake times:

    . Performing the SSL/TLS handshake:
hello request...0ms
client hello...30ms
server hello...0ms
server cert...0ms
server key exchange...4490ms
cert request...0ms
server hello done...0ms
client cert...0ms
client key exchange...3310ms
verify cert...0ms
client change cipher spec...0ms
client finished...10ms
server change cipher spec...0ms
server finished...0ms
flush buffers...0ms
hs wrapup...0ms
-----------------hs done!------------------
total: 7861
  • 1
    Please have a look at the timing of the handshake to find out at which part the slow down is and which party needs to be faster. Sometimes such issues are already caused by too slowly getting random data. – Steffen Ullrich Apr 5 '16 at 8:05
  • 1
    You're using about 4,5 seconds in the "Certificate Request" stage where the client may send its own certificate. The more usual case is that ONLY the server sends its certificate. Are you even using client certificates? – StackzOfZtuff Apr 5 '16 at 10:40
  • 1
    Assuming that list of messages is correct you are not using plain-RSA; server keyexchange after server cert means DHE or ECDHE (possibly but not necessarily with -RSA), or else RSA_EXPORT which no decent server should use since about 2005. And even if your client cert/key is RSA it makes little sense to me for both certreq and certver to be costly in CPU, unless the client key is stored in some secured fashion that is costly to 'open' (e.g. password-based) and that is done at certreq time (which is reasonable though not absolutely necessary). – dave_thompson_085 Apr 5 '16 at 21:13
  • 1
    After digging a bit on mbedtls functionsI saw that I handling wrong the state, so I was counting the key exchange. I'm sorry for the misleading traces. ( traces updated ) The bottleneck is on the key exchange, where the asymmetric crypto is done isn't it? However reading the specs of TLS 1.2 i found this: The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. If i am right the server key exchange can be avoided just using the public key, i'm getting things right? – podema Apr 6 '16 at 9:10
  • 1
    i changed the key exchange methods to just rsa. It was using diffie hellman. It takes now just a second! – podema Apr 6 '16 at 13:14

The main bottleneck is on the key exchange, where the asymetric crypto is done.

Use rsa key exchange, it is by far the fastest method. This way it only has to compute the client key exchange, avoiding server key exchange calculations. Furthermore you can control client key exchange time by changing the cert size.

| improve this answer | |

Note that although RSA-2048 encryption takes longer than RSA-1024 encryption, RSA-1024 is too close to the size that has been publicly shown to be breakable. Everyone assumes the NSA routinely break RSA-1024 of "interesting" parties, and the price to do it keeps falling until someday soon academics will demonstrate the ability to do it. Last time academics did a demo was in 2009 when they broke RSA-768, so being able to break RSA-1024 today on public cloud (no custom hardware) is feasible IMO.

Note also that without using DHE or ECDHE, all recorded traffic can be decrypted after the fact using the private key for the certificate, even if the certificate is expired and useless. So you must keep the private key of the certificate secret forever.

I would try to benchmark P-256 ECDHE, both from mbedTLS and the one from bearssl-esp8266. Or even Curve25519 ECDHE if you can.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.