5

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

Edit:
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
Community
  • 1
podema
  • 71
  • 1
  • 5
  • 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 05 '16 at 08:05
  • ESP8266, which is the mcu in use, have a hw rng, so i suppose it is not the source. I associated the slow hs to the mcu horsepower but it is true that i can be a leak i will search for it – podema Apr 05 '16 at 08:08
  • after a little bit of programming i performed the hs by steps and get each step time – podema Apr 05 '16 at 10:27
  • 1
    You're using about 4,5 seconds in the ["Certificate Request" stage](https://tools.ietf.org/html/rfc5246#section-7.4.4) 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 05 '16 at 10:40
  • yup, that's good news, seems that it can be speeded up. i'm doing the test request with CURL, not using certs, not intentionally at least. I'm searching how can i disable this thing in mbedtls (which is the tls framework im using) – podema Apr 05 '16 at 10:45
  • 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 05 '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 06 '16 at 09:10
  • The note of "if the certificate doesn't contain enough information" is targeted at the combination of RSA certificates and `*_RSA_*` cipher suites. ECDHE *may* be faster than your current DH and if you want to live without forward secrecy, you may want to have a look at the RSA cipher suites afterwards. – SEJPM Apr 06 '16 at 12:35
  • 1
    i changed the key exchange methods to just rsa. It was using diffie hellman. It takes now just a second! – podema Apr 06 '16 at 13:14

2 Answers2

2

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.

peterh
  • 2,938
  • 6
  • 25
  • 31
podema
  • 71
  • 1
  • 5
0

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.

Z.T.
  • 7,768
  • 1
  • 20
  • 35