SSLO HTTPS conversion to HTTP for NGFW inspection

[Konstantinos_Be]

Hi all,

I am new to the bigip SSLO and I was playing around it in order to see if I can enhance my NGFW visibility instead of moving to a bigger box.

The BIGIP has been moved as the default gateway for all users and acts as a transparent proxy. All users have been provisioned the CA certificate and exceptions for pinned and sensitive sites have been provisioned and working as intended.

The main idea is that I want to decrypt HTTPS traffic and send it over a Layer2/3 path via the NGFW in order to examine traffic and then re-encrypt it before been sent over to the internet.

I have everything working as intended except the HTTPS-to-HTTP-to-HTTPS.

Is this something which can be done by the SSLO?

Thank you

Konstantinos

[Stephan_Schulz · Accepted solution]

Hi,

this is the use case for which the SSLO is build for, so yes it is (easy) possible to do this. In this case, the NGFW is just a service (inspection) device and SSLO will forward traffic based on your policy. There is one thing to consider in how to positioning the SSLO and NGFW. Is this NGFW the internet facing device with NAT, VPN, etc? If yes, it is a bit more complex as you can't move the device into the inspection zone completely.

From a SSLO perspective (best prectise) all inspection devices are hidden and isolated within a dedicated inspection zone and only the SSLO can forward traffic to them. It would be best to use a separate or a virtual instance of your NGFW as inspection device. Otherwise you can use PBR to steer the the traffic.

client --> (https) SSLO --> (http) NGFW --> (http) SSLO --> (https) NGFW --> (https) internet

The SSLO itself can be integrated as a L2 or a L3 device and it can work as a transparent or an explicit proxy. This really depends on your architecture or use case. You can find more details here: https://clouddocs.f5.com/sslo-deployment-guide/

Cheers
Stephan

[Leslie_Hubertus]

@Konstantinos_Be - I'm going to mark Stephan's answer as an Accepted Solution so other users can find it easily in the future. Please let us know if this didn't answer your question, OK? 🙂

[Konstantinos_Be]

Hi @Leslie_Hubertus ,

I can understand the "accept" criteria, however, I am seeing traffic as encrypted passing through the NGFW.

Do I need an iRule in order to decrypt it before been sent?

Thank you

Best Regards

Konstantinos

[Leslie_Hubertus]

That's a follow up for @Stephan_Schulz - who I think is already offline for the day, but will hopefully come back tomorrow to reply. 

[Stephan_Schulz]

Hi,

no, there is no additional iRule needed to decrypt the traffic, but maybe we should go back one step and verify how you have integrated the solution. I understand that the SSLO is integrated in L3-mode and it is behaving as a transparent proxy. How is the service for NGFW configured? Is it a L2 or a L3 device?

In general, the SSLO will decrypt and forward traffic based on your security policy in combination with any dynamic service chain (see pictures below).

With the security policy you define your criterias for a specific traffic type (i.e. URLs) and the action (allow, drop etc.). You can also configure if this traffic type should be decrypted or not and to which service chain it should be forwarded.

• Bypass means no TLS/SSL decryption
• if a service chain is selected, SSLO will forward the traffic to all devices in this chain

You can configure different chains to involve different inspection devices in different order etc. 

To understand, why you are seeing encrypted traffic on your NGFW it is important to understand at which stage it has seen the traffic. Remember my previous answer, I don't know yet, but I assume your NGFW will see the traffic twice.

If you see the traffic outgoing from the SSLO to the NGFW (you can verify this with tcpdump on the SSLO) within the inspection zone, then you should verify your security policy and the matching criteria for the traffic. You can also see the classification result in /var/log/apm (you should enable debug-logging for trouble shooting).

Cheers
Stephan

[Konstantinos_Be]

Hi Stephan,

I fully understand what you just described and thanks for the nice illustrations.

I have configured the NGFW as a L3 service using the provided IP addresses (even through I cannot understand why I cannot use other private IP addresses).

The L3 service can be viewed below:

The configured security policy is the below:

The SSL configuration is the below:

The NGFW is deployed in the LAB as a service only. Traffic after the service chain is forwarded from the BIGIP SSLO to the internet router and NATted for internet access.

The NGFW configuration is pretty straighforward as it can be seen below:

Am I missing something?

Thank you

Best Regards

Konstantinos

[Stephan_Schulz]

Hi Konstantinos,

actually it looks good, so there must be something different... And btw. you can use your own IP addresses if you want. Just disable the "auto manage addresses" option. This behaviour is by design, as we recommend to use isolated and dedicated vlans and IP addresses for any inspection device. 

Which TMOS version do you use? (I don't remember the exact version, but we've have changed the default IP range in newer versions).

You can find some troubleshooting tips here (choose your version): https://clouddocs.f5.com/sslo-deployment-guide/sslo-10/chapter5/page5.01.html

Cheers
Stephan

[Konstantinos_Be]

Hi Stephan,

I am currently running 16.1.3.3 and SSLO 9.3.41.

I don't know how I can "force" HTTPS traffic to be decrypted before been sent to the NGFW.

I do see the HTTPS traffic as terminated on the BIGIP since I have the wildcard certificate on the site as expected.

Thank you

Best Regards

Konstantinos

[Konstantinos_Be]

Dear all,

After further troubleshooting it has been found that the decryption is working.

The flow is decrypted and sent over the original port, hence the port 443.

Thank you for the support and quick feedback.

Best Regards

Konstantinos

[Stephan_Schulz]

Hi,

ah yes, this can happen. It is a (recommended) option for the service device to use "port remap" to change the port to 80 (at least to something different than 443).

glad to hear it is working now. 

Cheers
Stephan