“There’s an old expression about falling off a horse. You get back on and you ride that bad boy into town.”– Brock Lesnar
One frustrating reality of the internet is that we live in an age filled with bad actors. These sneaky agents might be anyone; foreigners halfway around the world, corporate spies, or even a kid down the block with too much time on his hands.
As a responsible developer or IT professional, you have little choice but to use TLS (Transport Layer Security) to secure connections between your IoT devices.
However, initiating a TLS session involves a fair amount of back and forth protocol overhead.
The good news is that you may not have to pay that price every time you connect; the TLS protocol provides a way to “get back on the horse,” and to resume an internet session that was created earlier.
Why Use TLS Session Resumption?
Resuming a TLS session can be especially useful when it comes to embedded IoT systems. Resources (and processing speed) in IoT devices are often constrained, so every bit of efficiency you can scrape together will be well worth the effort.
TLS Session Setup Overhead
Let’s take a moment to review what it takes to actually establish an encrypted connection with SSL/TLS. Setting up a TLS session requires a rather involved series of handshake steps between your device and its host.
Note: Our purpose today is not to do a deep dive into the details of how this negotiation works; however—if you’re incurably curious—while the rest of us gallop onward, you can check out a few side trails. We’ve considered some security issues (and how we’re tackling them) in recent articles like Peer Verification: Getting to the Root of the Matter and Introducing wolfSSL: Serious Updates to Our Security Suite. For the super-detail oriented, this fine interactive example of a TLS v1.2 connection can take you right down to the byte level of establishing a typical session. You could even dig into NetBurner’s NNDK 3.3 detailed software documentation.
As you can see from the TLS v1.2 Handshake illustration, there is a good deal of protocol information, cipher selection, number crunching and “back-and-forth” traffic required to establish a TLS-secured session. When you consider the total amount of data sent back and forth, the calculations required by both client and server, and the fact that two complete round-trip exchanges must occur before any actual data can be sent, you can see that starting from scratch every time is costly, both in time and in compute power.
Two Methods of TLS Session Resumption.
They say two heads are better than one, and likewise, so are two different ways to approach resuming your TLS session.
The TLS v1.2 protocol provides two alternative methods of session resumption; Session IDs and Session Tickets. The official specification for Session IDs can be found in RFC 5246, and Session Tickets are defined in RFC 5077.
Thankfully, NetBurner devices support both methods, either as clients or servers. You configure your device to be a client or a server by calling either SSL_accept() (in the case of a server) or SSL_connect() (to initiate a connection as a client). Don’t worry, we provide a plethora of examples for both clients and servers to get you started.
Using Session IDs
Session IDs provide one of two possible shortcuts to resuming a previous TLS session quickly and with minimal overhead. Session IDs are the original design used for resuming SSL sessions, and they are still used by TLS. The following is a quick overview of how they work.
Let’s assume the server supports session IDs and is prepared to offer this feature during a TLS connection. The server will put a non-zero value in the Session ID field of its ServerHello message. If the client wishes to be able to resume a previous session later, it will store this value and then insert it into the Session ID field of its ClientHello.
When the server sees that particular session ID value, it checks to see if it still has the necessary information for the session saved in its session resumption cache. If it does, it can immediately resume the previous session.
You might think of this as kind of like opening an account with your stable manager. It may take you a while to set up the account when you rent your first horse, but next time, all you have to do is flash your ID. They’ll pull up your information in their system, and you’ll be back in the saddle again quickly.
Using TLS Session Tickets
Session tickets are somewhat more complex, but they offer an important advantage. They shift the burden of remembering details of a prior session from the server to the client.
As you might imagine, if your embedded system is acting as a server, it may not have the luxury of “deep pockets” in the memory department. Conserving memory is especially important if your embedded server has a lot of clients to deal with.
Using session tickets is a slick trick that gets each client to handle its own portion of the session resumption memory requirements. Here’s how it’s done:
The client lets the server know it supports tickets by sending an empty Session Ticket extension in its ClientHello message. If the server supports session tickets, it will encrypt all the session details and send that information back to the client as a Session Ticket extension to the final TLS handshake.
Session ticket information includes the complete session state (the master secret negotiated between the client and the server and the cipher suite used). This state is protected by encrypting it with a key known only to the server.
Provided that the client stores the ticket, it can later resume the TLS session by sending it back to the server. The server can then get all of the necessary information about the previous session from the ticket and restart the session.
Think of it this way: Maybe you’ve stabled your horse overnight. Using a session ticket is kind of like turning in your claim-check at the stable so they’ll get you back on your horse quickly. They don’t need to look you up in the system when you come back. Everything they need is right on your claim-check.
What Happens if a Session Can’t Be Resumed?
It’s important to note that every client must be prepared to go through a complete new session negotiation. When your client attempts to resume a session, it’s possible that the server response may be—in effect—“Heck with you, and the horse you rode in on!”
But, why might a server force a completely new session negotiation?
Some servers may have a limited software implementation, and simply may not support one or both kinds of TLS session resumption. A server might have had a traffic overload since the last communication with the client, and its cache may no longer contain the session information pertaining to that ID. The most common reason of all, however, is that IDs and tickets simply expire (and let’s be glad they do!). If a client tries to resume a session after its expiration, it will need to go through the negotiation process all over again.
Session IDs vs Session Tickets: Pros and Cons
Generally speaking, session tickets are preferred as they are more secure then their session ID counterparts. However, that’s not always the only consideration that needs to be made (though we’d argue it is the most important).
Session IDs hail back to SSL days and are the simplest, lowest overhead method from the client perspective. When clients are IoT devices with limited compute horsepower and not a lot of memory, it’s good to have a high capacity central server that can store lots of session ID data.
However, if you have many IoT devices contacting a central server with limited resources, session tickets might be optimal, because each IoT device only needs enough memory to store one ticket from its last session. The server doesn’t need to remember session IDs with all their associated data from a whole stable of different devices.
A Few Words About Session Security
Just as you can only ride one horse for so long, good security comes with time constraints. Long session gaps can give bad actors time to hack into a session and cause trouble. This is why session IDs and session tickets both have security timeout settings that are dictated by the server. When an ID or a ticket expires, the server intentionally flushes cached session data and forces a complete new session handshake when the client initiates the next contact.
Depending on your specific application, and how important the history of your network interaction may be, you may want to forego TLS session resumption altogether. If your IoT devices check in with a server on only an occasional basis, it may be both reasonable and preferable from a security standpoint to simply accept the overhead of setting up a new session each and every time.
NetBurner Supports Both ID and Ticket Methods
As we’ve written about recently, the latest NetBurner software releases have been rocking the security scene. The highly regarded wolfSSL SSL/TLS and SSH Security Suite is now included with all NetBurner development kits in the NetBurner 3.3 release at no additional charge, and will soon be available in NNDK 2.9.3 as well. With this latest software release, all of our products (except the MOD5213 and the SBL2e series) support both ID and Ticket based session resumption, and you don’t have to do anything special to make either method work.
But wait! That’s not all! While a specific release date has not yet been set, NetBurner expects to offer TLS 1.3 support in the near future.
NetBurner Support: You’ve got it!
Everyone needs a little hand-holding from time to time. If you really need to do something different or special (for example, only support certain TLS cipher suites), you can drop your comment or question below. If your need is more urgent, hit us up with an email: firstname.lastname@example.org. We’ll go out of our way to answer your questions and hook you up with the right solution.