SSL Profiles Part 1: Handshakes

Jason Rahm, 2019-15-05

This is the first in a series of tech tips on the F5 BIG-IP LTM SSL profiles.

1. SSL Overview and Handshake

2. SSL Certificates
3. Certificate Chain Implementation
4. Cipher Suites
5. SSL Options
6. SSL Renegotiation
7. Server Name Indication
8. Client Authentication
9. Server Authentication
10. All the "Little" Options

SSL, or the Secure Socket Layer, was developed by Netscape back in the ‘90s to secure the transport of web content. While
adopted globally, the standards body defined the Transport Layer Security, or TLS 1.0, a few years later. Commonly interchanged
in discussions, the final version of SSL (v3) and the initial version of TLS (v1) do not interoperate, though TLS includes the
capabality to downgrade to SSLv3 if necessary. Before we dive into the options within the SSL profiles, we’ll start in this installment
with a look at the SSL certificate exchanges and take a look at what makes a client versus a server ssl profile.

Server-Only Authentication
This is the basic TLS handshake, where the only certificate required is on the serverside of the connection. The exchange is shown
in Figure 1 below. In the first step. the client sends a ClientHello message containing the cipher suites (I did a tech tip a while back
on manipulating profiles that has a good breakdown of the fields in a ClientHello message), a random number, the TLS version it
supports (highest), and compression methods. The ServerHello message is then sent by the server with the version, a random
number, the ciphersuite, and a compression method from the clients list. The server then sends its Certificate and follows that with
the ServerDone message. The client responds with key material (depending on cipher selected) and then begins computing the
master secret, as does the server upon receipt of the clients key material. The client then sends the ChangeCipherSpec message
informing the server that future messages will be authenticated and encrypted (encryption is optional and dependent on parameters
in server certificate, but most implementations include encryption). The client finally sends its Finished message, which the server
will decrypt and verify. The server then sends its ChangeCipherSpec and Finished messages, with the client performing the same
decryption and verification. The application messages then start flowing and when complete (or there are SSL record errors) the
session will be torn down.
Question—Is it possible to host multiple domains on a single IP and still protect with SSL/TLS without certificate errors? This
question is asked quite often in the forums. The answer is in the details we’ve already discussed, but perhaps this isn’t immediately
obvious. Because the application messages—such as an HTTP GET—are not received until AFTER this handshake, there is no
ability on the server side to switch profiles, so the default domain will work just fine, but the others will receive certificate errors.
There is hope, however. In the TLSv1 standard, there is an option called Server Name Indication, or SNI, which will allow you to
extract the server name and switch profiles accordingly. This could work today—if you control the client base. The problem is most
browsers don’t default to TLS, but rather SSLv3. Also, TLS SNI is not natively supported in the profiles, so you’ll need to get your
hands dirty with some serious iRule-fu (more on this later in the series). Anyway, I digress.

Client-Authenticated Handshake
The next handshake is the client-authenticated handshake, shown below in Figure 2.
This handshake adds a few steps (in bold above), inserting the CertificateRequest by the server in between the Certificate and
ServerHelloDone messages, and the client starting off with sending its Certificate and after sending its key material in the
ClientKeyExchange message, sends the CertificateVerify message which contains a signature of the previous handshake messages
using the client certificate’s private key. The server, upon receipt, verifies using the client’s public key and begins the heavy
compute for the master key before both finish out the handshake in like fashion to the basic handshake.

Resumed Handshake
Figure 3 shows the abbreviated handshake that allows the performance gains of not requiring the recomputing of keys. The steps
passed over from the full handshake are greyed out.
It’s after step 5 that ordinarily both server and client would be working hard to compute the master key, and as this step is
eliminated, bulk encryption of the application messages is far less costly than the full handshake. The resumed session works by
the client submitting the existing session ID from previous connections in the ClientHello and the server responding with same
session ID (if the ID is different, a full handshake is initiated) in the ServerHello and off they go.

Profile Context
As with many things, context is everything. There are two SSL profiles on the LTM, clientssl and serverssl. The clientssl profile is
for acting as the SSL server, and the serverssl profile is for acting as the SSL client. Not sure why it worked out that way, but there
you go. So if you will be offloading SSL for your applications, you’ll need a clientssl profile. If you will be offloading SSL to make
decisions/optimizations/inspects, but still require secured transport to your servers, you’ll need a clientssl and a serverssl profile.
Figure 4 details the context.
 Conclusion
Hopefully this background on the handshake process and the profile context is beneficial to the profile options we’ll cover in this
series. For a deeper dive into the handshakes (and more on TLS), you can check out RFC 2246 and this presentation on SSL and
TLS cryptography. Next up, we’ll take a look at Certificates.

F5 Networks, Inc. | 401 Elliot Avenue West, Seattle, WA 98119 | 888-882-4447 | f5.com

F5 Networks, Inc. F5 Networks F5 Networks Ltd. F5 Networks

Corporate Headquarters Asia-Pacific Europe/Middle-East/Africa Japan K.K.

info@f5.com apacinfo@f5.com emeainfo@f5.com f5j-info@f5.com

©2019 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other
countries. Other F5 trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of
their respective owners with no endorsement or affiliation, express or implied, claimed by F5. CS04-00015 0113