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

SteveG · ‎03-01-2017

I'm seeing similar stuff on a couple of sites (angular.io), like you if I disable SSL inspection for that site it works fine. Do you have 'block invalid certs' ticked on your SSL Inspection profile, I disabled that but still see the same problem? I'm wondering if it's a TLS 1.3 thing but not had time to investigate fully.

Alby23 · ‎03-01-2017

Try, just to test, to inspect all ports in Proxy Option profile.

It's a resource-consuming option so enable it just in a dedicated policy and please retry.

LewisBowerbank · ‎03-02-2017

We have the same problem, we have the advertising category blocked these are embedded on pages and sometimes the browser just says there is a problem connecting securely to the website. Even if the page is in an allowed category but the advert causes this to fail. If I allow the advertising category the page loads. It is annoying that Fortigate certificate has to present itself on blocked pages, I cannot add certificates to the end user machines on this network.

I tried the inspect all ports in the proxy and that didn't help unfortunately

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

LewisBowerbank · ‎03-02-2017

Thank you for your suggestion, I had not done this with the webfilter profile but sadly the Fortigate still presents its certificate which causes the browser to say there is a problem with the website's security certificate/lots of security alerts pop up about the certificate and if you wish to proceed/or states the connection is not private and prevents you from visiting the page.

I'm looking to move to another device to handle web filtering providing WCCP on the Fortigate is flexible enough that some IP addresses can be exempt.

hmtay_FTNT · ‎03-02-2017

Hello LewisBowerbank,

If you are getting those certificates error when you did not try to block anything, it is very likely you are enabling deep-inspection and the FortiGate is doing a MitM on the SSL sessions. If you do not import the FortiGate's SSL Certificate on your machine, you will get that error.

If you would like to avoid importing the FortiGate's SSL Certificate on all the machines, you need to get a properly signed SSL Certificate and add it to the FortiGate.

LewisBowerbank · ‎03-06-2017

Thanks it isn't occurring on all sites as it would do on deep inspection. I'm not sure on the process but getting a SSL certificate but we would need that to be trusted while acting on behalf of sites such as YouTube where the blocked advertising category causes problems with this site and I don't think we would be able to have access to something like that.

hmtay_FTNT · ‎03-06-2017

Hello LewisBowerbank,

Can you send me your configuration file? I can take a look at it to see if you disable the replacement message correctly.

The reason you are getting the SSL certificate error is because the FG tries to send the replacement message through the SSL connections that are getting blocked. If you disable the replacement message correctly, that should prevent the Certificate error.

Jond · ‎03-15-2017

Hi there... I am also getting issues with certificate-inspection (not mitm) breaking web sites. My configuration is standard. I have just created a new profile from scratch and that also causes the issue.