Web Application Firewall SSL inspection clarification?

[Cajuntank]

I am making a few servers available to the public for my users and contractors when not on-premise. I have secured the servers already with a wildcard certificate and have the VIP and policy set and have tested accessibility. What I am wanting to do now is to additionally provide IPS and WAF profile inspection to those policies. The IPS and WAF part I understand, what I am a little fuzzy on is the SSL inspection requirement for these to actually do their job. In the fortiOS admin guide, there is always an example for WAF applied to a policy where they are also setting the policy to use a deep-inspection profile.

I understand the need for deep-inspection, but how does that work with public access for a private cert? Will they just get certificate warnings until they themselves import and trust it on their own? I see where I can create a Protecting SSL Server profile and specify my wildcard cert I imported into my FortiGate, but is that enough comparatively to deep-inspection?

[saneeshpv_FTNT]

Hi,

Usually, If you wish to publish your servers for Public access, first of all you need a Server certificate signed by a Public CA and not your private CA, so that external users can trust the website without explicitly importing the Private Root CA. But in your case, if the access is only limited to specific set of users and you don't want to incur additional cost of purchasing a Public CA Signed Certificate, you may ask them to import your Root CA to their PC, so they don't get certificate warnings when they access the websites. 

[pminarik · Accepted solution]

If you use a default-like "deep-inspection" profile with your own CA (like below), then indeed external clients will absolutely run into certificate warnings.

basic dpi

However, this is not the setting you should be using for protecting an internet-facing server.

What one is supposed to use is the "Protecting SSL Server" option. This is intended for protecting a specific server, and for that purpose you should import a certificate appropriate for handling traffic to that server (matching the expected FQDN and/or IP in the certificate's SAN field) and use it in this profile. CA certificates intended for DPI should not (and cannot, as far as I know) be used in this scenario.

protect server

[Cajuntank]

I saw this feature and can easily implement, but it still raises the question in my mind if this is still enough for IPS and WAF to do their job properly at that SSL inspection level?

[pminarik]

Those are two different questions, but both certainly valid.
SSL inspection profile using "Protecting SSL Server" will allow the FortiGate to decrypt the TLS session and inspect the plaintext payloads inside.

If it's a protocol that the FortiGate understands (you didn't actually specify, but let's assume HTTPS), then the IPS engine will be able to detect and block whatever you tell it to block using the IPS profile selected in the firewall policy. WAF should also do its job of inspecting HTTP(S) traffic, but be aware that FortiOS WAF is rather simple and all but deprecated nowadays. If it works for you, good, if it doesn't, you'll have to use a different product for WAF functionality. (such as FortiWeb)

As for whether SSL inspection is required for IPS / WAF to work, that depends.

IPS - this is a per-signature question. Some signatures work with the "outer layer" (e.g. detecting some attempts to exploit a hypothetical TLS vulnerability in some specific implementation), while some signatures require deep SSL inspection to inspect the inner payload (e.g. a specific malicious payload send to a vulnerable server, within a TLS-encrypted session).

WAF is simple - SSL inspection is mandatory for HTTPS inspection to work at all.

[Cajuntank]

Ok, the "Protecting SSL Server will allow the FortiGate to decrypt the TLS session and inspect the plaintext payloads inside" is the main thing I wanted to hear and confirm. I understand about the WAF part... my main concern was being able to apply other security inspections correctly to the policy and them actually work...i.e.. if I could not decrypt the TLS session, what good does IPS really do for example? Thank you for the clarification.