Visitor III

Solved

Why is the certificate replaced during web-filtering?

Forum|Forum|2 years ago
November 15, 2023
5 replies
7906 views

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

Best answer by Calvin777

Hi!

OK, I now got the mechanism. The basic reason for "certificate replacement" is the way how the "proceed" mechanism in "Web profile/Policy override" is implemented. For everybody who is interested: The Fortigate provides a corresponding service on port 8015. After clicking proceed, the webpage does not come from the webserver, but the fortigate. Therefore its the fortigate certificate, which is used.

Thanks to everybody contributing to this diskussion!

Have a nice weekend.

hbac

Staff

Hi @Calvin777.,

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

Regards,

Calvin777Author

Visitor III

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

hbac

Staff

@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,

AEK

SuperUser

Hello

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

AEK

Calvin777Author

Visitor III

Thanks @AEK ,

but this didn't help.

AEK

SuperUser

Hi Calvin

Can you share a screenshot of your ssl inspection profile?

AEK

pminarik

Staff

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/189919 (just disregard the HSTS commentary, that's incorrect/not relevant anymore)

Calvin777Author

Visitor III

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!

pminarik

Staff

The link I included in my reply covers this. If it's not sufficient, let me know what specifically you're missing that you'd like to see added.

Also, this is a "general fact of life" with TLS. The payload of a TLS session cannot be silently modified by a third party without hijacking the session (which requires using your own certificates during the handshake). This is true for all vendors. Anybody claiming to have the capability to do this without triggering errors and without importing CA certificates to client endpoints implicitly claims that they have completely destroyed the security of TLS.

When it comes to FortiOS, you have two alternatives:

"set https-replacemsg disable" in webfilter profile's CLI. This replaces certificate warnings by simply sending a TCP-RST to the client (browser will show an error mentioning this TCP-RST, no block page).
block this on DNS level by a DNS profile. This will replace the certificate warning by either DNS-related errors in the browser, or actually keep certificate warnings (if the block action of the DNS profile stays configured to the default blocking IP).

sw2090

SuperUser

I gues you see the FGT Cert on the blocking page since that comes from the FortiGate :)
If you got an UTM Block via SSL inspection and your policy does only have certificate inspection enabeld then something on the cert of the website must have triggered the certificate inspection to block this. Probably log entry details will show you.

Sign up

Login with SSO

Login to the community

Login with SSO