<iframe src="//www.googletagmanager.com/ns.html?id=GTM-MXN9JJ" height="0" width="0" style="display:none;visibility:hidden">

The Smaato Blog

Speed vs. Security: Optimizing Secure Communication

Home » Blog » Speed vs. Security: Optimizing Secure Communication
Posted by Johan Beisser on April 12, 2016
Speed vs. Security: Optimizing Secure Communication

Internet traffic is moving increasingly towards ubiquitous use of secure connections (HTTPS rather than HTTP). Proper handling of these secure connections in order to make them as fast as possible is an area of real concern for anyone running a web-based or mobile business.

For mobile companies like Smaatothe challenge with HTTPS is not encryption itself, but rather the certificate exchange and session key negotiation which imposes additional overhead on a small request over cellular networks. Even high speed 4G/LTE carrier networks can be problematic for the SSL/TLS handshake.

Let’s take a look at a highly simplified HTTPS request from a mobile device:


When a browser or application connects to a HTTPS website, it has to retrieve and verify the certificate (public key) from the server. Once the certificate has been retrieved, the application then verifies the validity against the Certificate Authority (CA) keychain. Modern operating systems, a few browsers (Firefox, for example), and all mobile devices have a CA key store to authenticate the certificate - so once the key is acquired, it's verified quickly.

For the client, the steps are:

  1. Connect to the server.
  2. Get the public certificate from the HTTPS server.
  3. Verify the certificate is valid through the local keychain.
  4. Negotiate a transport protocol with the server.
  5. Issue the pre-session-key to the server.
  6. Calculate and then verify the session key with the server.
  7. Complete the actual HTTP request.

Steps 1 to 6 cover the basic TLS/SSL handshake. However, requesting Google with OpenSSL in client mode shows much more:

~ $ openssl s_client -connect www.google.com:443
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
      i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA  
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
No client certificate CA names sent
SSL handshake has read 3240 bytes and written 456 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol : TLSv1
    Cipher : AES128-SHA
    Session-ID: 771A0E075DF1FB310B4DF40C0D70AFE0357B8981B075E8AB48FEF9FA5B76FEA9
    Master-Key: 930E84033ACAB4D9C27C5E5F99700CF65EB61BD2656C5CE3AB58A10C570D75E4AD6962452BF17B4063CEFE750D3693E
    Key-Arg : None
    Start Time: 1458336832
    Timeout : 300 (sec)
    Verify return code: 0 (ok)


Of the 3240 bytes OpenSSL received during the handshake, 2048 bits (256 bytes) were the public certificate for Google. The client doesn’t send much information, as it doesn’t need to send a certificate back to the server. If it has to authenticate the requested certificate, it does so against its own keychain and checks the certificate up until it finds the CA root certificate - GeoTrust in this case.

Having finished the first part of the handshake, the client generates a random key, encrypts it with the server’s public key (the retrieved certificate), and sends this to the server. The server and client now use that key to calculate the session key (called Master-Key). In our example, the session uses AES128-SHA as a symmetric transport encryption and authentication hash. The use of a smaller, random, and calculated symmetric key (Master-Key) ensures the transport is secure enough for the short lifetime of the session and easily decrypted by both sides.

In an ideal network, with an ideal TCP packet payload of 1400 bytes, this exchange represents between 2 and 4 packets being sent to the device. Cellular data is high latency and “lossy”, so retransmissions due to dropped packets and missed TCP windows are expected. If the requested endpoint is on the other side of the country or across an ocean, users experience noticeable delay waiting for the handshake to finish. However, once the connection is established, and the handshake is finished, the connection has a reusable session key to that endpoint, which by default is valid for 300 seconds (5 minutes). When the session key expires, the device has to retrieve the public certificate again, and negotiate an entirely new session.

This additional latency from distance during TLS handshake is very noticeable using cURL to request an HTTPS site:

Let’s examine a call to Smaato’s EMEA publisher endpoint in Dublin, Ireland from San Francisco, California (time is measured in seconds):

~ $ curl -w '\nLookup time:\t%{time_namelookup}\nConnect
time:\t%{time_connect}\nSSL/TLS time:\t%{time_appconnect}\nPreXfer
time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal
time:\t%{time_total}\n' -o /dev/null -s https://test-IRE

Lookup time:    0.031
Connect time:   0.188
SSL/TLS time:   0.728
PreXfer time:   0.728
StartXfer time: 0.887
Total time:     0.887


For comparison, let’s examine the same request to Smaato’s East Coast endpoint:

~ $ curl -w '\nLookup time:\t%{time_namelookup}\nConnect
time:\t%{time_connect}\nSSL/TLS time:\t%{time_appconnect}\nPreXfer
time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null -s https://test-US

Lookup time:    0.005
Connect time:   0.078
SSL/TLS time:   0.369
PreXfer time:   0.369
StartXfer time: 0.444
Total time:     0.444


The key exchange and handshake takes the bulk of the request time in both requests. Once the encrypted transport is established, the HTTP request passes quickly, taking between 75 and 150ms to complete. Again, the closer the physical endpoint is, the faster the handshake is handled, and the faster the request will complete.

So, given this challenge SSL/TLS presents in mobile, what are the options to mitigate them?

First, get the SSL/TLS certificate request endpoint as close as possible to the client device. With a Content Delivery Network (CDN) it would be called edge caching: speeding the delivery of images, javascript, text, or other data from the nearest point to the client. Edge caching not only improves the customer experience, it also improves Distributed Denial of Service (DDoS) immunity by distributing the request load over a wider area and larger number of routes and nodes.

In this case, edge caching is being used as a form of simple HTTPS acceleration - the closer the requested endpoint is to the client, any  extra delay due to the key request and handshake should be less noticeable.

At each of these Points of Presence (PoP), there’s the benefit of a faster handshake, combined with a large pool of available connected sessions carrying data back to the load balancers in front of the application itself.


Timings are merely to illustrate the difference.
1. Normal HTTP request.
2. HTTPS request of the same data to the same endpoint.
3. Request to the PoP, then through the pre-existing session pool to the load balancer.


Secondly, it’s important to extend the session key timeout. For mobile, caching the session key and permitting resumption may give the performance required after the first key exchange. Setting the session timeout to 3600 seconds (1 hour) will mitigate the key exchange impact, so long as the mobile device stores the session keys and doesn’t preemptively expire them. There’s still some compromise: at millions of transactions per hour, the session keys will sit in the PoP’s RAM, and without some kind of ability to distribute session IDs and their keys between all PoPs, there’s a chance the session will not resume if the device moves or Internet routes change which PoP is nearest.

Thirdly, while the certificate size is a factor in an HTTPS request, reducing its size to under 2048 bits isn’t an option. The largest size for reasonable performance on current cellular networks may be 4096 bits, but to maintain performance for mobile applications and devices where throughput and speed are important, the fewer bytes transported the better. Any reasonable Certificate Authority will not sign a certificate (key) that’s less than 2048 bits, and the minimum size will go up again in the future.

Lastly, the choice of TLS cipher suite initially appears to be a problem for key exchange and session negotiation. In practice, it barely affects SSL/TLS performance or throughput. For the HTTPS acceleration endpoints, the ability to distribute established session ID and session keys between the PoPs, combined with a long session lifetime, will effectively eliminate additional public key request delays. Even without distribution, TLS session resumption will cut delays for requests to the same PoP. Changing or restricting the transport cipher-suites don’t significantly affect client experience.


Suggested links:
For an extremely in-depth analysis of real world TLS/SSL handshake and requests:

The CA/Browser Forum recommendations on certificates for HTTPS/TLS:

Written by Johan Beisser

In his role as Product Architect Johan helps ensure that the Smaato Platform and its underlying structures accomplish the overall goal of speed, security, and efficiency.

Want the latest in mobile advertising monetization strategies & ideas in your inbox? Subscribe today!