Forum Discussion

Nfordhk_66801's avatar
Nfordhk_66801
Icon for Nimbostratus rankNimbostratus
Jan 23, 2015

Using ServerSSL Profiles

Hi,

 

I am interested in using ServerSSL profiles to secure connectivity from the client to the end host but I have some confusions about the process. Right now our setup looks like this:

 

Two VS Servers:

 

HTTP Server - Has iRule redirect

 

HTTPS Server

 

Pool with HTTP nodes.

 

Client SSL profile assigned, with SSL cert generated from a CA.

 

What I'm thinking is this: Change the pool to HTTPS and assign a serverSSL profile.

 

But don't the servers need to have certs on them too? What cert should I attach to the SSL profile? This is the part I'm a little confused about.

 

I tried reading this: https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14806.html but I still do not fully understand.

 

10 Replies

  • If you want to use HTTPS on the backend, you'll need to set up your web servers to allow for https traffic and set up a certificate on them. Then you'll need the serverssl certificate set on the F5 (and pool members to use port 443).

     

    If you want, you could use self-signed certs internally or a cert from a CA. For the serverssl profile, you could simply assign the default serverssl cert, or you'd have to install an additional one and create a new serverssl profile to use.

     

  • giltjr's avatar
    giltjr
    Icon for Nimbostratus rankNimbostratus

    The server need to have certificates on them, however they do not need to be same certificates that you use in the SSL client profile.

     

    When you do SSL offload and you have and you want to use SSL between the F5 and the servers there are 2 SSL connections:

     

    END USER <--- SSL1 ----> F5 <--- SSL2 ---> Web Server

     

    Between the End User and the F5 the F5 will use the SSL client profile. Here you should use a certificate that is signed by a well known CA.

     

    Between the F5 and the Web server you can use the same certificate, or you could use a self signed certificate. No matter what you do the Web server will need the private and public part of the certificate installed on it. One advantage of using a self signed certificate is that you can make the expiration date as far out in the future as you want and thus you don't need to replace/update the certificate that often if ever.

     

  • In reality, are there any benefits to letting the F5 perform all these functions? Why not just put certs on the servers themselves and let the F5 acts as a pass through?

     

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      If you want to leverage any Layer 7 functionality it will require that the F5 be able to decrypt the SSL traffic. i.e. iRules that use HTTP events.
    • Nfordhk_66801's avatar
      Nfordhk_66801
      Icon for Nimbostratus rankNimbostratus
      What about using the ASM? We are purchasing it soon. Will that cause any issues if I just use the F5 as a passthrough?
    • shaggy's avatar
      shaggy
      Icon for Nimbostratus rankNimbostratus
      yes - ASM is Layer 7 functionality. F5 must terminate SSL in order to decrypt client requests, which is required if you want ASM security policies to inspect those requests. So, at a minimum, a client-SSL profile must be assigned to those virtual servers. A ServerSSL profile will re-encrypt traffic back to the pool member.
  • Some benefits: Certificate management and its cpu intensive. Hence the need to offload to a F5 server.

     

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    One benefit of this, shown through the recent flood of SSL-related security vulnerabilities, is that a lot of applications, legacy applications in particular, could not handle these situations quickly enough, if at all; with SSL-bridging on the F5, you can just fix it on the client side on the F5 through a vendor hotfix or an upgrade to close off the holes, allowing plenty of time and options for yourselves to decide what to do with those applications.

     

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    One simple way to understand how this works is to think like this:

     

    1.

     

    The end-user connects to F5 as the server, and F5 has to present an SSL certificate to prove its identity to the end-user. You need to do everything right here to offer top security.

     

    2.

     

    The F5, as a client, connects to the application server, and the application needs to present an SSL certificate to prove its identity to fulfill the requirement of the SSL protocol.

     

    There is a lot of flexibility in 2, depending on your security requirement. If all you need is only encrypted traffic, you can just use a self-signed certificate on the application server. The default serverssl profile on F5 is configured to ignore certificate checking.

     

  • THi's avatar
    THi
    Icon for Nimbostratus rankNimbostratus

    Passthrough and ASM:

     

    For any intelligent use of ASM, you need to have visibility to Layer 7 traffic on the client requests (and responses).

     

    In case of ssl encrypted traffic from the clients, you need to terminate the client ssl connection at the BIG-IP for the ASM to be able to see the Layer 7 traffic - and function as an application level firewall/protection device. You can the re-encrypt the traffic at the server side of the BIG-IP to the servers if required. Return traffic goes just the reverse.

     

    If you just do the passthrough without ssl termination at the BIG-IP, the ASM cannot see Layer 7 stuff and you could as well revert to use normal L2-4 firewall instead of the ASM application level firewall.