My company uses HTTPS to make terminals talk to servers. We optimized as much as we could (using session id and session tickets). Problem is that latency is so high that any HTTP request costs ~4s just to establish secure connection! If we used plain TCP, connection would take place in ~1.5s!

So my question is: is there any way to pre-establish encryption session so that we can pay only TCP connection time?

  • Since you're asking about TLS usage it might be a bit off-topic on SecuritySE. – Arminius Apr 13 '17 at 3:39
  • What's the source of this latency? Is the device too slow at doing RSA/encryption computation, or is it because you have poor network topology/overcrowding? Internet packets travel at cables and fiber optic at about 2/3 the speed of light, which means in ideal network condition you should be able to reach any points on earth in around 200ms. Any network latency above that is something you can optimize without changing the terminals/server endpoints. – Lie Ryan Apr 13 '17 at 5:47
  • Also are you able to use HTTP with persistent connection? – Lie Ryan Apr 13 '17 at 5:50
  • Latency is caused by GPRS. Latency is as high as 700ms. Sometimes 1300ms when signal is poor. – Igor Gatis Apr 13 '17 at 11:00
  • I'm not sure I want TLS. For example: what if I used TCP and encrypted data using AES with a PSK? I'd skip TLS handshake completely. – Igor Gatis Apr 13 '17 at 11:03

Currently a TLS handshake needs at least 2 round trips for the full handshake or one round trip for resuming a previously established session. This means there is currently always round trip overhead with TLS which can heavily impact the connection setup if you have a large round trip time, as it seems to be in your case.

With the new TLS 1.3 this overhead will be greatly reduced up to a 0-RTT handshake if resuming a session. Currently TLS 1.3 is still not fully standardized yet (will be hopefully this year) and even after it is standardized it will probably take several years before it is supported by the majority of client and servers. But, if you need a 0-RTT protocol now and have full control over client and server, then you might start using TLS 1.3 already in your own environment. Even if it is not fully standardized yet it is probably better than designing your own protocol.

For more details see An overview of TLS 1.3 and Q&A which describes both TLS 1.2 handshakes and TLS 1.3 handshakes.

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.