Pozor od 1.1.2018 na komunikaci s ISZR

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.

Všechna státní data jako otevřená (Open data)

Příznivci otevřených dat, oslavujte a radujte se. V pátek 22.9.2017 nám přišel k připomínkám níže uvedený návrh usnesení vlády ČR  "o zveřejňování dat, která jsou vedena v informačních systémech veřejné správy spravovaných ústředními správními úřady, jako otevřených dat".

Tento návrh zjednodušeně řečeno říká, že všechna neprovozní data vedená v IS státní správy by měla být zpřístupněna jako otevřená data, pokud tomu nebrání nějaké jiné právní předpisy. Týká se to dat, které jsou vedena v IS, které budou vytvořeny nebo rozvíjeny a využitím zákona o zadávání veřejných zakázek. Zjednodušeně řečeno, pokud budeme po 1.1.2018 dělat veřejnou zakázku (VZ) na nový systém nebo na podporu stávajícího, tak už s tím  musí počítat.

Záměr je to podle mě velmi dobrý a chvályhodný a směřuje k tomu, aby se na otevřená data myslelo při vypisování nových VZ, což je správná cesta. Bohužel ale dojem z tohoto záměru velmi kazí fakt, že pro jeho připomínky se použila zkrácena lhůta, konkrétně je musíme odeslat do 29.9.2017. Reálně na připomínky máme 3 dny, protože 28.9.2017 je státní svátek a většina lidí má na 29.9.2017 naplánovanou dovolenou, takže je musíme dát dohromady do 27.9.2017, tj. 3 dny, přičemž otázek a nejasností v dané problematice je spousta.

Na první pohled to vypadá, že není  žádný problém. Ale když jsme se rychle trochu zamysleli nad možnými dopady na nás, tak jsme zjistili, že vlastně ani přesně nevíme, co vše pod otevřená data spadá.  Podle  §3 odstavce (11) zákona o svobodném přístupu k informacím 106/1999 Sb. je definice otevřených dat následující:

"Otevřenými daty se pro účely tohoto zákona rozumí informace zveřejňované způsobem umožňujícím dálkový přístup v otevřeném a strojově čitelném formátu, jejichž způsob ani účel následného využití není omezen a které jsou evidovány v národním katalogu otevřených dat".

Pokud by se někdo zaradoval, že všechny úřady budou muset zveřejnit například i data z personálních systémů, tak ho rovnou zklamu, protože tato povinnost se naštěstí (jinak bychom se z toho asi zbláznili) nevztahuje na provozní systémy, které jsou definovány takto:
"Provozní informační systém - informační systém zajišťující informační činnosti nutné pro vnitřní 
provoz příslušného orgánu, například účetnictví, správu majetku, nesouvisející bezprostředně 
s výkonem veřejné správy – viz § 2 písm. u) zákona o ISVS."

Uvedu pár okruhů a otázek, které mě napadly při prvním přemýšlení. Jedním z okruhů je například náš výměnný formát ISKN (NVF), který obsahuje prakticky všechna data ISKN. Je strojově čitelný a je dokumentovaný. Dnes je ale placený, není dostupný online dálkovým přístupem, není veřejný a obsahuje osobní údaje. Stačí tedy, pokud ho zveřejníme dálkovým způsobem?

1) Veřejný = zdarma?

Pokud stačí jeho zveřejnění, může být placený, nebo musí být poskytován zdarma? Pokud zdarma, tak co se stane našimi příjmy, které musíme povinně odvádět do státního rozpočtu? Není to zrovna malá částka (pozn. možná to nevíte, ale i když jsme státní správa, tak máme nařízenu splnit určitou velikost příjmů, kterou musíme odvést do státního rozpočtu, na kterou jsou vázány naše výdaje a když ji nesplníme, tak máme docela problém).

2) Osobní údaje 

Co s osobními  údaji, které ve výměnném formátu jsou?

Máme je z něj nějak vyřezávat, kvůli GDPR?  Když není veřejný a víme, komu byl poskytnut, tak je to rozdíl proti stavu, že bude někde veřejně dostupný. Už dnes máme problém s ÚOOÚ, kterému se nelíbí, že jsou v katastru zveřejňována rodná čísla (pozn. je to odvěký spor, protože katastr je ze zákona veřejný). Pokud si někdo koupí list vlastnictví, tak je to velký rozdíl proti tomu, když by si hromadně a anonymně stáhl výměnný formát s osobními údaji všech vlastníků a jiných oprávněných všech nemovitostí ČR.

3) Veřejné = přístupné anonymně?

Pokud je něco zveřejněno jako open data, tzn. veřejně online dostupné, znamená to, že to musí být dostupné i anonymně? Nebo to může být přístupné jen po registraci, abychom věděli, kdo data odebral? Souvisí to i s předchozím odstavcem.

4) Stačí zveřejnit výměnný formát?

NVF obsahuje prakticky všechna zajímavá data z ISKN. Stačí tedy, pokud ho zveřejníme a splníme tím naši povinnost? Máme spoustu jiných výstupů, které využívají stejná data, jako jsou ta v NVF. Problém v tom, že například Výpis z KN je tak komplikovaný výstup, který, jak si troufám tvrdit,  nedokáže nikdo na základě dat z NVF správně sestavit tak, aby odpovídal tomu od nás (často i my s ním máme problémy :-) ). Dnes je poskytován elektronicky. Musí být dostupný i jako otevřená data nebo ne? Takových výstupů a sestav máme mnoho.

5) Náklady
Zveřejňování všech dat jako otevřené nepochybně přinese i náklady na úpravy existujících IS (nové s tím budou počítat, tak to tak strašné nebude) a infrastrukturu, což plyne i ze zkušeností států, které již takto data poskytují. V tento okamžik je obtížné náklady vyčíslit, v rámci návrhu usnesení jsou obecně rozmělněny do běžných rozpočtů jednotlivých organizací.

Mohl bych pokračovat dál. Výše uvedené otázky jsou jen to, co nás rychle napadlo. 

Jednodušší je to u RÚIAN. Ten má výměnný formát VFR, který je už dnes veřejný, zdarma, osobní údaje neobsahuje a můžeme ho celkem bez problémů jako open data v katalogu zveřejnit.

Zkrácená lhůta na připomínky u sice krátkého, ale závažného materiálu, který má velké dopady, je hodně podivná. Nenapadá mě žádný důvod, proč by v tomto případu mělo být využito zkrácené připomínkové  řízení, které se má používat ve výjimečných situacích a má být řádně odůvodněno:

Tohle je navíc naplánované tak, že je přes státní svátek a velmi pravděpodobné dovolené, což nám neumožní udělat kvalitní připomínky, protože záběr je velmi široký. Argument může být, že se to týká až VZ po 1.1.2018, ale to nemění nic na tom, že připomínky musíme dávat k záměru jako takovému, v obecné rovině. 

Celé je to podivné a "zkráceně zkrácený" termín vnáší pochybnosti, zda to není spíše jen rychlé politické rozhodnutí za účelem jeho bezproblémového protlačení ještě před volbami, aby v nich mohlo být patřičně využito. V materiálu "odůvodněno" takto:

Zveřejňování státních dat jako otevřená je určitě správná cesta, ale rozhodně bych to takto neuspěchával. Usnesení dále vůbec neřeší případné dopady na právní úpravy, které určitě v mnoha případech vzniknou, jinak nebude možnost publikace otevřených dat plnohodnotná. Ale to se už opravdu ve 3 dnech nedá zvládnout promyslet. Bohužel to vypadá jen jako předvolební, rychlý výkřik, bez nějakého hlubšího promyšlení. 

Úkol je zadán, tak ho musíme nějak zvládnout. Musíme jen doufat, že nenastane žádná mimořádná situace, který by způsobila vyhlášení veřejné zakázky na něco pro ISKN po 1.1.2018 (i to už jsme museli), protože pak by se už i na ISKN tato povinnost vztahovala. ISKN bohužel na tuto situaci není připraven, protože je rozdíl poskytovat NVF offline způsoben, na objednávku, nebo ho mít dostupné online, pro všechny a ještě možná s upravenými daty. Generování NVF je v ISKN nejnáročnější dávková úloha. Museli bychom tam úpravu pro otevřená data nějak rychle doplnit, doslova a písmene dolepit", což nemám rád, takové divoké úpravy moc systémově řešit nelze.

Po vyřešení výše uvedených dotazů (a spoustě dalších) začneme ISKN na tuto situaci připravovat a plánovat úpravy v rámci jeho normálního životního cyklu.

PS: Pro zajímavost - ČÚZK má v současné době ze všech státních orgánů nejvíce datových dat v Národním katalogu otevřených dat