SSL Certificate Inspection causing connection issues with certain sites

daccu · ‎12-02-2016

We have SSL Certificate Inspection enabled (we are NOT using DPI-SSL, so we don't have the MITM invalid certificate problem). Certain services such as Amazon Echo, credit card POS devices, and PRTG application updates error out on connection with this enabled. If I simply remove the certificate inspection from the IP4 rules everything works. Are there any tweaks that will make just the services we're having trouble with connect? I know with DPI-SSL you can set exclusions, but that option doesn't seem to be available for the certificate inspection option. As a secondary question, what exactly is the Fortigate doing during certificate inspection that breaks these services?

hmtay_FTNT · ‎03-02-2017

Hello,

To answer daccu's question first,

Certificate Inspection should not break any SSL connections. The Fortigate only inspects the SNI on the Client Hello or the Server Certificate when Certificate Inspection is used. It does not attempt a MitM. Could you post the output of the CLI commands, "config firewall ssl-ssh-profile", "edit <your profile>", "show"?

E.g.

edit "certificate-inspection" set comment "SSL handshake inspection." config https set ports 443 set status certificate-inspection end config ftps set ports 990 set status disable end config imaps set ports 993 set status disable end config pop3s set ports 995 set status disable end config smtps set ports 465 set status disable end config ssh set ports 22 set status disable end next

This is the default certificate-inspection profile.

SteveG,

TLS 1.3 would have affected the engine if you used deep-inspection - not widespread yet, recently added into Chrome 56 (would require the server to support the protocol too). It should not affect it if certificate-inspection is used. Our dev team has released a new engine to address TLS 1.3. It is not released to the public yet as it is undergoing beta tests.

LewisBowerbank,

You can disable the replacement message.

If you are using the Web Filter profile and FortiOS 5.4, here's how:

Go to "config webfilter profile", "edit <profile name>", "set https-replacemsg disable".

If you are using the Application Control profile and FortiOS 5.4,

Go to "config application list", "edit <application name>", "set app-replacemsg disable".

View solution in original post

hmtay_FTNT · ‎04-27-2017

Hello Ivan,

>>After reading the discussion I am not sure if I understood the solution correctly. The issue is that during certificate inspection (SNI and CN) some website access breaks - right? Typically the issue occures on those sites where there are some embedded links which are beeing loaded after the first URL request. The issue only occures if some of those emmeded links are categorized by the webfilter to be blocked (e.g. advertising). When the webfilter blocks access to those https sites the fortigate will send the https-replacemsg to the client with the own fortigate certificate. Typically this is untrusted and the client will get the unknown certificate issuer error. This can be solved for managed clients with certificate rollout. But for BYOD devices thats not possible.

Yes, this is correct. >>My question: What actually happens if the fortigate does not send the https-replacemsg as suggested by you?

If the Fortigate does not seed the https-replacemsg, it will send a TCP RST packet to close the session.

>>Will the website be partially loaded? (Like loading a news pages without the Ad Banners)

Yes, it will be partially loaded. Let's say you load a YouTube page. If you have Google Ads blocked, you will noticed there are patches on the page that looks like the typical error message you get. I attached a sample screen.

One important thing to note is you may notice the page might load slower than usual. This is caused by non-asynchronous loading of the HTML content. For e.g., in the YouTube case, if the HTML page is written in a way as to load the Google Ads first, if the browser receives a RST packet, it may (or may not) keep requesting for the content until the timeout value is reached. If the HTML page is not written in a way to allow asynchronous loading of other content at the same time while it is trying to load the Google Ads, the page will load slowly. This is because the browser is trying to load the ads before everything else. However, if the Google Ads code is at the very end, you will see the rest of the page loads like usual minus the ads. If the code is somewhere in the middle of the page, then you might have 60-70% of the page loaded, then it will slow down for a while to try to get the Google Ads, and once the timeout is done, the remaining page will be loaded. This is unfortunately not something we can control. On many of the major browsers today, a RST packet will stop the browser from resending the GET request for a resource. So you are not likely going to see a slowdown. In short:

If https-replacemsg is enabled, you may see a slowdown if a content on a page is blocked because the Fortigate does not send a RST packet right away. The browser will wait until the timeout value is reached.

If https-replacemsg is disabled, you most likely will not see a slowdown. A RST packet will be sent immediately, the browser knows not to wait, and the rest of the page will load after that.

I hope this clears up some confusion you have. Thanks!

HoMing

View solution in original post

ikmarwright · ‎02-01-2021

Deleted. Didn't realize the thread was so old.