tls slow?

[pol delgado martín]

Hi,

I'm developing a device that must have https server.

When acting as a server (tls esp-open-rtos example) the tls  hs lasts about 7s (cert change to a 1024 rsa one). 

Is it an esp8266 limitation? can it be speeded up? 

Thanks!
Pol 

[pol delgado martín]

Maybe using some other algorithm for the authentication may speed up things, searching for it

[pol delgado martín]

After a little research rsa is the fastest.

I modified the tls_server example in order to perform the handshake step by step (i can provide the source if it has to be useful for the project or for someone).

This way i can trace the bottleneck:

. Performing the SSL/TLS handshake: client hello...0 server hello...20 server cert...0 server key exchange...10 cert request...4480 server hello done...0 client cert...0 client key exchange...0 verify cert...3310 client change cipher spec...0 client finished...0 server change cipher spec...10 server finished...0 flush buffers...0 hs wrapup...0 hs over...0 ------------------------------------------- -----------------hs done!------------------ ------------------------------------------- total: 7850

can cert request be avoided in mbedtls ? i already added this line (tough it's the default config)

  mbedtls_ssl_conf_authmode ( &conf, MBEDTLS_SSL_VERIFY_NONE );

 

El lunes, 4 de abril de 2016, 11:36:30 (UTC+2), pol delgado martín escribió:

[Alex Stewart]

That seems very odd.. Unless I'm misunderstanding things, I don't see any reason why sending the cert request should take any time at all.  There's no calculation of any kind (or even waiting on the client, etc) involved in that step of the TLS negotiation (and looking at the code, setting `authmode == MBEDTLS_SSL_VERIFY_NONE` should cause the routine to bail out and return before doing anything anyway..  I think you should be able to see this if you turn on mbedtls' debugging messages to level 2 or above (`mbedtls_debug_set_threshold(2)`))..

Are you sure you aren't somehow counting time spent in the key exchange stage as being part of "cert request" instead?

If the cert request step really is taking that long then it seems to me there's really something wrong and it's probably a bug somewhere in mbedtls that we should dig into..

--
You received this message because you are subscribed to the Google Groups "esp-open-rtos mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esp-open-rto...@googlegroups.com.
To post to this group, send email to esp-op...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/esp-open-rtos/84f441b5-919c-4b6d-9c77-b383487847c3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[pol delgado martín]

After digging a bit on mbedtls functions (ssl_handshake_server_step ()) I saw that I handling wrong the state, so I was counting the key exchange. you are basically right, I'm sorry for the misleading traces.
The bottleneck is on the key exchange, where the asymmetric crypto is done isn't it?  (Sign and decrypt)
I'm afraid if that's the bottleneck that it's a silicon wall. Is it fast for you? 
Tomorrow I will upload the fixed traces. And I will continue the hunt.
Some crazy idea if the whole hs cannot be speeded up is to make dumb api calls at the start of the client so next calls can use session ressumption (avoiding rsa)

[pol delgado martín]

from: Fogood

No worries.. at least it makes a bit more sense now..

It's likely that at least some of this is just inevitable with the hardware we have to work with, but there may still be some ways we can improve the situation.  The addition of mbedtls to esp-open-rtos is still fairly recent, and I have to admit I haven't had a chance to play around much with it in that context..  I was planning to get into it for one of my projects soon, though.  If I have a bit of spare time I'll try digging into things and see if I can help out, but it sounds like you're on the right track, at least..

I wouldn't be surprised if the ESP8266 actually has some hardware features which could improve crypto performance which our mbedtls implementation isn't using but theoretically could.  Unfortunately, a lot of that sort of info is locked away in the proprietary Espressif stuff, and we may have to reverse-engineer it out..  It would actually be interesting to see how fast the Espressif SDK stuff handles TLS negotiation..  If it's significantly faster, then we know there's some secrets to be discovered.  If not, then we may just have to optimize what we have as best we can..

[pol delgado martín]

As i said, there are the fixed traces:

ip:192.168.1.55,mask:255.255.255.0,gw:192.168.1.1

  . 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: 7860

Relating to esp capabilities i will implement the tls server in the oficial sdk. I will give numbers when ready.

Aside from that and after reading a bit, tls 1.2 specs say 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, so... time to figure out how, it will double the speed of the whole hs.

[pol delgado martín]

Solved!

. Performing the SSL/TLS handshake:

  hello request...0ms

  client hello...20ms

  server hello...10ms

  server cert...0ms

  server key exchange...0ms

  cert request...0ms

  server hello done...0ms

  client cert...0ms

  client key exchange...1240ms

  verify cert...0ms

  client change cipher spec...0ms

  client finished...0ms

  server change cipher spec...0ms

  server finished...0ms

  flush buffers...0ms

  hs wrapup...0ms

-------------------------------------------

-----------------hs done!------------------

-------------------------------------------

total: 1290

I used wireshark to monitor what's happening in tls. as i said it was sending a server key exchange method, when it's not needed, it was using diffie hellman.

I just unabled every key exchange method except rsa, which is the fastest, and its fast now.

Even if it's more insecure maybe it should be the default, since changing the algorithm increases a lot the hs time, too much for a lot of applications.

Furthermore other methods can be enabled manually in a controlled way.

Toughts?

I can commit mbedtls/config.h if you wish.

El lunes, 4 de abril de 2016, 11:36:30 (UTC+2), pol delgado martín escribió:

[pol delgado martín]

PS: about what Foogod said of speeding up mbedtls, we should check if someone have available an implementation of a tls server with the official sdk. and check if it is any faster, if i get a working implementation i will try.

El lunes, 4 de abril de 2016, 11:36:30 (UTC+2), pol delgado martín escribió:

[Alex Stewart]

Well done!  This is really useful info..

If I understand things correctly, whether or not it needs to do the server key exchange will depend not only on the algorithms chosen but also on the certificate in use and what information it contains, so the key exchange method that's fastest for one certificate may not be the fastest for another..

We should also ensure that whatever default configuration we provide for mbedtls is not subject to known attacks, as there have been a lot of cracks discovered in a lot of the algorithms lately, and reducing the ability of the server/client to choose different options may have some real security implications..

In my opinion, the default configuration for mbedtls should be the most secure one we can devise, and performance should be a secondary concern.  We can provide documentation on how people can change the config to improve performance (with appropriate warnings about the security implications) if they choose to.  Weakened crypto should never be the default, however:  It should always be something somebody has to deliberately choose to do.

That being said, I do still intend to do some looking into the key exchange code and see if there are possibly some ways to speed it up on ESP8266..  It's possible with a bit of work people may not need to make that choice as often, which would always be best..

--
You received this message because you are subscribed to the Google Groups "esp-open-rtos mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esp-open-rto...@googlegroups.com.
To post to this group, send email to esp-op...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/esp-open-rtos/c430e688-6521-4e96-ab1b-90f99ccec41c%40googlegroups.com.

[Angus Gratton]

Hey Pol,

On Wed, Apr 06, 2016 at 06:26:06AM -0700, pol delgado martín wrote:
> Solved!
> . Performing the SSL/TLS handshake:
> hello request...0ms
> client hello...20ms
> server hello...10ms
> server cert...0ms
> server key exchange...0ms
> cert request...0ms
> server hello done...0ms
> client cert...0ms
> client key exchange...1240ms
> verify cert...0ms
> client change cipher spec...0ms
> client finished...0ms
> server change cipher spec...0ms
> server finished...0ms
> flush buffers...0ms
> hs wrapup...0ms
> -------------------------------------------
> -----------------hs done!------------------
> -------------------------------------------
> total: 1290

Nice work, I had not thought that much of an improvement would be possible!

Could you please post your mbedlts/config.h as a diff[1] on this mailing list? I'm not certain about merging it (more or less for the reasons Alex mentioned), but I'd like to take a look at exactly what needed changing to see this speedup.

If you're able to post some wireshark captures online somewhere for download as well, I'd love to take a peek at those. :)

Angus

[1] I mean the lines from the output of 'git diff' or 'git show' that indicated what needed changing to get this speedup.

[pol delgado martín]

Sure!

I attach to this message both the captures and the diff. 

I basically changed config.h so only rsa key exchange based cipher suites are used. This way i avoid making crypto on server hello.

As i said above all of this is with 1024 rsa only =( .

With 2048 it take about 8s, decrypt with the 2048 private key is costly for esp. I attached a capture too.

1024 is somehow compromoised, at least having mbedtls available (and self signed certs, in my case) i can order the esp to gen its own certs every day so 1024 length can be acceptable.

I understand what you say, and it is true that a lot of attacks where discovered recently, i was thinking only in avoid people's problems (it take too long for a hs), but maybe better be secure by default, so for every change to performance you have to value the tradeoff and your usecase.

At least the info rest here for future users =)

If you have feedback for the 2048 case it will be apreciated!

diff:

476c476

< #define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED

500c500

< #define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED

520c520

< #define MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED

545c545

< #define MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_RSA_PSK_ENABLED

599c599

< #define MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED

624c624

< #define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED

648c648

< #define MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED

672c672

< #define MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED

696c696

< #define MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED

---

> //#define MBEDTLS_KEY_EXCHANGE_ECDH_RSA_ENABLED