cancel
Showing results for 
Search instead for 
Did you mean: 
JRahm
Community Manager
Community Manager

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.

 

0151T000003d45wQAA.png

 

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.

0151T000003d45xQAA.png

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.

0151T000003d45yQAA.png

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.

0151T000003d45zQAA.png

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.

Comments
Awesome... Very nicely laid out..
jaked_150553
Nimbostratus
Nimbostratus
I have a question.... in the case where both client and server ssl profiles are enabled, do we need a certificate in the server ssl profile?

 

how does encryption/decryption happen in the following scenarios?

 

 

1- there is no certificate in server ssl profile, there is certificate on the server

 

2 - there is certificate in server ssl profile, there is certificate on the server, both the certificates are same

 

3 - there is certificate in server ssl profile, there is certificate on the server, both certificates are different.

 

JRahm
Community Manager
Community Manager
>>I have a question.... in the case where both client and server ssl profiles are enabled, do we need a certificate in the server ssl profile?

 

 

only if your server requires client certificates to negotiate SSL.

 

 

>> how does encryption/decryption happen in the following scenarios?

 

 

>> 1- there is no certificate in server ssl profile, there is certificate on the server

 

 

same as no certificate in your client with a certificate on the BIG-IP for offload.

 

 

>> 2 - there is certificate in server ssl profile, there is certificate on the server, both the certificates are same

 

 

you should not use a server certificate in a client cert role. The server ssl profile is for the BIG-IP as a client to your servers, so you should have a client cert in there.

 

 

>> 3 - there is certificate in server ssl profile, there is certificate on the server, both certificates are different.

 

 

if there is no certificate on the server, then there is no need to re-encrypt from BIG-IP to the server, and therefore no need for a server ssl profile.

 

 

Just for clarification:

 

 

Complete Offload (no ssl to server):

 

client->BIG-IP(client ssl)->server

 

 

Offload & Re-encrypt to server:

 

client->BIG-IP(client ssl)->BIG-IP(server ssl)->server
Nick_128577
Nimbostratus
Nimbostratus
Nice but.... We have both client and server profiles enabled as we are inspecting the traffic as it comes through the F5. Our understanding is that the F5 terminates the secure connection from the outside world and makes a new secure connection internally to the downstream system in this model and that works fine until a very recent patch for WinShock. What we are seeing is that if we allow TLS1.2 externally but remove the capability internally then we are seeing issues with the site from an external prospective. Why is this occurring as surely the F5 should be handling this and not assuming that the downstream system needs to negotiate in the same way?
Ajit
Altostratus
Altostratus

Hello Jason,

 

Can you please re-answer the below question. I think there is some misunderstanding here:

 

How does encryption/decryption happen in the following scenarios?

 

3 - there is certificate in server ssl profile, there is certificate on the server, both certificates are different.

 

Praveen32_33178
Nimbostratus
Nimbostratus

I will try to answer this one,

 

The server ssl profile is for acting as an ssl client. Since, we are talking about Client Authentication here, if the certificate on your node has a server, I'd assume that you need re-enryption to your server too.

 

In addition, in client authentication, the server challenges the client for authentication. The client,in this case the BIGIP authenticates [using its private key] itself by sending a digital signature back to server ( node ). Because, the server now has the clients public key, pre master secrets come into play on the server side of the connection.

 

If the certificates on your server-ssl profile and the server are the same, i would assume there should be an SSL handshake failure.

 

Version history
Last update:
‎17-Nov-2010 07:16
Updated by:
Contributors