TLS 1.3

https://tools.ietf.org/html/rfc8446

Some modern Browser switch to TLS 1.3 automatic if the Web server on the other side supports this. Like Version 72 of Chrome.exe or even your OS is like Windows 10 Buildnummer 20170 upwards (That means the OS itself). So it's all safer and faster?

https://blogs.windows.com/windows-insider/2020/07/15/announcing-windows-10-insider-preview-build-20170/

The problem is that some Next Generation Web Filter (Firewall) can't look into the SSL-encryption anymore and find malware/Ransomware. With Browser self updating mechanism like in Chrome or Edge Chromium you suddenly have a constellation that you did not want. While you approved IE11/EDGE Updates in WSUS and mostly checked each new Release of the Browser before releasing it this has changed.

The interesting point is that also some Load Balancer are only able to break (Deep Inspect) traffic with really new Firmware releases. Customers demanded that feature since 2017 we see in diverse blogs and feature request portals of producers. So if you want to sniff into SSL (Break SSL Stream) and you're Firewall can't handle TLS 1.3 special you currently have a problem.

Check if your browser has TLS 1.3 active is easy

CHROME:

chrome://flags/#tls13-variant (Since Version 72 TLS 1.3 default)

MICROSOFT EDGE CHROMIUM:

edge://flags/

As example Type edge://flags/ in the Browser URL window.

Or jump direct to the TLS 1.3 setting with edge://flags/#enable-tls13-early-data

Open following URL / Test Website to see what's supported:

https://browserleaks.com/ssl

https://news.sophos.com/en-us/2020/08/18/report-firewall-best-practices-to-block-ransomware/

https://www.fortinet.com/blog/business-and-technology/tls-is-here-what-this-means-for-you

https://www.f5.com/c/landing/encrypted-threats/article/tls-1-3-are-you-ready-for-the-update

https://community.checkpoint.com/t5/General-Topics/CheckPoint-TLS-1-3-support-When/td-p/63672

https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/understanding_traffic_decryption.html

https://www.sonicwall.com/support/knowledge-base/ssl-tls-protocols-supported-by-sonicos-matrix/170615123553371/

Read more:

https://devblogs.microsoft.com/premier-developer/microsoft-tls-1-3-support-reference/

https://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/1819-pg-projects/Detecting-Malware-in-TLS-Traf%EF%AC%81c.pdf

https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/

https://www.heise.de/security/meldung/Verschluesselung-TLS-1-3-Fauxpas-gefaehrdet-Embedded-Systeme-mit-wolfSSL-4883741.html

https://www.heise.de/hintergrund/Was-TLS-1-3-ist-und-wie-Sie-davon-profitieren-4248740.html

https://www.sans.org/reading-room/whitepapers/vpns/paper/39715

https://nakedsecurity.sophos.com/2020/02/18/malware-and-https-a-growing-love-affair/

Problem: Forticlient Silent Option to select different Module to install does not work as before with Forticlient 6.X up to 6.0.5 (FortiClientSetup_6.0.5.0209_x64)

Problem: You see an empty Forticlient Window when you open it

Explanation:

Bis jetzt gab es fuer den Forticlient:

• Forti Configurator (Ein Tool bei welchem man die Optionen wählen konnte und dann gleichzeitig ein CONFIG file mitgeben und es machte am Schluss ein MSI)
• Ein Windows Installer OPTION INSTALLLEVEL (Mit dieser konnte man bis Forticlient 5.9.X sagen was man will (SSLVPN/VPN/Antivirus usw.)

Den Configurator gibt es nur noch auf dem Developer Network von Fortinet. Damit man dort an das File kommt MUSS man zwei Fortinet Mitarbeiter als Referenz angeben.

To get the Configurator where you can you have to open a developer account with Fortinet. And to do that you have to get approval of TWO Fortinet employees (Fortinet E-mail Addresses). That's simply because they don't want customer to modify the default install and use the ONLINE Installer so everybody tries their Antivirus and Patch Module. Before you could download the Forticlient Configurator for free und the Support Forticlient download section.

There are also other nice things there like the VPN Automation scripts and SSLVPN Commandline tools. I am sure a lot of Fortinet Customer would like to use those and don't even know they exists and swap to VPN technology from Microsoft https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/always-on-vpn-technology-overview

This thread Shows what happens when you use Installlevel=1 (As worked before with Forticlient 5.X)

https://forum.fortinet.com/tm.aspx?m=165279

https://docs.fortinet.com/document/forticlient/6.0.2/configurator-tool/823336/use-forticlient-configurator-tool-tool-for-windows

Forticonfigurator:

Nice ;-.)

Solution:

Use INSTALLLEVEL 3 instead of 1

msiexec.exe /i FortiClientSetup_6.0.5.0209_x64\forticlient.msi /quiet INSTALLLEVEL=3

The MSI package:

VPN, SSLVPN, SSO is fine for most enterprise users.

We don't see the NAC Option in the GUI even if we choose it with option 3 > We don't want that so Installlevel 1 would be the choice but that DOES not work as mentioned.

Here is the reason Fortigate makes this so complex. They want to sell EMS which can be used to Deploy Forticlient.

Fortigate Application Filter Certificate wrong/missing Entry sample for an important laptop driver (W10 Deployment fails because of signed Driver Revocation Lookup)

OR HOW a missing small ENTRY I a FORTIGATE FIREWALL IPS/APP filter can ruin your Windows 10 OS-Deployment work.

Reason: Missing entry in Fortigate Application Filter "ROOT.CERTIFICATE.URL" and "OCSP" source of failing deployment

Windows 10 Deployment with commercial Deployment Products (This includes HP client hardware, Microsoft SCCM, Landesk or Ivanti Frontrange).

During the Unattend phase the driver for MASS storage or NIC does a Certificate Revocation Lookup. However the as sample mentioned

URL pki.infineon.com (Hardware Driver URL, CRL FQDN) is missing in Fortiguard definitions. Thus the Fortigate does block the access to WAN. Since this is an early setup phase of W10, group Policy or special GPO do not pull at that moment.

Fortigate has already missed several PKI URL the last few months confirmed by ticket resulting in large trouble and delay on client and Server OS of customers who route their Client or Server traffic through Web proxy and because of security do not want to route computer account proxy traffic standard to the proxy.

Why this is so important. Why this is generating a lot of work and trouble for OS-Deployment teams.

The normal way in larger companies is that all outgoing traffic from client VLAN goes to Firewall which it blocks. All Web/Application/Socks traffic that should go outside goes to a Proxy, Web filter.

Because in early phase of Deployment those options are not set already and normally not needed. However if the driver is older than the Expiration of the Code Signing Certificate W7/W10 will check

The Certificate Revocation list from WAN/Internet. If that fails it may refuse to integrate the driver in Windows PE or early Windows Setup phase. If example this is a driver which

handels NIC (network) or mass Storage driver (Disk) they deployment can't run through this early process.

Workaround:

URL we need open in our sample: pki.infineon.com which prevents a complete Enterprise Deployment system to fail

Sample from Fortigate for other Certs they missed:

F-SBID( --name "Root.Certificate.URL_Custom"; --protocol tcp; --app_cat 17; --service HTTP; --flow from_client; --pcre "/(crl\.microsoft\.com|\.omniroot\.com|\.verisign\.com|\.symcb\.com|\.symcd\.com|\.verisign\.ne t|\.geotrust\.com|\.entrust\.net|\.public- trust\.com|\.globalsign\.|\.digicert\.com|crl\.startcom\.|crl\.cnnic\.cn|crl\.identrust\.com|crl\.thaw te\.com|crlsl\.wosign\.com|www\.d\-trust\.net)/"; --context host; --weight 15; )

In our case:

F-SBID( --name "Root.Certificate.pki.infineon.com"; --protocol tcp; --app_cat 17; --service HTTP; -- flow from_client; --pcre "/(pki\.infineon\.com)/"; --context host; --weight 15; )

Please also see:

Butsch.ch | The certificate is invalid for exchange server usage Exchange 2010 SAN/UC

https://www.butsch.ch/post/The-certificate-is-invalid-for-exchange-server-usage-Exchange-2010-SANUC

So you understand that this is a problem which persists over all firewall producers:

https://support.symantec.com/en_US/article.HOWTO9584.html

Symantec: About the Install Readiness Check for Certificate Revocation List access

https://success.trendmicro.com/solution/1058226

TEND MICRO: After upgrading OfficeScan, users complained that the server started to rename all files in the OfficeClient Directory to "_invalid".
Below is a sample list of files in the D:\app\Trend Micro\OfficeScan\PCCSRV\Admin directory:

Checkpoint:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk108202

If there is no Internet connection, then CRL fetch and intermediate CA fetch will fail (this will be logged). The inspection will take place; however, URL-based or Category-based bypassing will not work.

Note: The CRL verifications are performed in the background asynchronously while matching the security policy (this mimics the behavior of the major web browsers).

Untrusted certificates and lack of CRLs can be configured as reasons to drop the connection

Mcafee:
https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/25000/PD25504/en_US/epo_530_pg_0-00_en-us.pdf