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

[x_member]

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.

[AndreaSoliva · Accepted solution]

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

[AndreaSoliva · Accepted solution]

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]

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]

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

[x_member]

kallbrandt wrote:

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

As everything else works (albeit with SSL inspection off) I'm inclined to compare supported ciphers first and try and setup a useful test scenario and run some diagnostics before raising a ticket to check the situation. Had an online chat today with Fortinet that suggested they believe it should all work without issue, but that's not what we're seeing. 

We've been burned before with updating to new releases too quickly.

[x_member]

I've an open ticket with support at the moment to address further issues with SSL inspection (including outbound) which are apparently a known issue with the ipsengine.

I'm currently testing a revised ips engine on our test network - the webserver on this network is not TLS 1.2 capable, however the SSL inspection on inbound connections is completely broken here as well (turning it off instantly resolves connectivity issues relating to the client-server handshake).

So I've tried to follow the instructions given by Andrea as I cannot find any other help on how to setup load balancing / virtual servers for a single webserver with SSL inspection.

*EDIT* earlier error was me making spelling errors and not seeing them..

Unfortunately I get a command failure (-61) at set server-type https

Looking in the web ui, I see no "Type" of HTTPS, just HTTP / TCP / UDP /IP

A limitation of the FGT60D or 5.2.7?

[AndreaSoliva]

Hi

yes sir as I wrote in my article:

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

Your device is not supported and that we do not have any troubles at all which is not really understood within this thread:

--> SSL Inspection and SSL Offloading is not the same. SSL Inspection is also called deep inspection (inspection of encrypted traffic). SSL Offloading is decrypt real time encrypted traffic on a Reverse proxy to use in later phase deep inspection.

From this point of view do not mix up SSL Offloading the SSL Inspection or deep inspection.

hope this helps

have fun

Andrea

[x_member]

AndreaSoliva wrote:

Hi

yes sir as I wrote in my article:

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

Your device is not supported and that we do not have any troubles at all which is not really understood within this thread:

--> SSL Inspection and SSL Offloading is not the same. SSL Inspection is also called deep inspection (inspection of encrypted traffic). SSL Offloading is decrypt real time encrypted traffic on a Reverse proxy to use in later phase deep inspection.

From this point of view do not mix up SSL Offloading the SSL Inspection or deep inspection.

hope this helps

have fun

Andrea

I'm trying really hard not to mix up the two, but I'm afraid I don't understand your explanation. My question related to SSL Inspection of incoming traffic.

Your answer related to SSL Offloading. 

Am I to understand from your answer that SSL Offloading is required to be able to do SSL inspection on inbound traffic? In which case should I assume that any documentation referencing "SSL Inspection" implicitly includes the words "outbound traffic only"?

[AndreaSoliva]

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]

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