Why is the certificate replaced during web-filtering?

[Calvin777]

Good evening!

I've created the following policy to scan web traffic (test setup):

config firewall policy
edit 2
set name "Trust:Webzugriff"
set uuid a7a53264-XXXXXXXXXXXXXXXX
set srcintf "internal2"
set dstintf "wan1"
set action accept
set srcaddr "Trust address"
set dstaddr "all"
set schedule "always"
set service "HTTPS" "PING" "HTTP"
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set av-profile "AV-Web"
set webfilter-profile "block some & monitor-all"
set dnsfilter-profile "default"
set file-filter-profile "default"
set ips-sensor "all_default"
set application-list "block-high-risk"
set logtraffic all
set nat enable
next
end

The webfilter profile is configured to warn on specific categories. This works fine. Surfing to a corresponding web page triggers the webfilter. The Fortigate "warning-page" is shown. However, while the log says the web filter was triggered, the warning page says "FortiGuard Intrusion Prevention - Access Blocked". May be a cosmetic issue.

Clicking "Proceed" in the warning page now leads to the web page, but the certificate of the web page was replaced by the fortigate. I would expect this beahvior with deep-inspection, but not "certificate-inspection".

The configuration of certificate-inspection is the factory default.

Version: v7.4.1 build2463 (Feature)

I would be very thankfull, if somebody could explain this behavior!

Thanks

Oliver

[hbac]

Hi @Calvin777.,

Is the firewall policy set to flow based or proxy based? 

Regards, 

[Calvin777]

It's the default. As far as I understood the documentation it should be flow based.

[hbac]

@Calvin777,

Yes, if it is set to flow based and no deep inspection, you shouldn't see FortiGate certificate. Can you check the logs and make sure it hits policy 2? 

Regards, 

[Calvin777]

Thanks @hbac ,

yes, it is policy 2!

Extract:

2023/11/15 20:21:53, Deny (Deny: UTM Blocked), SSL, 2 (Trust:Webzugriff)

EDIT: There are other entries, related to this connection, which hit the "implicit deny"

[AEK]

Hello

This may be related to your ssl inspection profile. Try another ssl profile in which you allow all certificate errors.

[Calvin777]

Thanks @AEK ,

but this didn't help.

[AEK]

Hi Calvin

Can you share a screenshot of your ssl inspection profile?

[pminarik]

If Webfilter decides that it must block, then it doesn't matter if you're using certificate-inspection or deep-inspection.

The client device/browser is still expecting valid TLS and valid HTTP, so the original connection to the TLS server must be "hijacked" in order to inject the HTML code of the block page. Thus, the certificate must be replaced. Thus certificate warnings if the inspection CA is untrusted by the client.

You can consider certificate-inspection to be "opportunistic deep inspection". If webfilter doesn't decide to block, nothing happens. If it decides to block, MITM happens.

This is nicely described in the flowchart of this article: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Web-Filtering-certificate-warning/ta-p/189... (just disregard the HSTS commentary, that's incorrect/not relevant anymore)

[Calvin777]

Hi @pminarik , @sw2090 

Thanks for your replies. Just to make clear: my question is not about trusting (or not trusting) certificates. This topic is clear to me.

I just wondered, why the certificate is exchanged, when the user clicks on "proceed" (!) in the warning page, generated by fortigate and then gets to the requested page (here the certificate is replaced). Proceeding on this particular website, the original certificate is passed by the fortigate (Web filter does not react again).

@pminarik , you wrote

"If webfilter doesn't decide to block, nothing happens. If it decides to block, MITM happens." 

This is probably the solution. Is this behaviour described in some documentation? Something I can refer to in our internal docs?

 Thanks to all!