Nyní jsem již vážně z Fortinetu rozčílený. Fortinetu rozhodně na zákaznících nezáleží. Jako velmi špatné mi přejde, že česká pobočka nic neřeší. Mám zkušenosti třeba s Ciscem, kde jsou velice ochotní technici a eskalují problémy i do zahraničí. O inteligenci podpory (i když se má jednat o senior inženýra) nemám ani tak pochybnosti, jako jasný názor, je extrémně nízká (pokud to není nařízení, že se tak má chovat, aby odradil zákazníky). Údajně již problém delší dobu řeší Research and development tým, kde musí být také velice omezení. Pak je jasné, proč má FortiGate více bugů než funkčnosti. Poslal jsem jim jasné vysvětlení a důkazy problému, ale nejsou to schopni pochopit. Co naprosto nechápu, proč si situaci nevyzkouší ve svém prostředí!!! To snad dělá každá firma při řešení problému.
Celkově neustále řeším nějaké problémy. Nejčastěji to, že máme různé aplikace, které se pravidelně připojují k nějakým webovým službám v internetu (například do Azure) a to občas začne zlobit a spojení se nedaří. V logu je, jako by server poslal Server Reset (takže se navazují nové a nové sesison), ale odjinud jsou spojení bez chyb. Na dané adresy mám výjimky ze SSL inspekce, apod. Většinou pomůže, když pro danou cílovou adresu změním politiku z Proxy Mode na Flow nebo naopak (nejhorší je, že některé služby chodí v jednom módu a jiné v tom druhém).

Pozn.: 8. 9. 2020 jsem doplnil, jak jsem před časem řešil IPsec VPN.

Pozn.: 11. 9. 2020 jsem doplnil situaci okolo řešeného problému.

Pozn.: 7. 10. 2020 jsem doplnil informaci ohledně opravy bugu ve FortiOS 6.2.6. A zmínil nový problém s přístupem na HTTPS ve FortiOS 6.2.5.

Pozn.: 2. 12. 2020 jsem doplnil informaci o upgradu na FortiOS 6.2.6, který problém nevyřešil, ale zhoršil (již to nefunguje ani s Certificate Inspection).

Pozn.: 1. 2. 2021 jsem doplnil informaci o upgradu na FortiOS 6.2.7, který problém nevyřešil.

Pozn.: 12. 2. 2021 jsem doplnil jak katastroficky pokračuje řešení s Fortinetem a úvodní názor.

Pozn.: 11. 3. 2021 jsem doplnil další problém. Nefunkční HTTPS komunikace z Dynamics 365 na Exchange Web Services v Proxy Mode s certifikátem.

Pozn.: 15. 4. 2021 řeším jsem další problém se Site to Site IPsec VPN, popsal jsem vše do nového článku. Mám otevřený ticket na Support. Jako problém se ukázalo využití VDOM Partitioning (Virtual clustering).

Pozn.: 2. 5. 2021 jsem doplnil informaci o upgradu na FortiOS 6.2.8, který problém konečně vyřešil.

Virtual clustering s VDOM partitioning

Relativně kosmetický problém, ale člověk na něj nesmí zapomenout. Pokud provozujeme FGCP cluster a máme rozdělené VDOM na různé nódy, tak se řada informací nepřenáší na druhý nód a musíme se připojit na ten, kde je daná VDOM Master. To je třeba u SD-WAN (statistiky a monitoring), Site to Site IPsec VPN (často se na druhém nódu ukazuje jako Inactive, to je dost nepříjemné), výpis routovací tabulky, debug pomocí CLI (a vůbec mnoho CLI zobrazovacích příkazů).

SSL VPN a špatná LDAP skupina

Po upgradu na FortiOS 6.2.4 se často (ale ne vždy) uživatelé v SSL VPN špatně zařazují do LDAP skupiny (z LDAPu FortiGate načte správnou, ale VPNce předá jinou), takže se sice připojí do VPN, ale tam nemohou komunikovat. Takže jsem hned prováděl downgrade. Jde o známý bug, prý opraven ve FortiOS 6.2.5. Technical Tip: Incorrect portal mapping because of SSL VPN LDAP user matching incorrect group

Nepřipojení do SSL VPN - FortiClient končí na 98%

Podle diskuzí velmi známý problém, který trvá asi od počátku Fortinet SSL VPN. Připojení k SSL VPN z FortiClienta (6.0.x, 6.2.x, 6.4.x) se zasekne na 98 % (buď po delší době skončí nebo zůstane viset) a uživatel se nepřipojí. Někdy se povede na x-tý pokus nebo po restartu aplikace (zajímavé je, že je lepší ukončit a nastartovat aplikaci, ne restartovat počítač). Někdo se nepřipojí vůbec. Asi třetina lidí u nás má s tímto vážný problém. Vypadá to, že kdokoliv má připojení k internetu přes IPv6, tak se nepřipojí (pokud se na stanici IPv6 zakáže, tak to jde). I funkční připojení trvá velice dlouho oproti Cisco AnyConnect. Obecně chybová hlášení Forticlienta nic neříkají (stejně jako debug).

Po dlouhé době se ukázalo, že problém způsobuje snaha připojit se pomocí DTLS. Více informací v FortiGate problémy s připojením do SSL VPN přes FortiClient.

Timeouty session - Poll Active Directory Server

Naprosto zásadní problém, který se objevil odhadem u poloviny lidí (možná i více, ale oni si toho nevšimli). Po přepnutí FortiGate do provozu se začalo mnoha lidem stávat, při komunikaci mezi různými sítěmi, že jim po různé době (někdy pár vteřin, někdy až po desítkách minut) spadne (libovolná) session. Například u RDP se automaticky znovu spojení naváže (problikne černá obrazovka, případně info o navazování spojení), ale SSH se ukončí. Stejně tak připojení na Exchange se při každém pádu spojení znovu obnoví a uživatel si nemusí problému všimnout (ale vše je pomalejší a někdy se nezobrazí správně informace). Práce pomocí SSH či připojení do DB je nepoužitelné, protože se neustále ukončuje a musí se navazovat znovu.

V Traffic logu FortiGate se u těchto session uvádělo Firewall Action: timeout. Zkoušel jsem upravovat politiky (vypínat kontroly, HW akceleraci apod.), zvedat timeouty, hledat problém v routingu a NATu. Pak debutovat vše možné, výpis session s filtrem, Packet Sniffer i Debug Flow (často se objevovala zpráva no session matched a od cílového serveru RST ACK). Jinak nikde nebylo nic zásadního vidět.

Až jsem dostal radu vypnout autentizaci na pravidle, obrátil jsem se pro radu na jednoho Fortinet specialistu, který viděl ve výpisu session údaj auth_server=Local FSSO Agent. Já nikde autentizaci nepoužívám, ale měl jsem vytvořený Fabric Connector pro Active Directory bez agenta. Což jsem chápal, že je metoda pro identifikaci uživatelů v lozích. Identifikace fungovala opravdu hezky, ale také způsobovala přerušení mnoha session. Ve chvíli, kdy jsem konektory vypnul (disable), tak vše začalo fungovat. Myslím, že i kdyby byl v získávání údajů o uživatelích jakýkoliv problém, tak by to nemělo způsobit rozbití komunikace.

Mám v plánu zkusit Fortinet Single Sign-On (FSSO) s pomocí agentů (agent-based), zda nebyl problém v tom vzdáleném dotazování do DC logů.

DNS error a IP connection error

Při pohledu do Traffic logu se velice často objevuje chyba v DNS komunikaci. U záznamu je Action: DNS error a Firewall Action: dns. Občas je Action: IP connection error a Firewall Action: ip-conn. Vždy je hned následováno dalším záznamem, kdy DNS komunikace korektně projde. Děje se pro UDP protokol (občasné DNS dotazy přes TCP prochází vždy).

V diskusích se tato situace řeší dost, ale asi není řešení a často se uvádí, že se není třeba touto chybou zatěžovat. Zmiňované je smazat system session-helper 14 pro dns-udp. To u mne nemělo vliv.

IPsec Site to Site VPN - autentizace certifikátem a SHA-2

Pozn.: IPsec VPN jsem se věnoval znovu, pokusil se nastudovat a sepsal článek FortiGate IPsec VPN, debug a problémy, kde také hodně popisuji debug. Je zde také uveden problém, kdy neprobíhá Phase 2 (IPsec) Rekey (řeším s podporou Fortinet). Vyřešilo se vypnutím VDOM Partitioning (Virtual clustering).

Potřebovali jsme vybudovat VPN tunel s jedním zákazníkem, který měl striktní požadavky na zabezpečení. Specifikoval všechny parametry, které byly

• Phase 1 - Exchange mode IKEv2, autentizace certifikátem, Encryption AES-256-GCM, Integrity HMAC-SHA2, Pseudo Random Function (PRF) SHA512, DH Group 21, SA Lifetime
• Phase 2 - Protocol ESP, Encryption AES-256-GCM, Integrity HMAC-SHA2, DH Group 21, Lifetime
• dva subnety na vzdálené straně, jeden u nás

Nevyznám se detailně v této oblasti, takže jsem chvilku řešil i terminologii. FortiGate používá Encryption a Authentication, které dohromady tvoří Proposal. Pro AES-GCM-256 uvádí, že Encryption algorithm obsahuje autentizaci. Ale pro fázi 1 je povinné použít PRF. Takže pro fázi 1 se nastavilo aes256gcm-prfsha512 a pro fázi 2 aes256gcm.

Vše šlo na FortiGate nastavit jednoduše v GUI. Ale tunel se nenavázal. Můžeme se podívat do Log & Report > Events - VPN Events, ale zde jsou pouze hrubé události. Takže musíme použít CLI. Důležitá věc je, pokud používáme VDOM a cluster, připojit se vždy na Master Node (i když následně tunel fungoval, tak jsem jej skoro vždy viděl dole, ale jiný tunel se zobrazoval korektně). Výpis informací o IPsec VPN. Technical Tip: Troubleshooting IPsec VPNs

get vpn ipsec tunnel summary
diagnose vpn ike gateway list name JMENO

A hlavně zapnutí debug IPsec VPN pro cílovou IP.

diagnose debug application ike -1
diagnose vpn ike log-filter dst-addr4 X.X.X.X
diagnose debug console timestamp enable

diagnose debug enable

Část debugu s chybou

2020-07-01 08:29:07.977165 ike 1:JMENO:2924: certificate validation pending
2020-07-01 08:29:07.977755 ike 1:JMENO:2924: certificate validation complete
2020-07-01 08:29:07.977763 ike 1:JMENO:2924: certificate validation succeeded
2020-07-01 08:29:07.977899 ike 1:JMENO:2924: signature verification failed

K této chybě jsem našel jen nějaké staré diskuse, že s certifikátem je třeba použít SHA-1. Udělal jsem nějaké pokusy a funkční bylo

• změnit autentizaci z certifikátu na Pre-shared Key (PSK)
• ve fázi 1 použít libovolné šifrování, ale autentizaci nebo PRF SHA1

Nakonec přišel technik druhé strany s tím, že Cisco Firepower má nějaký speciální příkaz, který povolí pro fázi 1 SHA-512, ale pro hashování odpovědi s certifikátem použít SHA-1. Tunel se pak navázal s požadovaným nastavením.

Ještě jsem řešil jednu věc, která je spíše moje neznalost a rychle jsem dostal radu od FortiGate specialisty. Na druhé straně jsou dva subnety, hledal jsem, jak je zadat do fáze 2. Někde v dokumentaci jsem našel, že je třeba vytvořit Address Group, kam se zařadí jednotlivé subnety. V konfiguraci VPN se vybere Named Address a daná skupina. V monitoringu jsem pak viděl oba Phase 2 Selectors, ale navázal se vždy pouze jeden.

Řešení bylo konfigurace pomocí CLI a vytvořit pod stejnou Phase 1 samostatně dvě Phase 2. Naznačeno v Technical Tip: IPSec VPN between a FortiGate and a Cisco ASA with multiple subnets

Nefunkční HTTPS spojení na určité website ve FortiOS 6.2.5

Provedl jsem upgrade z FortiOS 6.2.3 na FortiOS 6.2.5 a hned jsem narazil na nové problémy. Přestal fungovat přístup na některé weby, které dříve fungovaly. Firefox zobrazí chybu

Secure Connection Failed 
Error code: PR_END_OF_FILE_ERROR

Je to při použití politiky v Proxy-based Inspection Mode, kde je pouze SSL Certificate Inspection spolu s libovolným Security Profile (AV, Web Filter, Application Control, IPS). Když se politika přepne do Flow-based Inspection Mode, tak přístup funguje (ale problém je zase s některými jinými adresami).

Je podobné jako známá chyba Proxy web filter with SSL inspection may fail for websites that allow TLS versions below 1.3 after upgrading to FortiOS 6.2.5, ale není to vázané jen na Web Filtering a nevím, co přesně myslí tou SSL inspection.

Nefunkční HTTPS komunikace z Dynamics 365 na Exchange Web Services v Proxy Mode

Velmi dlouho jsem řešil podivný problém, kdy se nedařila komunikace z cloudové služby Microsoft Dynamics 365 (CRM) na interní Exchange 2016 Server. Přesněji jeho službu Exchange Web Services (EWS), která se využívá pro přístup do schránek uživatelů, za pomoci servisního účtu s Application Impersonation rolí. Přístup vracel chybu

Error : System.Net.WebException: The remote server returned an error: (401) Unauthorized.

Stejný problém se ovšem vracel i při přímé autentizaci uživatele (bez Impersonation - zosobnění). Ale pokud se z Dynamics 365 spustil pouze Test připojení, tak proběhl v pořádku (včetně EWS přístupu do schránky). Neprocházel Test a povolení poštovní schránky.

Další věc je, že všechny testy (včetně Impersonation) z Microsoft Remote Connectivity Analyzer procházely bez chyby. Navíc EWS využívají i další služby a také nemají problém. Dlouho jsme tedy řešili, že bude problém v Dynamics 365. Později jsme zkusili napojení na testovací Exchange a to prošlo bez chyb.

Zkoumal jsem nastavení Application Impersonation, které se v diskusích často řeší. Analyzoval jsem logy na FortiGate a testoval vypnutí různých kontrol. Detailně jsem se věnoval Exchange logům EWS i IIS. Skrze FortiGate procházelo při testu mnoho spojení. Řada záznamů byla vidět i v IIS logu, vždy s kódem 401 Unauthorized. V logu EWS byl ovšem vždy pouze jeden záznam. U něj byla chyba

ErrorImpersonateUserDenied - The account does not have permission to impersonate the requested user

U testů, které fungovaly, byl podobný záznam, stejný autentizovaný uživatel (ale jiným formátem zapsaný) i Impersonated uživatel. Samozřejmě bez chyby. Třeba i v IIS logu se dá dobře hledat podle UserAgent = CRM/9.0.0.0/Live.

FortiGate - Proxy Mode a SSL Inspection

Nakonec jsem zjistil, že problém je v určitém nastavení FortiGate. Otestoval jsem, že se takto chová FortiOS 6.2.7 i FortiOS 6.4.5. Pokud je politika v Proxy Mode a zároveň je použit certifikát na FortiGate, řekněme SSL Inspection, tak spojení nefunguje. Jakmile jedna z těchto podmínek splněna není, tak se spojení naváže a vše funguje bez chyb.

Detailnější popis nefunkčního nastavení. Pokud máme více Exchange serverů a chceme na FortiGate využít Server Load Balancing HTTPS spojení pomocí Virtual Server. Tak musíme ve Virtual Server použít certifikát a politiku mít v inspekčním módu Proxy-based. Není asi možnost, jak nastavit Load Balancing na více serverů, aby spojení z Dynamics 365 fungovalo.

Řešení je vytvořit novou publikaci pouze jednoho Exchange serveru (třeba pouze pro Dynamics 365, i když jsem také zjistil, že Internet Service Database na FortiGate sice obsahuje položku Microsoft-Dynamics se spoustou IP adres, ale mezi nimi není ani jedna, z které se k nám Dynamics 365 na Exchange připojuje). Destination NAT vytvoříme pomocí Virtual IP, pokud nepoužijeme SSL inspekci, tak může být politika v Proxy Mode i Flow Mode. Ale asi nám bude vadit, že Firewall nekontroluje provoz. Tak můžeme použít SSL Inspection typu Protecting SSL Server, kde zadáme certifikát serveru. Politika pak musí být ve Flow Mode, aby komunikace fungovala.

Případně informace ke konfiguraci FortiGate Firewall politiky, NAT, Load Balancing, Debug.

Nemám energii hledat, co se liší v komunikaci která funguje, a která ne, při různých nastaveních FortiGate. A již vůbec ne se to snažit řešit s Fortinet Support, to by patrně byla ztráta času. Ale bohužel další důležitá věc, kde FortiGate zklamal, a stála mne spoustu času.

Nefunkční HTTPS spojení z Javy verze 11 a větší při SSL inspekci v Proxy Mode

Zatím největší problém, který se dosud nepovedlo vyřešit a velmi nás omezuje. Dokonce jsem otevřel ticket na Fortinet Support, i když nemám moc dobré zkušenosti s podporou velkých firem, takže se snažím vše vyřešit sám. Ale zde jsem přesvědčen, že jde o chybu FortiOS. Jak špatná je Fortinet podpora popíšu dále.

Popis problému a TLS 1.3

Mám Firewall Policy pro přístup do internetu na HTTPS, která je v Proxy-based Inspection Mode a využívá SSL Deep Inspection spolu s AV, Web Filter, Application Control a IPS. Ze všech webových prohlížečů funguje přístup na webové stránky dobře (samozřejmě po vyřešení CA certifikátu a výjimek pro určité weby). Ale využíváme také mnoho Java aplikací, ať již našich vlastních nebo různých vývojových nástrojů apod. Pokud je použita Java 8, tak je vše v pořádku. Dnes se ale hodně přechází na Java 11 a z ní se nedá připojit na většinu HTTPS stránek. Spojení končí na handshake failure.

Nejprve jsem dělal různé pokusy a debugoval připojení z Javy (vývojáři mi k tomu napsali malou aplikaci). Vyzkoušel jsem různé verze OpenJDK 11 a 14 (Adopt Open JDK, Amazon Corretto) i Oracle Java. Všude stejné chování.

V debug logu bylo vidět, že je problém, když se zkusí navázat TLS 1.3. Java 8 nepodporuje TLS 1.3 a zkouší TLS 1.2, což projde bez problémů. Stejně tak, pokud se v Java 11 vynutí použití TLS 1.2 při startu, parametrem -Dhttps.protocols="TLSv1.2", nebo se TLS 1.3 zakáže v konfiguraci, tak spojení přes TLS 1.2 proběhne.

Zakázání protokolu TLS 1.3 se provádí v konfiguračním souboru java.security doplněním do položky (zde je pouze začátek)

jdk.tls.disabledAlgorithms=TLSv1.3, SSLv3, RC4

Zajímavé je, že prohlížeče se pomocí TLS 1.3 připojí. Proto si nemyslím, že je problém v tomto protokolu nebo podpoře TLS 1.3 na FortiGate.

Pokusy konfigurace na FortiGate

Zkoušel jsem různá nastavení na FortiGate a níže jsou výsledky.

• když se přepne SSL Deep inspection na Certificate Inspection, tak spojení funguje
• pokud nechám SSL Deep inspection, ale vypnu všechny ostatní Security Profiles, tak spojení funguje, jakmile zapnu libovolný další profil, tak nefunguje (patrně se Deep inspekce neprovádí)
• pokud politiku přepnu z Proxy-based do Flow-based, tak začne spojení fungovat, myslel jsem, že to takto vyřeším, ale objevil se jiný vážný problém (popíšu dále)
• pokud se pro adresu nastaví výjimka ze SSL inspekce, tak spojení funguje

Testované adresy

Nejprve jsem měl pocit, že nefunguje přístup na žádný web, ale zjistil jsem, že některé fungují. Příklady funkčních webů a protokol a šifra, co si zvolí prohlížeč.

• https://www.google.com/ TLS 1.3 TLS_AES_128_GCM_SHA256
• https://www.vinodoc.cz TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• https://apache.org/ TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Těch, které nefungují, je mnohem více. Například:

• https://www.seznam.cz/ TLS 1.3 TLS_AES_256_GCM_SHA384
• https://repo1.maven.org TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• https://repo.maven.apache.org/ TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• https://www.microsoft.com TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• https://www.samuraj-cz.com/ TLS 1.3 TLS_AES_256_GCM_SHA384
• https://www.apple.com/ TLS 1.3 TLS_AES_256_GCM_SHA384

Debug na webovém serveru

Porovnání funkční a nefunkční komunikace (je vidět, že na některém serveru stejné parametry fungují a jinde ne) mne dovedlo k jedné informaci, kterou jsem ověřil na testovacím Linuxovém web serveru. Pokud se používá OpenSSL 1.0.x (které nepodporuje TLS 1.3), tak připojení funguje. Pokud se použije OpenSSL 1.1.1, tak nefunguje, i v případě, kdy se nepovolí TLS 1.3 v konfiguraci serveru.

Při zapnutí debugu na serveru se také zobrazila již více navádějící informace (to jsem zkoušel, až po debugu na FortiGate popsaném dále).

fd[000e] OpenSSL error[0x14201076] tls_choose_sigalg: no suitable signature algorithm

Zkoušel jsem provádět různý debug na FortiGate. Jednotlivé věci jsou orientačně popsány v dalších kapitolách.

FortiGate (FortiAnalyzer) logy

V Traffic logu FortiGate je Action: Accept a Firewall Action: server-rst. V logu SSL inspekce nic. V Event logu (All Types) se dá pro cílovou IP nalézt událost WAD SSL Fatal Alert received, handshake failure.

Výpis session

Nic zajímavého neukáže.

diagnose sys session filter src 10.0.100.10 
diagnose sys session filter dst 192.168.50.45 
diagnose sys session list
session info: proto=6 proto_state=56 duration=2 expire=2 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0
 use=5
...

Packet Sniffer

diagnose sniffer packet Local 'host 10.0.100.10 and host 192.168.50.45' 4 100

interfaces=[Local]
filters=[host 10.0.100.10 and host 192.168.50.45]
24.710746 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: syn 2544371997 
24.713290 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: syn 3361056785 ack 2544371998 
24.713921 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: ack 3361056786 
24.771173 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: psh 2544371998 ack 3361056786 
24.771303 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: ack 2544372422 
24.773966 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: fin 3361056786 ack 2544372422 
24.774212 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: ack 3361056787 
24.777604 Local -- 10.0.100.10.51369 -> 192.168.50.45.443: psh 2544372422 ack 3361056787 
24.777648 Local -- 192.168.50.45.443 -> 10.0.100.10.51369: rst 3361056787

Ani Packet Sniffer moc nepomůže. Člověk z podpory jej spouštěl rozšířený (prý to dokáží převést do Wiresharku).

diagnose sniffer packet any 'host 192.168.50.45' 6 0 1

Debug Flow

diagnose debug flow filter proto 6
diagnose debug flow filter saddr 10.0.100.10
diagnose debug flow filter daddr 192.168.50.45
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 100
diagnose debug enable

Debug WAD

WAD daemon se používá pro SSL inspekci v Proxy Mode. Pro Flow Mode je to IPS engine. Pro debug je potřeba zapnout level verbose (což jsem prve nedělal). Pak se již určité informace zobrazí.

diagnose wad filter dst 192.168.50.45
diagnose wad debug enable category ssl
diag wad debug enable level verbose
diagnose debug enable

Pouze pár řádků z výstupu.

...
SESSION-ID: d4f4e378b0c9b6e00d1ebf5c0c9106d4ae2021021e6c719f80d354667f41aa75
wad_ssl_proxy_find_session(2667): can't find the session!
__wad_ssl_proxy_filter_ciphers(7560): unsupported num = 12, supported num = 32, intersection num = 32
wad_ssl_proxy_filter_ciphers(7609): wsp(0x7f49d461a880/6) cipher filter: ns=12, is=32
wad_ssl_proxy_srv_continue_fwd_client_hello(9236): sp=0x7f49d461a880/6 start handshake with server. changed_ch=1
wad_ssl_proxy_clt_caps_find_session(12611): sp=0x7f49d461a510/7 find session from (nil)
...
wad_ssl_port_caps_on_alert_recv(12368): fts recv alert level=2 desc=handshake failure
...

Packet Capture

Zachycení komunikace nakonec ukázalo nejvíce a patrně identifikuje problém. Nejprve jsem zachytával komunikaci Wiresharkem na stanici. Ale ověřil jsem, že pomocí Network > Packet Capture v GUI FortiGate, pro rozhraní do sítě, kde je klient, je výsledek stejný a zachycení je pohodlné. Následně jsem pomocí WireSharku provoz analyzoval. Musím přiznat, že až člověk z podpory mne navedl k tomu, abych zachytil komunikaci na vstupním (interní síť) i výstupním (internet) rozhraní. On se totiž pořád snažil nastavit interface na any, když mu to nešlo v GUI, tak použil Packet Sniffer v CLI.

Následující obrázek ukazuje komunikaci od klienta na FortiGate.

Na dalším je vidět, jak vypadá od FortiGate na server.

Analýza komunikace

Je vidět, že cílový server dostane Client Hello pro vyjednání TLS komunikace a hned odpovídá Handshake Failure. Porovnával jsem tedy, jak vypadá Client Hello, které odesílá Java, a jak vypadá to, které odchází z FortiGate. Ten navazuje komunikaci na cílový server za klienta a patrně vychází z povolených šifer ve své konfiguraci. Myslel jsem, že FortiGate bude vytvářet Client Hello vždy stejně (dle konfigurace), ale podle testů je vidět, že se hodně odráží od parametrů, které přijdou od klienta.

Nevyznám se detailně v TLS protokolu a zaráží mne několik věcí. Třeba uvádění verze TLS, kdy Wireshark někde označuje v Client Hello paketu TLS 1.2 Record Layer a jinde (podle mne stejné parametry) TLS 1.3 Record Layer. Pak je tam několikrát Version: TLS 1.2 (a třeba od prohlížeče TLS 1.0) a finálně se přitom naváže TLS 1.3 (samozřejmě se uvádí seznam nabízených protokolů v supported_versions).

Porovnání ukázalo, že Java nabízí 45 Cipher Suites, FortiGate z nich několik odstraní a nabízí 33 Cipher Suites. Ale všechny hlavní a podporované šifry na serveru zde jsou, včetně té, která se bez SSL inspekce použije. Liší se trochu i některá rozšíření (extension). Podle chyby, zobrazené při debugu na serveru, jsou hlavní dvě z nich:

• signature_algorithms
• signature_algorithms_cert

Rozšíření signature_algorithms obsahuje stejných 16 Signature Hash Algorithms od Javy i od FortiGate. Rozšíření signature_algorithms_cert od Javy obsahuje totožných 16 algoritmů, ale od FortiGate je jich pouze 9 z nich. (nenabízí RSASSA-PKCS1-v1_5 algorithms a Legacy algorithms). Porovnání je na následujících obrázcích.

Díval jsem se na komunikaci v různých případech, kdy se spojení naváže. Zaměřil se na extension signature_algorithms_cert.

• jediná stránka s TLS 1.3, která mi z Javy 11 funguje, je google.com, zajímavé je, že v tomto jediném případě FortiGate toto rozšíření nepoužije
• když se v Java 11 zakáže TLS 1.3, tak Java stále toto rozšíření vkládá, ale v paketu od FortiGate není
• z prohlížečů spojení vždy funguje, vypadá to, že ty toto rozšíření nevkládají
• na některé stránky s TLS 1.2 se z Javy 11 připojit lze (třeba, kde je OpenSSL 1.0.x), v paketu od FortiGate se rozšíření nachází, ale podle informací na internetu jej některé servery nepoužívají (pracují pouze se signature_algorithms)
• když je SSL inspekce vypnutá nebo je politika ve Flow Mode, tak to vypadá, že odchází originální Client Hello, které vytvořila Java (a rozšíření má všech 16 algoritmů a spojení se naváže)

Hledal jsem nějakou dokumentaci, zajímavé je třeba The Evolution of Signatures in TLS a Signature algorithms. Vypadá to, že rozšíření signature_algorithms, bylo přidáno v TLS 1.2. A signature_algorithms_cert až v TLS 1.3 (starší verze TLS 1.3 ho ani nezmiňuje), i když ho patrně používají i některé implementace TLS 1.2.

Nepovedlo se mi nalézt, jak definovat povolené algoritmy v Javě 11 nebo na webovém serveru, na rozdíl od určení povolených Cipher Suites. Stejně tak zjistit, jaký z nabízených algoritmů se na serveru použil.

Závěr

Z výše popsaného jsem přesvědčený, že ve FortiOS je chyba (bug). Špatně pracuje s rozšířením TLS zpráv signature_algorithms_cert. Pokud dané algoritmy povolí pro signature_algorithms, tak by je měl povolit i pro signature_algorithms_cert. Velmi mne překvapuje, že na tento problém již nenarazil jiný zákazník, hlavně velké firmy. Pořád vycházím z toho, o čem mne přesvědčovali zástupci všech výrobců FW, že SSL inspekce se dnes opravdu běžně používá. Potom aplikace v Java jsou naprosto běžné a přechod na verzi 11 je dnes doporučený.

Pokračování řešení a testy

Kontaktoval jsem český Fortinet, kde mi hned reagoval jeden technik a ochotně mi pomáhal, i když říkal, že na podporu nemá vliv. Díky němu jsem získal Eval licenci na FortiGate-VM. Udělal jsem tedy testy čistě nainstalovaného FortiOS 6.2.3 s minimální konfigurací. Problém zde byl. Zkoušel jsem postupné upgrady a nakonec i čistou instalaci FortiOS 6.4.2. Všude se popsaný problém projevuje.

Pozn.: Mimochodem. Nechápu, proč se ve FortiOS 6.4 přesunulo FortiView a Monitor do Dashboard. Navíc u mne defaultní položky v Dashboard vypadají jinak, než na všech obrázcích z dokumentace.

V té době jsem dostal zprávu ze suportu, že problém začal řešit vývojový tým. Po pár dnech, že zjistili, že chování odpovídá známému problému s ID #658654. Aktuálně se vývojáři věnují opravě tohoto problému. Mám dostat informaci o průběhu.

FortiOS 6.2.6 a neopravený bug

Podle Fortinet Supportu měla být chyba opravena ve FortiOS 6.2.6. Také FortiOS 6.2.6 Release Notes uvádí jako opravený problém ID 658654 (Cannot access the specific website using proxy-based UTM with certification inspection.) I když z popisu bych nepoznal, že jde o můj problém.

Provedl jsem upgrade clusteru na verzi FortiOS 6.2.6 a rychlé testy hned ukázaly, že problém stále trvá. Provedl jsem řadu pokusů a chování je úplně identické jako dříve. Co je horší. Předtím, když se nastavila vyjímka ze SSL Inspection (nebo na politice byla pouze Certificate Inspection místo SSL Deep inspection), tak komunikace fungovala. Nyní se projeví stejný problém. Vše funguje pouze ve Flow-based módu nebo když není použit žádný Security Profile.

Zadal jsem nový ticket na Fortinet Support.

Přístup na weby se SSL inspekcí ve Flow Mode

Při testech problémů s Java 11 jsem zjistil, že pokud je politika v inspekčním módu Flow-based, tak vyjednání spojení funguje. Přepnul jsem tedy politiku pro celou firmu a po pár hodinách se mi ozvalo mnoho lidí, že mají problémy s komunikací do internetu na HTTPS. Ve výsledku šlo o pár stejných adres. Když jsem je testoval z prohlížeče, tak mi zprvu vše fungovalo, ale zjistil jsem, že v určitou dobu se stránka opravdu nenačte. Ale pokud v prohlížeči zkusím načíst znovu, tak se již většinou zobrazí. Pak nějakou dobu daná adresa funguje. Kde jsme narazili na problém:

• https://www.linkedin.com/ - náhodou jsem zjistil, že se mi nenačítá LinkedIn, poprvé stránka timeoutuje
• https://epodani.cssz.cz/ - pro nás velmi důležitá adresa, která se volá z aplikace (takže nelze provést nové načtení), poprvé se nepovede vyjednat SSL, vrací SSL_ERROR_BAD_HANDSHAKE_HASH_VALUE
• naše Java aplikace - funguje jako klient (v tuto chvíli s Java 8) server, v průběhu práce začala opakovaně vyskakovat chyba Read time out (SocketTimeoutException)

Protože se chyby objevují občas, tak se velmi špatně debugují. Na skupinu uživatelů (kteří ovšem nepoužívají uvedené dvě problematické aplikace) jsem nechal Flow Mode povolený. Nehlásí mi žádný problém. Ale již, když jsem hledal informace k problému s Java 11, tak jsem našel mnoho diskusí, kde řeší lidé problém s přístupem na určité webové adresy. Občas dokonce jen z určitého prohlížeče. Řešení uvádí naprosto různé, často návrat k nějaké předchozí verzi FortiOS. Různé přepnutí do Proxy mode nebo naopak Flow mode (očividně každému funguje něco jiného). Někomu prý TAC poradil zablokovat na FortiGate TLS 1.3.

Moje zkušenost s Fortinet Support

Jak jsem psal, nemám s podporou velkých firem moc dobré zkušenosti. V minulosti jsem něco řešil se Symantec, Microsoft, Cisco. Radši se snažím problém vyřešit sám. Ale zde si myslím, že je to chyba v systému. Podpora Fortinetu je ještě horší, než co jsem dosud zažil.

Hned při vytvoření ticketu jsem vše popsal, kdy problém nastává a kdy ne, přiložil jsem debugy, logy, zachycení provozu. Nechtěl jsem dávat naši konfiguraci, ale tu si samozřejmě hned první zprávou vyžádali. Tak jsem ji poslal. Měli vše, aby si tento problém vyzkoušeli. Já myslím, že je naprosto obecný, takže by ani nemuseli zkoušet naši konfiguraci, ale pouze vyzkoušet spojení z Javy 11. To se dosud nestalo.

Prvních 14 dní se nedělo nic. Pak mne kontaktoval zahraniční inženýr a domluvilo se vzdálené spojení. Jsem přesvědčen, že nečetl můj popis problému a již vůbec se nedíval do zaslaných podkladů. Na vše se vyptával, debugy, které jsem poslal, si sám vytvořil znovu. Pak pokaždé řekl, že si to musí projít, nebo chtěl ještě něco poslat, a domluvilo se další spojení. A při tom spojení opět stejně. Teprve v tu chvíli začal prohlížet zaslané podklady. Na nic nebyl dopředu připravený.

V té chvíli jsem již došel k přesvědčení, že je problém v Client Hello a TLS rozšíření signature_algorithms_cert. Vše jsem mu detailně popsal, tak jako výše. Ale přijde mi, že to ignoruje a mne neposlouchá. Snaží se třeba problém svést, že se jedná o naši aplikaci (nechápe argument, že se nelze z obecné Javy připojit na stránku Microsoft). Stále dokola si nechává poslat zachycenou komunikaci. A snaží se něco hledat v CLI (přijde mi, že ho příliš nezná).

A to nejjednodušší, aby si problém zkusil někde v labu, to asi není schopen udělat. Po měsíci se začalo řešit s vývojovým týmem a vše se pohnulo.

Pozn.: Docela pozdě jsem zjistil, že zprávy do mailu nechodí dobře a je potřeba si je otevírat na webu. Nejen, že v nich chybí konce řádků, ale někdy chybí kus zprávy (asi se objeví nějaký znak, který v jejich systému způsobí ukončení a odeslání mailu).

Časový průběh

• 4. 8. 2020 založení ticketu
• 4. 8. 2020 velice záhy mne odpověděl člověk s českým jménem, požadoval konfiguraci a schéma sítě a radil udělat upgrade na 6.2.4
• 4. 8. 2020 vše jsem mu poslal, napsal, že 6.2.4 je nepoužitelná (nechodí VPN) a poslal dotaz, již se neozval
• 10. 8. 2020 automatická zpráva, že ticket byl eskalován na senior inženýra
• 16. 8. 2020 plánoval si se mnou vzdálené spojení
• 18. 8. 2020 proběhlo první spojení
• 25. 8. 2020 proběhlo druhé spojení
• 31. 8. 2020 proběhlo třetí spojení
• 8. 9. 2020 jsem dostal požadavek od vývojového týmu na zachycení komunikace na klientovi, serveru i FortiGate ve stejnou chvíli
• 10. 9. 2020 přišla zpráva, že R&D team zjistil, že chování odpovídá známému problému s ID #658654 a pracuje se na opravě
• 27. 9. 2020 jsem provedl upgrade na FortiOS 6.2.5
• 6. 10. 2020 přišla zpráva, že developer team chybu opravil a bude součástí FortiOS 6.2.6 plánované na 3. 11. 2020
• 30. 11. 2020 jsem provedl upgrade na FortiOS 6.2.6 (vyšla někdy v polovině listopadu), problém trvá stále, dokonce se nyní projevuje, i když nastavíme vyjímku ze SSL Deep Inspection
• 31. 1. 2021 jsem provedl upgrade na FortiOS 6.2.7 na základě požadavku supportu (z 25. 1. 2021), kteří psali, že sice problém stále řeší, ale protože je k dispozici nová verze, tak požadují otestování. Problém je pořád stejný.
• 9. 2. 2021 přišla zpráva, která mne již vážně naštvala. Po 5 měsících řešení, kdy již dvakrát uznali bug a jednou tvrdili, že ho opravili, se vrátili úplně na počátek. Poslali dotazy, které jsme řešili na začátku, aby se tím vůbec zabývali. Zase tam tvrdí, že je problém na našem serveru. Vůbec nechápou, co jim stále píšu, že problém je s velkými servery, jako Microsoft, Apple či Apache. I když jsem jim dokázal, že problém je v rozšíření signature_algorithms_cert, tak hledají problém v podporovaných Cipher Suites. Takže jsem jim znovu detailně popsal chování v různých situacích a zachytil komunikaci před FortiGate a jak ji modifikuje. Je tam jasně vidět, že v Proxy Mode (za určitých podmínek) FortiGate upraví Client Hello tak, že ho servery odmítnou. A od FortiOS 6.2.6 se to děje i při Certificate Inspection. Tak jsem zvědavý, jaké bude pokračování.
• 27. 4. 2021 přišla zpráva, že ten den vyšel FortiOS 6.2.8, kde je chyba opravena, a že mám 5 dní na otestování, pak se ticket uzavře (vtipné). 1. 5. jsem novou verzi nasadil, a zdá se, že konečně opravdu chybu opravili. BTW začal jsem sledovat RSS kanál https://pub.kb.fortinet.com/rss/firmware.xml, kde jsou informace o nových verzích.