Hi, Currently we only do client-side SSL on the F5. I've been asked if we can encrypt the traffic from the F5 to web servers. I know the F5 can do server side ssl so just wonderered if someone could confirm the follwing steps are correct to do this? Install a certificate on the web servers, a self signed certificate should be OK. Create a server side SSL profile on the LTM. Apply the SSL profile to the Virtual Server It seems very simple, am I correct? Also could this have any impact on the ASM as we are just starting to set this up? Thanks Darren

Yes it is that simple, ensure your Server side SSL profile trusts the Issuer and you are ok. I doubt it affects ASM as that module will inspecting after clientSSL and serverSSL but as I am about to implement ASM too I'll be interested in hearing any other comments too.

I agree it is that simple. In fact you can typically just use the default serverSSL profile. The only time I have created a sepperate profile is if I needed to support Sal client certs being sent to the backend. As for ASM, this will have no effect because the reencrypt doesn't occur until after ASM.

100% correct. It really is that simple. You CAN make it difficult if you like... But remember the trade offs. The biggest advantage of doing offload in the first place is not having to doit to the backend... So the backend doesn't have to do the processing... Of course with longer keylengths you can trade off security with a shorter keylength for the server side... But generally in most environments you're not buying a lot when you re-encrypt... If an attacker can snoop your backend traffic (WHich is what serverside SSL is guarding against), you're already broken... H

As someone who configures and maintains F5 boxes, I'm totally on board with Hamish's statements about re-encrypting not being necessary. With that said though, I also work in an environment where our security team has begun requiring it in certain areas. As long as physical access control is there, it's not a PCI requirement but re-encryption is almost considered a last line of defense in case someone internal goes rogue. Of course, if that's a true requirement, there are still opportunities to minimize the performance impact. As Hamish also mentioned, using a shorter keylength can be a great option. We have an application that cannot support larger than 1024-bit. Since CAs now require 2048 or larger, LTM essentially allowed the application to continue working.

We currently have this same setup where we are doing offloading on the LTM's, then from the LTM's to the web servers we are using the Server SSL functionality. The certs we are using on the Server SSL profile are the defaults. Everything works fine. Something that bothers me though is how this is actually working, for the Server SSL to work, the LTM is essentially acting as an SSL client to the server, correct? So how is the server decrypting the traffic from the LTM if it doesn't have the private key of default cert of the LTM? Thank you

Server-side SSL | DevCentral

24 Replies

Jason_Keating
Altostratus
Mar 25, 2011
Yes it is that simple, ensure your Server side SSL profile trusts the Issuer and you are ok.

I doubt it affects ASM as that module will inspecting after clientSSL and serverSSL but as I am about to implement ASM too I'll be interested in hearing any other comments too.
Steve_Brown_882
Historic F5 Account
Mar 25, 2011
I agree it is that simple. In fact you can typically just use the default serverSSL profile. The only time I have created a sepperate profile is if I needed to support Sal client certs being sent to the backend. As for ASM, this will have no effect because the reencrypt doesn't occur until after ASM.
Hamish
Cirrocumulus
Mar 25, 2011
100% correct. It really is that simple.

You CAN make it difficult if you like... But remember the trade offs. The biggest advantage of doing offload in the first place is not having to doit to the backend... So the backend doesn't have to do the processing... Of course with longer keylengths you can trade off security with a shorter keylength for the server side... But generally in most environments you're not buying a lot when you re-encrypt... If an attacker can snoop your backend traffic (WHich is what serverside SSL is guarding against), you're already broken...

H
Chris_Miller
Altostratus
Mar 25, 2011
As someone who configures and maintains F5 boxes, I'm totally on board with Hamish's statements about re-encrypting not being necessary. With that said though, I also work in an environment where our security team has begun requiring it in certain areas. As long as physical access control is there, it's not a PCI requirement but re-encryption is almost considered a last line of defense in case someone internal goes rogue.

Of course, if that's a true requirement, there are still opportunities to minimize the performance impact. As Hamish also mentioned, using a shorter keylength can be a great option. We have an application that cannot support larger than 1024-bit. Since CAs now require 2048 or larger, LTM essentially allowed the application to continue working.
markj_58101
Nimbostratus
Mar 31, 2011
We currently have this same setup where we are doing offloading on the LTM's, then from the LTM's to the web servers we are using the Server SSL functionality. The certs we are using on the Server SSL profile are the defaults. Everything works fine. Something that bothers me though is how this is actually working, for the Server SSL to work, the LTM is essentially acting as an SSL client to the server, correct? So how is the server decrypting the traffic from the LTM if it doesn't have the private key of default cert of the LTM?

Thank you
- james_lee_31100
  Nimbostratus
  Apr 15, 2016
  Just use default serverside ssl profile, it works fine
- superuser_22978
  Nimbostratus
  Jun 21, 2017
  As F5 works as a full proxy device. Think it like this. When you try to launch a web page are you presenting any cert? No right. When the F5's front end ssl decrypts the traffic. F5 initiates an ssl handshake to the backend server where it gets the cert and public key from the backend server(treat f5 as your laptop here). Now f5 encrypts the traffic with public key offered and backend server decrypts with its private key.
  
  Thank you.
Hamish
Cirrocumulus
Mar 31, 2011
You answered the question yourself. The server can decrypt stuff from the F5 (Client) because the shared session key (That's actually used to encrypt the traffic) is negotiated as part of the key exchange where the server uses it's own private key. The client side key doesn't get involved). The session between the LTM and the server is a completely different TLS (Or SSL) session from the client - LTM connection.

H
markj_58101
Nimbostratus
Mar 31, 2011
OK thanks, I see what you are saying. Now that I think about it it's actually fairly straight forward. The thing that confuses/d me is why you have the cert/key options on the Server SSL profile when the Server itself is providing the cert for encryption?

Thanks
Hamish
Cirrocumulus
Mar 31, 2011
Mutual authentication.

The certs are used not only to provide an initial public/private encryption for the SSL handshake (When they negotiate a shared secret for the data), but also to authenticate the endpoint that presents them. If you have certs on the client side, these can be used to authenticate the client to the server.

H
Joel_Moses
Nimbostratus
Mar 31, 2011
I've only _very rarely_ seen a web server that requires SSL Mutual Authentication for incoming channels that isn't doing _client authentication_ with the presented certificate; it's certainly possible but is extremely uncommon. These servers are typically doing this for Web Services (J2EE/WCF) and aren't meant to be directly used by end-users. I think that the certificate/key field is left in the ServerSSL profile just for this eventuality?
markj_58101
Nimbostratus
Mar 31, 2011
OK great, Thank you for the answers.

Mark