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

[pminarik]

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).

[Calvin777 · Accepted solution]

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.

[sw2090]

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.