Kormányzati Elektronikus Aláírás-ellenőrző Szolgáltatás (KEAESZ) tanúsítvány hiba

Közösségi kerekasztal

Hallottam egy olyan dologról, hogy "Kormányzati Elektronikus Aláírás-ellenőrző Szolgáltatás (KEAESZ)". Rákerestem, és ez a honlap jött ki:

https://www.keaesz.gov.hu/

Elvileg van egy olyan állami ingyenes szolgáltatás, amivel ingyen, böngészőből lehet ellenőrizni egy elektronikus aláírás hitelességét. De nekem a fenti link tanúsítvány hibát jelez:

Your connection is not private
Attackers might be trying to steal your information from www.keaesz.gov.hu (for example, passwords, messages, or credit cards). 
NET::ERR_CERT_AUTHORITY_INVALID

Linux alatt, Chromium böngészővel. De próbáltam Firefox-szal is, és azzal sem megy. Nálatok megy? Vagy nem is ez a szolgáltatás honlapja? Vagy ez már megszűnt azóta?

  • 1265 megtekintés

( tornai | 2021. 01. 20., sze – 16:28 )

Szerkesztve: 2021. 01. 20., sze – 16:28

It sem megy (Win, Chrome)

"Your connection is not private
Attackers might be trying to steal your information from keaesz.gov.hu (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED"

( Charybdis | 2021. 01. 20., sze – 16:54 )

Szerkesztve: 2021. 01. 20., sze – 17:01

Amúgy működik a dolog, mármint ha továbbkattintunk hogy az érvénytelen tanúsítvány ellenére is meg akarjuk látogatni az oldalt, akkor kijön egy működő űrlap, ahol fel lehet tölteni fájlokat. Kipróbáltam egy aláírt PDF-fel, feltöltöttem, és kiírta hogy érvényes aláírás, sőt egy teljes letölthető PDF-et is generál, ami bizonyítja a feltöltött fájl hitelességét: benne van az elektronikus aláírás adatai, az ellenőrzött fájl SHA256 lenyomata, valamint a hitelességet bizonyító PDF maga alá van írva a KEAESZ által elektronikusan, és még időbélyegezve is van.

Szóval hasznos szolgáltatás lenne ez, ha nem dobna már az elején tanúsítvány hibát. Nem tudok más ilyen szolgáltatásról, ami böngészőből megy minden platformon, ingyenes, és ilyen hitelességet igazoló, aláírt, időbélyegzett PDF-et generál.

Írtam nekik egy hibabejelentő emailt a megadott elérhetőségre, kaptam visszaigazolást, hogy megkapták a bejelentést. Majd megírom ide, hogy mire jutottak.

Megjött a hivatalos válasz:

Az Ön által tapasztalt problémával kapcsolatban a következőről tudjuk Önt tájékoztatni. A Chromium alapú böngészők megkövetelik a certificate transparency szolgáltatást, mellyel a https://www.keaesz.gov.hu/ nem rendelkezik, ezért „Az Ön kapcsolata nem privát”-szövegű hibaüzenetet olvashat, amikor megpróbálja az oldal megnyitását ezen böngészőkben.

Megoldásként jelenleg vagy nem Chromium alapú böngésző használata javasolható (mint például Mozilla Firefox), vagy a „Speciális beállítások” -> „Tovább a webhelyre” opciókra kattintás.

Nem Chromium alapú böngésző használata: az dicséretes, ezek szerint a látogatók cirka 70%-a nem tudja használni a szolgáltatást, mert lásd: https://gs.statcounter.com/browser-market-share/all/hungary (kb. 70% használ Chrome-et Magyarországon)

Mozilla Firefox használata: azzal sem megy.

„Speciális beállítások” -> „Tovább a webhelyre” opciókra kattintás: szóval vakon bízzak meg benne, hogy a tanúsítvány hiteles és a kapcsolat titkosított? Aha, persze.

"Mozilla Firefox használata: azzal sem megy." - Nekem működik - igaz,. a GOV CA-t hozzá kellett adni a böngésző cert. store-jához. Ez egyrészt érthető, hiszen nem igazán lenne jó, ha a közigazgatási oldalak certje egy magáncégtől függene, msárészt meg felveti azt a kérdést, hogy azzal alá lehet írni bármilyen website certjét, azaz állambácsi "simán" bele tudna nézni (és akár nyúlni is) bármelyik ssl-es site forgalmába.

"szóval vakon bízzak meg benne, hogy a tanúsítvány hitele" - nem kell vakon megbízni benne: https://hiteles.gov.hu/szabalyzatok

> azzal alá lehet írni bármilyen website certjét, azaz állambácsi "simán" bele tudna nézni (és akár nyúlni is) bármelyik ssl-es site forgalmába.

Kérlek itt segíts egy kicsit: ha én mint CA adok neked egy cert-et [remélhetőleg az általad generált csr alapján] akkor bele tudok nézni a te SSL-forgalmadba?

Ha van egy tetszőleges https://... site, a kliens meg megbízik az általam üzemeltetett CA certjében, akkor a forgalmat átfuttatva egy ssl-t átcsomagoló proxy-n, ami a kliens felé az általam üzemeltetett CA-val aláírt certet mutat be (aminek a kibocsátóját ugye megbízhatónak tekinti a kliens, ergo a lakat "zöld" lesz), az átcsomagolás során bizony bele lehet nézni/nyúlni a forgalomba.

( meskobalazs | 2021. 01. 20., sze – 17:04 )

Szerkesztve: 2021. 01. 20., sze – 17:11

Idézet a NISZ-től (https://hiteles.gov.hu/content/22/ca_certificates):

A NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. mint minősített hitelesítés szolgáltató szolgáltatói tanúsítványait 2014. szeptember 29. óta a MS Windows operációs rendszer tanúsítványtára tartalmazza. Ez alól kivételt képez a Minősített Közigazgatási Tanúsítványkiadó, melynek a gyökértanúsítványa a Közigazgatási Gyökér-hitelesítésszolgáltató (KGYHSZ). Ezért a felhasználók ezen tanúsítványok használata esetén "az aláírás nem megbízható" hibaüzenetet kaphatják. Ennek kiküszöbölése érdekében javasolt telepíteni az alábbi leírás szerint a KGYHSZ Root tanúsítványát. A NISZ Zrt. az ellátotti köre számára telepítette a tanúsítványokat.

Ennek van bármi értelme? (ez nem költői kérdés)

Igen és igen.

A magyar internetre magyar rootcertet dolog egy teljesen valid indok. Az osekklel / böngészőkkel szállított root ca-k használata ugyanis -- az elméleti síkon -- nem javít, hanem kifejezetten ront egy cert biztonságosságának megítélésén az ideálishoz képest. Ők megbízható harmadik felek a kommunikációban, és mint olyanok, szükséges rosszak. Ők azok, akikről a kommunikáló felek (már amelyiket érdekli a másik hitelesítése, ez klasszikusan csak a kliens) elhiszik, hogy amit ő állít, az igaz. Praktikusan azért van erre szükség, mert a random.com-mal nem tudod egyébként kényelmesen kideríteni, hogy ő van-e a cert mögött. De ha egyébként meg tudsz győződni arról direktben, hogy az a cert valóban a másik félnél van, akkor a biztonság jobb, nem kell hozzá 3rd party. Főleg, hogy az ő állításait ráadásul technikailag semmi nem kényszeríti ki, egyszerűen elhisszük, hogy amit állít az igaz, mert pl bemutatta a megfelelő működési szabályzatát, meg átment az auditon MSnél/mozzilánál/guglinál.

Na most a magyar állam és állampolgára közti hitelességi kérdésekben praktikusan is komoly biztonsági gap lenne, ha bevonnánk egy külső felet, aki pl amcsi (vagy orosz, vagy kínai, vagy bantu) fennhatóság alatt van, mint alapvető döntnökét a megbízhatóságnak. Teljesen jogos, hogy ezt a magyar állam saját hatáskörben csinálja. Mármint képzeld el, hogy Trumpli uraság úgy dönt, hogy mostantól a magyar államigazgatás dokumentumai nem hitelesek :)

Technikailag már kissé szarabb a helyzet, amit ugyanis a nisz javasol, az a gyakorlatban neked csücskös. Ugyanis -- csak úgy, mint a többi CA -- a nisz is pont azt ír alá azzal a root CAval, amit csak akar. Szóval ha beimportálod, akkor állam bácsi pont arról a kapcsolatodról hiteti el veled, hogy jó, amelyikről csak akarja. Mivel a technológia (a tls se jó, a browserek sem csinálnak dolgokat, amiket csinálhatnának [insert nem annyira konteo köcsög google gondolatok here]) sajnos nem teszi lehetővé, hogy te értelmesen megmondhasd, hogy pl ez a root CA milyen kapcsolatok tekintetében hiteles (tehát pl nem lehet olyat mondani, hogy állambácsi véleménye csak a *.gov.hu tekintetében érdekel, viszont a többieké meg erre nem érdekel). A szerver oldalnak van valamennyi esélye védekezni az ellen, hogy ne állítson ki olyan rá certet, akinek ő erre nem kért, pl a certificate transparencyvel és az Expect-CT headerrel (meg a deprecated public key pinninggel), de messze nem silver bullet, ráadásul csak HTTPSre jó in practice jelenleg. Uh én ezt nem javasolnám, marad az értem gomb nyomkodása. (Nagyon hasonlóan pl a céges belső root CAkhoz)

Persze ebben is van sajnos kockázat, mert a browserek abban sem jeleskednek, hogy legalább te mint kliens azt tudd mondani, hogy na, ebben a konkrét certben megbízom. Hol megjegyzik, hol nem, periodikusan baszogatnak újra stb, te meg jó eséllyel úgy se fogod minden alkalommal megolvasni a fingerprintet, szóval könnyen át tudsz baszódni.

Igazából az egész TLS/PKI modell elég szar (a revocationokbe még bele se mentünk :D)

Így van. És ők láthatólag elgondolkodtak azon, hogy az egyik esetében megfelelő kompromisszum egy ilyennel aláírni, a másik esetben meg nem. Ott van az idézetben, hogy be tudnak tenni tanúsítványt az MShez, szerinted lar-pur-lart nem tették be ezt is, vagy irnak alá azzal, vagy esetleg végiggondolták, hogy mik az igények "Minősített Közigazgatási Tanúsítványkiadó" esetében, és tudatosan nem tették?

Nem értem mire gomndolsz. Van a portál, egy böngészős hozzáférés a szolgáltatáshoz. Ha magának a portálnak a tanusítványa minősített, azért mert úgy gondolta a tervező hogy ezzel a lekérdezésekben a http válaszban kiadott adatok minősített aláírásúak, akkor szerintem ez így nem jó. A https-re szerintem olyan cert kell, aminek a lánc végén egy böngésző szerint trusted root van. Ha pedig olyan adatot tölt le a kliens, aminek minősített aláírása szükséges mert a törvény ezt írja elő, akkor az meg legyen pl. minősített aláírással ellátott pdf, a megfelelő rootból induló lánccal. De ez két dolog, az egyik dolog a böngésző és a szerver közt a http transzport hitelessége, a másik meg a transzportált adat, a payload hitelessége, nem? Nem ismerem mélyen sem a kriptográfiát sem a vonatkozó magyar törvényeket, nem tudom hogy azzal hogy a portál certje minősített, akkor egyben az ott kiadott adatok minősített aláírása is oké-e. Nekem ez nem magától értetődik, de lehet hogy így van. Annyit tudodk, hogy ebben a témában semmi nem magától értetődő, vannak könyvelők az ügyfélkörben, abban már képbe kerültem, hogy egy e-személyis vagy AVDH-s aláírás elektronikus cégképviseletre miért nem jó hiába gondolják sokan hogy jó. 

Nekem mindegyik gov.hu-s szolgáltatás működik https-en alapból, csak ez a KEAESZ nem, és nem értem, hogy ennek mi az értelme. Egyáltalán hogyan lehet ezt működésre bírni? Valakinél megy egyáltalán a fenti link?

Még az AVDH is megy nálam alapból, nem kell hozzá tanúsítványt vadászni. Szerintem itt valamit elrontottak a KEAESZ-nél.

Elolvastam, de még mindig nem értem, pl. mi a különbség a KEAESZ és az AVDH között? Az AVDH megy gond nélkül, a KEAESZ nem megy. Mindkettő NISZ üzemeltetés és gov.hu-s.

A KEAESZ ezt írja alul (rányomtam, hogy fogadja el a tanúsítványt megbízhatónak):

A szolgáltatást az egyes, az elektronikus ügyintézéshez kapcsolódó szervezetek kijelöléséről szóló 84/2012. (IV. 21.) Korm. rendelet 4. k) pontja alapján a NISZ Nemzeti Infokommunikációs Szolgáltató Zártkörűen Működő Részvénytársaság – mint szolgáltató – működteti.

Az AVDH meg ezt írja:

Üzemelteti a Nemzeti Infokommunikációs Szolgáltató Zrt.

Egyik miért szar, másik miért jó?

Kissé megkövetem magam, mert nem pont erről a tanúsítványról van szó az idézetben, ezzel együtt, az egyik azért "szar" a másik meg azért nem, mert nem attól függ, hogy jó-e, hogy ki üzemelteti, hanem attól, hogy milyen tanúsítványt mutat fel. A "szar" a nisz egy saját root tanúsítványát mutatja fel, a jó meg egy eszignosat. Az előbbi nincs benne a géped trust storejában, az utóbbi meg igen.

Nem trust issueról van szó szeritnem (azaz nem azon a szinten, hogy a böngésző nem bízik a CA-ban :))

A hiba legalábbis Chrome alatt: 

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Itt valamiért nincs a most használt tanúsítvány:

https://transparencyreport.google.com/https/certificates?hl=en&cert_sea…

Amúgy a KEAESZ tanúsítványának a Kormányzati Hitelesítés Szolgáltató a rootja ami benne van a Megbízható legfelső szintű tanúsítványok közt.

Szerintem valami el van sz*rva. De nem vagyok CA. :)

U.i.: Használjatok IE-t az hiba nélkül berántja. ;)

Tényleg, akkor passzolom. Bár nem tudom loggolni mikor kell (azaz ahogy olvastam kiadáskor), lehet a két hét sok volt a googlinak. :) 

CT Information (info source: crt.sh)

Log entries for this certificate:
Timestamp Entry # Log Operator Log URL
2020-12-03  09:56:46 UTC 287833143 Google https://ct.googleapis.com/logs/argon2021

https://decoder.link/certificate_transparency

Alapvetően kiadáskor kellene, de hogy van-e erre technikai megkötés, azt nem tudom, ennyire még sose másztam bele. Az egész expect-ct meg az a signed timestamp izé azt célozza, hogy azt akarom, hogy legyen benne. Majd lehet feladom a tlshez tényleg értő kollégáknak játszani idebent :D

https://www.ssllabs.com/ssltest/analyze.html?d=www.keaesz.gov.hu&hideRe…

Itt is azt írja, hogy nem megbízható a tanúsítvány. Egész pontosan a Mozilla, Apple, Android, Java trust store szerint nem megbízható, a Windows trust store szerint viszont megbízható.

De egyáltalán Windows alatt megy ez bárkinek? Ha meg csak Windows alatt menne, akkor is szar, mert ezek szerint nem platformfüggetlen a szolgáltatás. Nem elvárható, hogy vásároljak egy jogtiszta Windowst csak azért, hogy problémamentesen tudjam használni ezt a szolgáltatást.

Maradjunk annyiban, hogy problémamentesen kellene működnie mindenféle böngésző figyelmeztetés nélkül Linux, Mac, Windows, Android, Chrome, Chromium, Edge, Safari, Firefox stb. alatt is. És anélkül, hogy nekem kelljen vadászni meg telepítgetni tanúsítványt.

Vagy szerinted teljesen életszerű, hogy átlag user meglátogatja az oldalt, látja a böngésző hibát, és azonnal fejből tudja mit kell csinálni, átmegy egy másik weboldalra, ahol azonnal megtalálja és letölti a megfelelő tanúsítványt, azt rutinból telepíti is a böngészőbe, aztán gond nélkül megy már neki a szolgáltatás, és még örül is neki, hogy milyen jó, hogy ezt valaki így oldotta meg, ez aztán a szuper munka!

Hát igen, igazából sok általános cikk van a neten arról, hogy digitalizáció így, digitalizáció úgy, versenyképesség-növelés, elektronikus aláírás mert az olcsóbb meg jobb mint a papír, stb. buzzwordök, de ezeket szerintem olyanok írják, akik még életükben nem próbálták ki az elektronikus aláírást a gyakorlatban.

Merthogy az a valóság, hogy az elektronikus aláírás drága (nagyon sok esetben a papír sokkal olcsóbb), a gyakorlatban szinte sehol nem fogadják el (még akkor sem, ha jogszabály szerint el kéne), nem tudják, hogy mi az, nem tudják ellenőrizni, nem tudják befogadni sem mert nincs meg fogadói oldalon hozzá az infrastruktúra meg a hozzáértés sem. Nincsen archiválási szolgáltató, aki normális áron archiválna, tehát archiválást oldd meg saját magad.

Lehetne az europa.eu-n bevezetni szerintem egy normálisan működő elektronikus aláírási, időbélyegzési és archiválási szolgáltatást. Minden EU-s magánszemély és cég kapna ingyen minősített elektronikus aláírást, amivel a felhőben, böngészőből lehetne aláírni fájlokat az europa.eu-n (mint az AVDH, csak cégszerű aláírás is lenne, és saját névre szólna az aláírás). Esetleg lehetne kérni kártyán is a tanúsítványt, ha valaki nem bízik a felhőben.

Úgy működhetne, hogy először személyesen kell azonosítania magát a magánszemélynek vagy cégnek az adott tagállam megfelelő kirendeltségén. Személyes azonosítás után kapna hozzáférést a rendszerhez, megkapná a saját minősített tanúsítványát. Ezzel létre tudna hozni minősített elektronikus aláírást és minősített időbélyeget, továbbá a rendszer azonnal archiválná is az így aláírt fájlokat, és a felhőben tárolná archív időbélyeggel, szükség esetén automatikusan felülhitelesítve az aláírást, hogy végig hiteles maradjon.

Lenne egy küldés funkció is, amivel az egész EU-ban bárkinek el lehetne küldeni a felületen keresztül az aláírt fájlokat, a fogadásról pedig készülne egy e-tértivevény, ami automatikusan időbélyegezve és elektronikusan aláírva lenne, így letagadhatatlan, hogy valaki megkapott egy fájlt. A fogadói oldalon is lenne automikusan archiválás, tehát  a fogadónak sem kéne aggódnia azon, hogy a befogadott elektronikus aláírt fájl hiteles-e lesz még 8-10 év múlva is, mert a rendszer a beépített automatikus archiválási szolgáltatással garantálná a hosszú távú hitelességet.

Az egészbe be lehetne vonni az összes EU-s állami szervet és önkormányzatokat is, tehát ezen a felületen keresztül tudna egymással kommunikálni minden EU-s magánszemély, cég, szervezet, állami szerv és önkormányzat.

Ez váltaná ki a papírt és ez növelné a versenyképességet.

A jogszabályi környezet már megvan hozzá (eIDAS rendelet, egész EU-ra érvényes).

Szép álom. 

Anno én olyat álmodtam, hogy az ENSZ készíthetne egy root cert-et azzal aláírja az összes országét az ország pedig a szervezeteinek és a polgárainak ad tanúsítványt ezzel aláírva. Persze így kimaradna a CA business.

A felhős EU szintű archiválással az a baj, hogy ezek a dokumentumok nem feltétlenül (sőt szinte soha) vannak titkosítva. Ha az archiválást odaadod egy kötelezően használandó központnak ott meglesz az összes magán és közokirat - ez túl nagy hatalom. Én eléggé bízon az EU-ban, de azért ennyire még én sem.

Kicsit más téma: Szerintem a személyi igazolványos digitális aláírás soha nem lesz használva ha így marad. A következők miatt:
- Nem adnak hozzá olvasót és amit ajánlanak az drága. Volt egy Szlovákiai magyar tanítványom, ő mutatta, hogy az ő személyi igazolványán nem csak tanúsítvány van, hanem adtak hozzá egy USB olvasót is.
- Az igazolványon levő tanúsítvány lejárata rövidebb, mint az igazolványé és digitálisan nem lehet hosszabbítani, be kell menni személyesen egy ügyintéző helyre. Kevesen fognak sorba állni egy egyébként sem használt szolgáltatás miatt.
- Az aláíró program finoman szólva nem az igazi. A Windowsos sem Linuxra meg csak ígérik Mac-ről mobil alkalmazásról nem tudok.

A túl nagy hatalommal kapcsolatban igazad van. Esetleg akkor kliens oldali titkosítást is be lehetne építeni a rendszerbe. Azzal meg az a baj, hogyha a jelszó a privát kulcs, és valaki elfelejti a jelszavát, akkor elvesznek a dokumentumai is, mert nem fogja tudni őket dekódolni.

Az Elon Musk-féle chipbeültetés megoldás lenne, akkor tutira nem felejtenék el a jelszót az emberek :)

Az archiválást lehetne opciós szolgáltatássá tenni, aki nem kéri, annak nem tárolnák a dokumentumait a felhőben.

Az eSzemélyi aláírás tényleg szar. Miért nem lehet a hosszabbítási szerződést elektronikusan aláírni a még érvényes tanúsítvánnyal? Ez volna a logikus.

Én a felhőbe tenném át az egészet, a Netlocknál már van ilyen. Csak böngésző kell hozzá, semmi más (persze előtte személyes azonosítás kell egyszer, de utána minden megy a felhőben).

"- Nem adnak hozzá olvasót és amit ajánlanak az drága." - Egyszer kell megvenni, ez igaz, de azt követően kifejezetten hasznos - pláne a mostani otthonmaradós időszakban.

"- Az igazolványon levő tanúsítvány lejárata rövidebb, mint az igazolványé és digitálisan nem lehet hosszabbítani, be kell menni személyesen egy ügyintéző helyre. Kevesen fognak sorba állni egy egyébként sem használt szolgáltatás miatt." - A lejárati idő nem gond, igaz, oda kell figyelni rá. A személyes megjelenés nem sorbanállós (lehet időpontot foglalni online), nekem 10 perc volt a megújítás, ebben benne volt a papírozás (szolgáltatási szerződés elfogadása, cert átvételének az igazolása, e-szig olvasóval történő maszírozása).

Oneplus 5-el és 7T-vel nekem ment. (igaz az utóbbival csak az azonosítást próbáltam mert lejárt a személyimen az aláírás :))

Annyit kellett nálam állítani, hogy a Delay for Card Presence Check és a Delay for Card Response értékeket maxra kellett állítanom.

Működni működik igaz, nálam nem a legstabilabb dolog a világon (e-azonosításnál van, hogy csak harmadjára sikerül :)) és a Windows-os drivere nincs aláírva így csak "teszt módba" lehet telepíteni.

köszi a részletes okfejtést, nagyjából ezt sejtettem én is. Akkor valójában már csak az a kérdés, hogy miért nem azt használják itt is ami már benne van a trusted store-ban a böngészőkben.

Azért zavar ez engem igazából, mert vért izzadunk azzal, hogy a usereknek megtanítsuk, hogy nézd meg a kis zöld lakatot (igen, ilyen szinten vagyunk sokszor) és akkor mikor ezt a szolgáltatást használná akkor még tanítsak meg neki egy kivételt is, hogy igen én egész eddig a szádba rágtam, hogy csak a zöld lakat a jó, de itt most ez egy kivétel, kattints rá nyugodtan.

( Charybdis | 2021. 01. 21., cs – 11:03 )

Találtam egy másik szolgáltatást, ami tud ingyen elektronikus aláírást ellenőrizni böngészőből, elég részletesen riportot ad: https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation

Hátránya, hogy nem ad ki olyan szép igazolást magyarul, mint a KEAESZ. Pedig az a KEAESZ igazolás hasznos tud lenni, ha valakinek meg kell mutatni, hogy márpedig érvényes az elektronikus aláírás.

( NevemTeve | 2021. 01. 21., cs – 13:48 )

Szerkesztve: 2021. 02. 04., cs – 06:56

No, ilyesmi a RootCA cert eleje (szép ékezetes):
 

s: C=HU, L=Budapest, O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt., CN=Főtanúsítványkiadó - Kormányzati Hitelesítés Szolgáltató
i: C=HU, L=Budapest, O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt., CN=Főtanúsítványkiadó - Kormányzati Hitelesítés Szolgáltató
nb: Sep 13 10:27:04 2013 GMT
na: Sep 13 10:27:04 2033 GMT

Beállítottam a Firefoxnak, mint megbízható legfelsőbb szintűt, azóta nem panaszol.

Szerk(2021.02.04.)
Firefox-on működik (saját tanusítványtára van, abba beletettem), IE-ben és Edge-ben működik (Windows közös tanusítványtárát használják, abba is beletettem), Chrome nyünyög, hogy NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Saját házi RootCA-mat is próbáltam, arra nem nyünyög a Chrome, müxik. Mi lehet a különbség? És mi lenne ez a 'certficate transparency' egyszerűbb szavakkal? Valahányszor generálok egy cert-et, be kell jelenteni a google-nak? Vagy mi?

Ez elég jól összefoglalja, hogy miért tag-eli a Chrome nem megbízhatónak: https://certificate.transparency.dev

Röviden: elérhetővé kell tenned az általad kiállított certificate-ekhez egy publikus log adatbázis service-t, aminek az elérhetőségét a böngészőnek ismernie kell.

Édekes, hogy a listában szereplő és a böngészők által ismert log service-ek jelentős részére már 404-et kapok, több közülük Google:

https://www.gstatic.com/ct/log_list/v2/log_list.json

Alma - körte.

A CRL és az OCSP a visszavont certekről szól, a transparency meg azokról, amit az ember alapvetően sosem akart validnak tekinteni.

Nekem is elég ambivalens érzéseim vannak egyébként vele kapcsolatban. Egyrészt nem tudom, mennyire jó ötlet ez a kiteregetés, másrészt nem látom, mennyi vannak kétségeim a hasznossága kapcsán (esetenként inkább káros), harmadrészt meg hoz új veszélyeket. Pl ha én malicsusz kisfiú lennék, és botnetet akarnék gyártani, biztos, hogy a transparency log tetején így kiderülő új szolgáltatásokat próbálgatnám gyorsan, mielőtt még rendesen bekonfigolják őket.

Persze. A CT a fent már többször is emlegetett bármelyik CA bármit ki tud állítani problémára próbál valamilyen technikai megoldást hozni. Mert ugye technikailag egy CA olyan certet állít ki, amilyet csak akar, nincs szüksége semmi technikai proofra, hogy azt tőle akárki kérte. Szóval a példánál maradva, a nisz a "mindenkinnél" a trust storeban levő certtel nyugodtan aláírhatja a te kis endomainem.hu oldalaadhoz a certet. Ez után már "csak" bele kell állni a domained fele menő forgalomba, és azt csinál, amit akar. Bár NevemTeve odafent ezt ironikusan apróságnak nevezte, FYI ma az összes magyar szolgáltatónak szűrnie kell az állam szerint blokkolandó oldalakat a KHETA alapján, aminek az ajánlott kiépítése az, hogy routeold be a forgalmat állam bácsihoz, és majd ő DPIzik. (vajon ki üzemelteti :) )

Nyilván egy sima CAnak ennél kisebb játszótere van, de kontroll továbbra sincs felette. Ha van egy nagy, nyilvános adatbázis, ahol látszik az összes kiállított cert, akkor arra lehet reagálni. Te is tudod figyelni a saját érdekeltségeidet, illetve generikusan is lehet nézni azt, hogy nincsenek-e anomáliák pl valamelyik CAban. (Pl olyan certeket állít ki, amire valaki másnak még van bőven érvényes certje). A chrome pedig azért sipákol, ha nincs benne valami cert, hogy legyen kényszerítő erdő, hogy a CAk részt vegyenek ebben. Különben ugye lehet vállvonogatni, a user tudni se fog róla, az ügyfélnek a saját valódi CAjának basztatására nincs igazából szüksége, és ha még elvből basztatná is, hogy miért nincs, a CA még mindig mondhatja, hogy dehát ha más se csinálja, akkor neked no gain, és extra risk a publikussá tett infó.

Szóval az, hogy egy cert benne van a logban, az igazából közvetlenül nem állít semmit annak "jóságáról". Ha állambácsi beleírja a megkérdezésed nélkül kiállított certet a logba, akkor a chrome nem fog sipákolni. (Közvetve természetesen igen, azt, hogy a szolgáltató dolgai ott vannak, van esély belelátni a kiállító működésébe)

Mint látszik, ez alapvetően egy reaktív folyamat, és nyilván van hozzáadott értéke, cserébe lesz egy szép nagy, periodikusan frissülő adatbázis az interneten elérhető oldalakról, in detail a tieidről is, még ha nem is akarod (és azért lássuk be, a googlenek -- meg a többinek -- ez elég hasznos), tovább nehezedik saját trust domain kialakítani lokálisan anélkül, hogy belekevernéd ezt az egészet, akkor is, ha erre egyébként baromira nincs rá szükség, és ilyen félmegoldásokkal próbálja épp a saját működését kicsit jobbá tenni :) meg ilyesmi.

> A log-ot ugyanaz a szolgáltató tartja karban, aki a certificate-et kiállította, én ettől nem érzem megbízhatóbbnak a validálási folyamatot.

Nem. Az adatbázis egy nagy közös blockchain. Szóval append only, és (elméletileg) nem dedikáltan üzemel.

> SSL inspection esetén az összes lecserélt certificate-t is tárolnia kell egy publikus adatbázisban? 

Ez nyilván a guglitól/mozzilától/egyéb böngészőtől függ, de jelenleg ha a CA publicly trusted (vagyis a vendor magától szállítja, hogy te ebben bízol), akkor kell(ene) neki, ha locally-trusted (vagy te, vagy a rendszergazdád tette be kicsi kezével), akkor nem. Szóval most még az van, hogy a szokásos enterprise bontás menni fog publikálás nélkül, mert ahhoz van egy céges trusted CA, állambácsinak viszont be kellene küldeni.

(Persze a teljességhez hozzátartozik, hogy ameddig nem terjed el rendesen az encrypted SNI, addig bontás nélkül szűrni tud domain alapon)

( eff | 2021. 02. 04., cs – 08:25 )

Szerkesztve: 2021. 02. 04., cs – 08:25

Ezeket a tanusitvanyokat NISZ Root certtel irtak ala, amit innen lehet letolteni, ez a magyar allami tanusitvany szolgaltato:
https://hiteles.gov.hu/cikk/22/szolgaltatoi_tanusitvanyok

A dolog pikanteriaja, hogy a magyar allami tanusitvany szolgaltato weboldala NetLock altal kiadott tanusitvanyt hasznal, mert ugye kulonben ugyanarra a sorsra jut, mint a fenti oldal.

Eleinte sajat tanusitvanyt hasznalt, akkor a bongeszom kozolte, hogy a https://hiteles.gov.hu nem hiteles :)

 

Szoval van egy allami tanusitvanykiadonk, amit kb semmilyen bongeszo nem fogad el, ezert a sajat weboldalat kulso "mockosz kapitalista" ceg altal kiadott tanusitvannyal szolgalja ki.

A NetLock is úgy indult, hogy nem volt benne a böngészőkben (sem), meg mondjuk az akkor még talán nem is T, hanem W900 wap gateway is prüszkölt amiatt, hogy a wap-szolgáltatásunk alá anno NetLock-os certet raktunk - de csak kikalapálták működőre a túloldalon...

Egyébként meg - ha belegondolsz - korrekt, hogy egy megbízható(nak tekintett) 3. fél CA-ja hitelesíti a letöltési site-ot, nem pedig saját maguk mondják magukról azt, hogy "bízz bennünk, itt a ca certje, töltsd le - megbízható, hiszen ezt az oldalt is ezzel írtuk alá" :-)

És akkor honnan tudod, hogy a hiteles.gov.hu-n tényleg azok a tanúsítványok vannak fent, amik szükségesek a KEAESZ szolgáltatáshoz? Ezek szerint ehhez meg kell bízni a Netlock-ban. De akkor már nem lett volna egyszerűbb ha a Netlock hitelesíti a KEAESZ oldalát?

A másik , amit még mindig nem értek, hogy az AVDH, amivel aláírni lehet, az meg ugye gond nélkül megy mindenféle cert telepítés nélkül. Ez a KEAESZ meg csak ellenőriz, aláírni nem lehet vele. Akkor minek bonyolítják a dolgot, miért nem mehet ugyanúgy a KEAESZ, mint az AVDH?

A végén csak az jön ki, hogy van a KEAESZ, amit az átlagpolgár nem tud használni, akkor minek fejlesztették le?

Továbbá megjegyezném, hogy a témában kikértem a hivatalos ügyfélszolgálat véleményét, és egy szóval sem említették, hogy töltsek le bizonyos tanúsítványt a hiteles.gov.hu-ról, és azt telepítsem. Tehát még az ügyfélszolgálat felkeresése után sem világosodik meg az ember, hogy hogyan is kell használni ezt a csoda KEAESZ-t.

Egyébként meg nem a Microsec az udvari szállító? A múltkor például kitalálták, hogy 'adj uram isten, de rögtön át kell állni RSA-ról ECC-re, mert az ETSI ez írta elő', amikor pedig rákérdezett valaki, hogy az ETSI tulajdonképpen nem írta elő ezt, akkor az volt a válasz, hogy 'de a Microsec is áttér ECC-re'.

Szerk: most hogy ezt leírtam, gyorsan szétnéztem, és láttam, hogy újra nekifutnak: https://hiteles.gov.hu/cikk/96/ECC%20alap%C3%BA%20teszt%20tan%C3%BAs%C3…

(Ez volt a korábbi 2018 novemberben: https://hiteles.gov.hu/cikk/73/V%C3%A1ltoz%C3%A1sok%20a%20szolg%C3%A1lt… )

Az okmányok/okiratok hitelesítését viszont nem.

Erről valami információ?

"Fennkölt elvek miatt? " - például azért, hogy ne fordulhasson elő az, hogy a magáncég besomja CRL-re az állami okmányaláíró weboldal certjét...

Előfordult már ilyen? Mi a feltétele annak, hogy valakit CRL-re tegyenek? Ha valakit CRL-re tesznek indokolatlanul, annak mi a következménye a cég felé, aki CRL-re tett valakit tévesen?