Skip to main content
x_member
x_member
New Member
July 18, 2016
Solved

(TLS v1.2) intermittent issue with SSL Inspection enabled

  • July 18, 2016
  • 2 replies
  • 44141 views

I'm looking for a little clarity on this after we've come across an intermittent issue on 5.2.7 with SSL Inspection enabled.

 

We serve a number of SSL websites to external customers from a single web server. Up until last week the server was running Windows 2008 SP2 Standard and customers had no issues accessing the site from any of the main browsers (IE, Edge, Chrome, Firefox).

 

Unfortunately we had an issue with the server and were forced to quickly implement a Windows 2012 R2 web server to serve the same sites. This was locked down (using IISCrypto) to offer appropriate encryption and cipher combinations, including TLS 1.2 (which was not supported on the older machine). No changes were made on the Fortigate configuration.

 

Since implementation we have had intermittent connectivity issues reported by customers which we have occasionally been able to replicate as they are not happening consistently. These occur across all browsers - in Firefox reporting an SSL_ERROR_BAD_MAC_ALERT when attempting to load any of the sites. NB: with ssl inspection off Firefox reports connecting using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 TLS1.2.

 

Switching off SSL inspection for all inbound traffic to the web sites has eliminated the issue for now, however I need to understand how to diagnose and resolve the issue. My searching located an article on the Fortinet knowledge base (http://kb.fortinet.com/kb/documentLink.do?externalID=FD37726) that implies that TLS v1.2 is supported - unless I'm reading this wrong of course. Note that I'm not able to enable inspection and monitor in live as the issue seems intermittent and took (afaik) approx 18 hours to first manifest.

 

Any thoughts / suggestions of how to direct my investigation gratefully received.

 

 

 

Best answer by Willem_Bargeman

What type of inspection mode are you using on the UTM profiles? Flow or proxy based?

If the inspection mode is flow based this could be the reason for the errors. There is a know issue in the IPS engine and flow based inspection if full SSL inspection is used. A new IPS engine version will fix the issue (not included in the 5.2.8 release).

Workaround is change the inspection mode to proxy based or update the IPS engine to version 3.0284

2 replies

AndreaSoliva
AndreaSoliva
New Member
July 19, 2016

Hi

 

Your message is actually a little bit confiusing this means: if you protect your WebServer/s internally over the FortiGate you implement actually a Reverse Proxy which is done on the FortiGate with a Virtual Server configuration. Actually the Virtual Server configuration is using in the background a normal vip object. Now what is important to know is that TLS 1.2 is not supported for SSL Offloading using Virtual Server and vip object. This means until now.....and now comes the good news!!!!

 

!!!!!!!!!!!!!!!!   Up to FortiOS 5.2.8 TLS 1.2 is supported on Devices which SSL Offloading can be done !!!!!!!!!!!!!!!!!

 

If your device is able to do SSL Offloading you see in the Software Matrix. In short words 80x, 100x and above but to be sure have a look at Software Matrix. To confgure a Virtual Server keep the picture which I attached in mind that you are fully aware how it works specially regarding the Certificate.

 

This means to configure a vip for the Virtual Server which is actually a Reverse Proxy (for TLS 1.2 min Version 5.2.8 must be used) do:

 

       # config firewall vip        # edit [Name of Virtual Server example "ActiveSync-OWA-Publishing"]        # set comment [Use a description example "Reverse Proxy ActiveSync/OWA"]        # set type server-load-balance        # unset src-filter        # unset extip        # set extip [IPv4 Public Addresse for example ActiveSync/OWA or Exchange example "193.193.135.66"]        # set extintf [Name of Interfaces for Public IPv4 Addresse for ActiveSync/OWA or Exchange zB "wan1"]        # set server-type https        # unset srcintf-filter        # unset monitor        # set persistence ssl-session-id        # unset extport        # set extport 443        # set ssl-mode full

       # set ssl-mode full        # set ssl-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]        # set ssl-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]        # set ssl-server-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]        # set ssl-server-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]        # set ssl-certificate [Name of Private Certificate for ActiveSync/OWA or des Exchange Servers]        # end

 

After that configure monitoring for the Servers within internal network or which are used over Virtual Server:

 

       # config firewall vip        # edit [Name of Virtual Server example "ActiveSync-OWA-Publishing"]        # config realservers        # edit [Use a integer like "0"]        # set ip [Internal IPv4 Adresse for ActiveSync/OWA or Exchange Servers 198.18.0.92        # set port 443        # unset healthcheck        # end        # end

 

After that configure a "ssl-ssh-profile" wich is configured as "Protecting SSL Server" and use this as the VIP within a Firewall Policy.

 

This is actually in short words a Reverse Proxy with SSL Offloading.

 

hope this helps and verifies the TLS 1.2 behaviour.

 

have fun

 

Andrea

x_member
x_memberAuthor
New Member
July 19, 2016

Thanks for responding Andrea.

 

I'm not sure where my original post becomes confusing, but I should have mentioned that our device is a FGT-60D; based on the available product matrices for both 5.2.4 and 5.4.1 it not support SSL Offloading. 

 

I take it this then means that we have no options for SSL Inspection for inbound TLS 1.2 traffic. This is a major blow for us.

kallbrandt
kallbrandt
New Member
July 19, 2016

Well, try 5.2.8? You have nothing to lose. :)

Since 5.2.8 VIP/LB now supports TLS 1.2 one can suspect the SSL inspection also should work better with it.

But seeing is believing...

I just read the release notes - Nothing about TLS 1.2 whatsoever...

 

AndreaSoliva
AndreaSoliva
New Member
July 28, 2016

Hi

 

Ask yourself following question:

 

"What is/must be used to encrypt the traffic within deep inspection traffic"

 

--> Answer: SSL Traffic is based on Certificates meaninig if you are sitting in LAN and trying to ge to a https site FGT is doign man of the middle which means FGT is doing the work as you would do it. This means also that the original Certificate from https server is never reaching you instead FGT is using it do decrypt the traffic and looking in this way deep into the traffic for AV, IPS etc. etc. as this is done the packet is again encrypted based on the deep inspection defined Certificate on the FGT. Addtional the Certificate will be signed related to the original https site and sent to you which is sitting in the LAN. If you receive the package you can decrypt the package because you have the Certificate local on the worksation in the related trusted Certificate container. In this way you see within the Certificate which you receive from FGT the https site but the Certificate is coming from the FGT. Exact in this way it is working from outside to inside (look at the picture I inclued). From this point of view FGT is playing the inside https server and has his Certificate. Because the user is requesting actually not the inside https server insted the FGT the FGT is able based on the Certificate to decrypt on the Reverse Proxy the traffic and actually FGT is also terminating the session. After that meaning decryption FGT does inspect the traffic IPS AV etc. etc. and if all ok opens a new session and sens the request to the https server inside which must be not in any case https. This means you can terminate on a reverse proxy https and forward traffic afterwards by http which is often done to save performance on the inside server. Reverse Proxy is the same as Explicit Proxy you use from inside to outside (Explained in quick way):

 

Client ----> Expicit Proxy (Session Terminates) | New Session Explicit Proxy -----> Destination

Destination ------> Explicit Proxy (Session Terminates) Inspection | New Session -----> Client

 

Outside World ------> Reverse Proxy (Session Terminates) Inspection | New Session -----> Inside Server

 

From this point of view SSL Inspection which means deep inspection as SSL Offloading are using the same technology but in a different way specially if you are using Transparent Proxy. But one is clear = Both are based on the same technology meaning man of the middle. From this point of view using not a Reverse Proxy trying to do based on SSL Inspection or deep inspection inbound traffic is impossible and will never work because FGT has not clou how to decrypt traffic!

 

Hope this helps

 

have fun

 

Andrea

x_member
x_memberAuthor
New Member
July 28, 2016

So Yes - inbound SSL Inspection is dependent on SSL Offloading then.

 

Willem_Bargeman
Willem_BargemanAnswer
New Member
July 29, 2016

What type of inspection mode are you using on the UTM profiles? Flow or proxy based?

If the inspection mode is flow based this could be the reason for the errors. There is a know issue in the IPS engine and flow based inspection if full SSL inspection is used. A new IPS engine version will fix the issue (not included in the 5.2.8 release).

Workaround is change the inspection mode to proxy based or update the IPS engine to version 3.0284

Terms & ConditionsAccessibility statement