Aktualizace 22.5.2018
Protože se ze SZR nikdo neozýval, tak jsme se začali vyptávat a rozesílat e-maily. Dozvěděli jsme se, že upgrade proběhl 7.5.2018 (nikomu nedali vědět) a máme to vyzkoušet. První testy vypadají OK, takže se snad konečně podařilo celou kauzu uzavřít. Sice ještě stále nefunguje TLS 1.2 na eGON9, ale eGON4 a eGON 5 se už tváří v pořádku.
Aktualizace 23.4.2018
Podpora SZR na naši žádost požadavek #30473 zpětně otevřela, dokud nebude vyřešen související požadavek #31122 na nový firmware F5 (reverzní proxy a zřejmě i jejich SSL terminace), což je dobrá zpráva.
Špatná zpráva je tak, že ISZR má architekturu udělanou tak, že produkční i testovací prostředí ji nějak sdílí s produkčním a plánovaný upgrade firmware F5 na testovacím prostředí (to je upgrade, po kterém by snad konečně, skoro po roce, měla chodit komunikace přes TLS 1.2 i v novějších systémech) ovlivní i produkci a proto ji nelze provést rychle, protože se musí některé AIS na produkci přizpůsobit.
Co z toho plyne? Že u tak kritické věci, jakou jsou základní registry, nelze poměrně závažnou věc, jakou je upgrade firmware, otestovat předem na testovacím prostředí, ale bude se dělat přímo na produkci, protože je minimálně částečně (F5) sdílena s testovacím. To bude možná na produkci nějaké nemilé překvapení (přál bych si, aby nebylo).
Celá kauza se táhne už od srpna 2017 a stále to nefunguje :(.
Aktualizace 29.3.2018
Podpora SZR označila náš požadavek #30473 v helpdesku za vyřešen s tím, že byla nalezena příčina a bude se řešit v novém požadavku #31122. Takto se zřejmě vylepšují statistiky. Požadavek z mého pohledu vyřešen není, testovací prostředí ISZR nefunguje správně. To, že byla nalezena (možná) příčina neznamená, že se problém vyřešil.
A jaká je vlastně příčina? Zřejmě je problém v reverzní proxy F5 a bude se muset provést její upgrade, aby podporovala RSA_SHA256. Není mi z jejich vyjádření zřejmé, zda bude stačit upgrade softwarový, nebo bude nutný nový HW.
SZR dostala za úkol do příštího jednání Rady základních registrů, která se má konat 26.4.2018 upřesnit, zda i za této nejisté situace je termín přechodu na TLS 1.2 k 1.8.2018 stále platný.
Aktualizace 27.3.2018
Konečně známe příčinu, proč rozumně nefunguje ISZR po přechodu na TLS 1.2 (aktuálně na testovacím prostředí, které má být už v konečné konfiguraci).
Problém je v tom, že jejich SSL terminace neumí zpracovat signaturu založenou na RSA_SHA256 a vyšší (byť ji při handshake jejich server nabízí), ale pouze RSA_SHA1. Takže z novějších systémů (např. Windows 10), které již RSA_SHA256 standardně používají, si neškrtnete (pozn.: novější asi není to správné slovo, Windows 10 jsou již 2,5 roku). Z Windows 7, které používají standardně RSA_SHA1, to funguje. Ale opravdu chce ISZR přecházet na TLS 1.2 a používat RSA_SHA1? Navíc RSA_SHA256 při SSL handshake nabízejí, ale neumí a Windows 10 nejdou pak přinutit používat RSA_SHA1.
Komunikace z Windows 7:
Komunikace z Windows 10:
Pokud tohle půjde na produkční ISZR, tak tím odříznou minimálně systémy pracující na Windows 10 nebo Server 2016 R2.
Přechod na TLS 1.2 se začal řešit loni v říjnu a stále nefunguje.
Aktualizace 7.3.2018
Podařilo se nám spolu s ROS prosadit, že se zruší RC4 a DES, takže tohle by údajně měla být konečně konečná definitivní a finální verze:
Má to jednu vadu - pořád to nefunguje:
System.ServiceModel.Security.SecurityNegotiationException: Nelze vytvořit zabezpečený kanál pro režim SSL/TLS s autoritou pub.egon.cms. ---> System.Net.WebException: Požadavek byl přerušen
Pátráme dál. Více informací o vypnutí TLS 1.0 a 1.1 si můžete přečíst na webu SZR.
Aktualizace 5.2.2018
Na provozní poradě SZR byl (zcela vážně) prezentován návrh, že problém bude "vyřešen" tak, že se povolí cipher suite TLS_RSA_WITH_RC4_128_SHA. Spolu se zástupci ROS jsme se snažili protestovat, ale asi to nebude moc platné.
Aktualizace 30.11.2017
Na provozní poradě SZR nám bylo sdělena zásadní informace, že přechod na TLS 1.2 a nové Cipher Suite se v plánovaném termínu neuskuteční.
Dodavatel (AutoCont) nejprve opraví chyby, aby bylo prostředí v souladu s dokumentem, pak bude následovat nové testování a pak teprve někdy později v roce 2018 (zatím odhad březen) dojde k přechodu na TLS 1.2 a vypnutí starších verzí.
Aktualizace 9.11.2017
SZR (resp. Autocont) dnes udělalo nějaké změny, takže se na pub.egon.cms lze dostat přes TLS 1.2 s TLS_RSA_WITH_AES_128_CBC_SHA. Bohužel ale stále stav nesouhlasí s popisem, protože je například povolen Cipher Suite TLS_DHE_RSA_WITH_AES_256_GMC_SHA384, který by být povolen neměl.
Aktualizace 1.11.2017
Podařilo se nám získat neoficiální vyjádření (není od SZR):
O níže popsaných problémech při komunikaci s ISZR u některých připojených AISů víme a snažíme se je řešit. V současné době pracujeme na řešení, které problémy odstraní. Nápravné opatření však zahrnuje rizikové činnosti jak na testovacím, tak na produkčním prostředí. Tyto rizikové činnosti nám však SZR zatím nepovolilo. Se SZR jednáme o termínech.
Z toho a dřívejších zjištění plynou dvě základní věci:
- prostředí EGON-4 (https://egon.gov.cz, https://pub.egon.cms) a EGON-5 (https://edit.egon.gov.cz, https://edit.egon.cms) neodpovídají stavu podle Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1 a podporují pouze Cipher Suite s RC4, který je ale dle dokumentu zakázán a naopak nepodporují Cipher Suite s AES, které by měly být povoleny a podporovány,
- pokud jste si podle výše uvedeného dokumentu otestovali změnu na TLS 1.2, která má být v produkci od 1.1.2018, tak jste neotestovali vůbec nic a paradoxně, pokud vám testy prošly, tak zřejmě s RC4, což je špatně,
- vnitro o problémů ví, ale na odbornou veřejnost, vývojáře a provozovatele AIS zvysoka dlabe a neobtěžuje se upozornit na to, že testování, o kterém píší, je zcela bezzubé a zavádějící,
- vůbec nemáme jistotu, jak skutečně bude produkční prostředí po 1.1.2018 z hlediska podporovaných Cipher Suite vypadat a zda budeme fungovat.
Zatím stále čekáme na oficiální vyjádření vnitra, resp. SZR na náš záznam v helpdesku ID 28313.
Aktualizace 31.10.2017
Problém jsme zapsali do helpdesku SZR pod ID 28313. Již dříve jsme zapsali problémy ID 27025 a 27786, ale oba byly uzavřeny následujícím způsobem, v přímém rozporu s Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1 (Cipher Suite s RC4 tam není povolen):Status: 08-VYŘEŠEN, Dobrý den jako dočasné řešení nastavte šifrování TLS_RSA_WITH_RC4_128_SHA na úrovni klienta. IE 10 používá protokkoly, které splňují podmínky nastaveni 128 bit šifrování.
Status: 08-VYŘEŠEN, Dobrý den, rozhodně je třeba používat pouze IE. FF 50 a vyšší ani ostatní nepodporují RC4. V odkazu je postup aktivace požadovaného šifrování v IE.
Původní text
Správa základních registrů (SZR) zveřejnila dokument s názvem Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1, ve kterém od 1.1.2018 oznámila vypnutí protokolů TLS 1.0 a TLS 1.1. Podporovaný bude pouze protokol TLS 1.2 a následující Cipher Suite (CS):- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
Protože jsou naše systémy na ISZR napojené, tak jsem začal upravovat konfigurace a aplikace. Podle popisu SZR má být na testovacím prostředí změna provedena a je tedy možné odladit systémy:
"V období od 1. 8. 2017 do 31. 12. 2017 otestujte v testovacím prostředí, že váš AIS bezproblémově komunikuje s ISZR i s takto změněným nastavením kryptografických protokolů."
Dva dny jsem se snažil rozchodit připojení na testovací prostředí (pub.egon.cms), ale marně. Neustále jsem končil na chybě, že se nepodařilo sestavit bezpečné spojení. Měl jsem podezření, že mám něco špatně nakonfigurované a aplikace nejede přes TLS 1.2 nebo podporované CS. Klesl jsem až tak hluboko, že jsem sáhl po Microsoft Message Analyzer (něco jako Wireshark) a monitoroval jsem TCP komunikaci. Ověřil jsem, že nabízím podporované protokoly:
Podle odpovědi serveru jsem usoudil, že akceptuje CS TLS_RSA_WITH_AES_128_CBC_SHA:
Vše vypadalo OK, ale spojení stále padalo. Po dvou dnech kolega zkusil aplikaci na jiném, starém stroji, kde je ještě Windows 2008 (ani to není R2). K mému překvapení aplikace fungovala. Tak jsem opět hledal v TCP a zjistil jsem, že spojení jede s CS TLS_RSA_WITH_RC4_128_SHA:
Problém je v tom, že TLS_RSA_WITH_RC4_128_SHA podle dokumentu SZR nemá být podporován a také, že od 1.1.2018 nebude podporován na produkčním prostředí:
Částečně tento stav potvrzuje i fakt, že helpdesk SZR mému kolegovi, který řešil spojení z Internet Exploreru na testovací prostředí (chtěl získat WSDL), odpověděl, že si musí povolit RC4.
Z toho plyne, zřejmě testovací prostředí ISZR neodpovídá tomu, co je v dokumentu uvedeno. Pokud jste si podle pokynů SZR vaše systémy otestovali proti testovacímu prostředí, tak to ještě neznamená, že vám od 1.1.2018 budou fungovat. Vypadá to, že testovací prostředí má nějaký problém s CS jako TLS_RSA_WITH_AES_128_CBC_SHA a funguje jen s CS založenými na RC4, což je přesně opak toho, v jakém stavu by to mělo být.
Jestli proti jejich testovacímu prostředí ISZR fungujete, nenechte se tím ukolébat a prověřte, že nepoužíváte CS na RC4, ale nějaký CS uvedený v tom dokumentu, jinak od 1.1.2018 nemusíte fungovat (pokud RC4 vypnou a nevyřeší se pravděpodobný problém s neakceptací jiných CS).
Budu to řešit přes Helpdesk SZR a dám vědět, jak to dopadlo. Problém samozřejmě může být na mé straně. Je to zvláštní. Pochopil bych, že jen vypnuli TLS 1.0 1.1, zapnuli TLS 1.2 a zapomněli odstranit RC4. Ale to, že zřejmě neakceptují např. TLS_RSA_WITH_AES_128_CBC_SHA je podivné, i v souvislosti s tím, co je na druhém obrázku, kdy mi jejich serveru odpoví, že je to OK a přesto se spojení nenaváže (zkoušeno z více strojů bez podpory RC4).
PS: Má aplikace (založena na .NET 4.7), se kterou to zkouším, je OK, protože na produkčním prostředí s TLS 1.0 jede bez problémů. Problém se objeví pouze tehdy, pokud jdu na testovací prostředí, zapnu natvrdo TLS 1.2 a zakážu všechny CS na RC4.
