Kormányzati oldal rossz biztonsági tanúsítvánnyal

Security-all

Ügyfélkapura próbáltam belépni:
https://gate.gov.hu/

Invalid Server Certificate
You attempted to reach gate.gov.hu, but the server presented an invalid certificate.

hmmm... jól van ez így?

  • 7138 megtekintés

( vl v | 2011. 06. 05., v – 22:00 )

Nekem valid certificate-et prezentál. Nem lehet, hogy a te készülékedben van a hiba?

Nem is az. Azt, hogy melyik CA-ban bízol neked kell eldöntened, nem a böngésződnek. Tudom, hogy az átlagember nem lát annál messzebb, hogy a böngésző b.szogatja-e a nem megbízható tanúsítványkiadó c. üzenettel vagy sem, de ez egyáltalán nem műszaki kérdés, ez bizalmi kérdés.

( julesruzi | 2011. 06. 05., v – 22:09 )

nálam is jónak tűnik,
Subject:
CN = gate.gov.hu
O = KOPINT-DATORG zRt.

Issuer:
CN = Advanced e-Szigno CA3
OU = e-Szigno CA
O = Microsec Ltd.

Validity : 2012.03.17. 10:30:08

Meg az Opera, meg az FF!
Tudtommal az e-Szigno semelyik böngészőgyártóval sem áll szerződésben, hogy ugyan fogadják már el az ő ROOT-CA -ját is.

Megaztán van egy ilyen gond is: 


kayapo@ponyfarm:~$ openssl s_client -connect gate.gov.hu:443
CONNECTED(00000003)
depth=2 /C=HU/L=Budapest/O=Microsec Ltd./OU=e-Szigno CA/CN=Microsec e-Szigno Root CA
verify error:num=19:self signed certificate in certificate chain

----
올드보이
http://molnaristvan.eu/

> Megaztán van egy ilyen gond is:
> self signed certificate in certificate chain

A ROOT-CA cert-et maga a CA írja alá: 


echo | openssl s_client -showcerts -connect gate.gov.hu:443 | while openssl x509 -text -noout ; do true; done > chain.lst


Certificate:
...
        Issuer: C=HU, L=Budapest, O=Microsec Ltd., OU=e-Szigno CA, CN=Microsec e-Szigno Root CA
...
        Subject: C=HU, L=Budapest, O=Microsec Ltd., OU=e-Szigno CA, CN=Microsec e-Szigno Root CA
...
        X509v3 extensions:
            Authority Information Access:.
                OCSP - URI:https://rca.e-szigno.hu/ocsp
                CA Issuers - URI:http://www.e-szigno.hu/RootCA.crt

            X509v3 Basic Constraints: critical
                CA:TRUE
...

> az eszigno jol hangzik, de ugye magyarorszagon kivul nem ismerik, de cserebe nem rakjak be sehova...

itt megtaláltam:

http://social.technet.microsoft.com/wiki/contents/articles/windows-root…

> hogy miert nem hasznalnak hasznalhatot, pedig mar leirtak elottem, me' a nem magyar...

netlock.hu, tudtommal évek óta "használható", és magyar.
http://www.mozilla.org/projects/security/certs/included/#NetLock

( _Franko_ v | 2011. 06. 05., v – 22:44 )

Milyen böngészővel nézed?

Mert vagy a Microsec vagy eGroup a kormányzati beszállító, éppen kinek melyik cég a "szimpatikusabb", és például a Microsec rootca a Firefox 3.5 után került a böngészőbe, egészen addig kiabált a böngésző, hogy nem megfelelő a tanúsítvány. A Sun/Oracle féle JRE-ben máig nincs benne egyik magyar rootca sem, így igazán örvendetes dolog akár WebService-el, akár Android-ról olyan oldalt elérni, ahol a cert amúgy rendben van, csak magyar.

Annó rákérdeztem, hogy miért nem egy nagyobb nemzetközi cég adja a tanúsítványt, és annyi volt a válasz, hogy magyar legyen. Szóval jó szokás szerint magyar seggbe magyar ló..szt... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

> hogy az osszes browser mint ervenyes tanusitvanyt mutassa

Úgy érted, hogy az összes browser-nek, az összes főtanúsítványt tartalmaznia kéne? Vagy nem az összesnek, és nem az összeset; csak a microsec legyen ott mindegyikben?

Lehetne egy főfő tanúsító, aki összegyűjtené és aláírná a főtanúsítványokat. De 1 az nem jó, legyen inkább több. Hopp, de hát ez már most is így van :-)))

Lehetne egy főfő tanúsító, aki összegyűjtené és aláírná a főtanúsítványokat. De 1 az nem jó, legyen inkább több. Hopp, de hát ez már most is így van :-)))

Azt nem értem, hogy miért erőltetik ennyira, hogy rootca legyen a magyarországi három nagy cég tanúsítványa, amikor megtehetnék, hogy egy nagyobb világcég alá betagozódnak, amely már ott van az összes szükséges kliens gyűjteményében.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mondom én: magyar seggbe magyar ló..aszt minősített este. :)

Miért kellene magyar hatóságnak egy külföldi rootca-t felügyelnie? A láncban benne lenne mindhárom cég, csak nem legfelül, hanem egyel lentebb, oszt azt felügyelhetné bármelyik állami szerv, ahogy jólesik... várj, tényleg nem jó, ez így még működne is. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Lásd a fönti linket, amit bepostoltam neked. Security okokból. Ha van egy, a magyar CA-k fölötti CA, akkor lehet hitelesítést hamisítani és végigvinni a láncon. Add össze ezt, meg egy DNS hijacket és úgy lépsz be az Ügyfélkapun, hogy a CIA/Moszad/KGB/Al Kaida site-ja van a háttérben. :)

--
Web 2.0: you make the content, they make the money.

Ahja, de ez csak egy elméleti potenciális veszély - ha korrumpálható egy hitelességéből élő cég, akkor egyetlen eset kiderülésekor lehúzhatja a rolót. A jelen probléma pedig egy igen zavaró dolog, gyakorlatilag egy kormányzati SSL feletti szolgáltatás igénybevételéhez egy felhasználói jogokkal telepíthető kliens csomaghoz kell adni egy tanúsítványt, amelyet pillanatok alatt ki lehet cserélni, és sokkal reálisabb a veszélye a MITM támadásoknak.

Gyakorlatilag az ÁNYK-ba is bele van csomagolva a kormányzati oldal CA-ja, hogy kapcsolódni tudjon SSL felett a bevallások feltöltéséhez, mert egyik magyar cég tanúsítványa sincs benne az elterjedt JRE verziókban... szerinted mennyi energiát kell abba fektetni, hogy ezt a CA-t és a feltöltéshez használt URL-t kicseréljék sajátra és egy "mérgezett" ÁNYK-t szórjanak szét a könyvelők között? Az egyetlen ok - amiért ez nincs támadva, az mindössze annyi, hogy nem lehet pénzzé tenni az ügyfélkapus név/jelszó párosítást, se a feltöltött bevallásokat.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nem láttam még ÁNYK-t, de ugye szoftvercsomagot is el lehet látni aláírással, ami a megváltozatlanságot garantálja.
Persze korlátlan lehetőségekkel mindent meg lehet csinálni, mindent lehet hamisítani - DNS-t, CA-t, certificate-okat, bevallást fogadó webservice-t.
Egyébként meg tökmindegy, hogy az ÁNYK-ban cseréled ki a certet vagy a jre-ben, szóval nem értem, hogy jön ide az a probléma, hogy a jre cert store-jában nincs benne pl. a microsec root CA tanúsítványa.

"Nem láttam még ÁNYK-t, de ugye szoftvercsomagot is el lehet látni aláírással, ami a megváltozatlanságot garantálja."

Az aláírt szoftvercsomag aláírásának hitelességét mivel ellenőrzöd?

"Egyébként meg tökmindegy, hogy az ÁNYK-ban cseréled ki a certet vagy a jre-ben, szóval nem értem, hogy jön ide az a probléma, hogy a jre cert store-jában nincs benne pl. a microsec root CA tanúsítványa."

Sokkal nehezebb a JRE vagy az oprendszer terjesztési folyamatába egy mérgezett cacerts fájlt elhelyezni, mint egy felhasználó által telepíthető programban ugyanezt elintézni.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Az aláírt szoftvercsomag aláírásának hitelességét mivel ellenőrzöd?"
??? úgy, ahogy bármilyen digitális aláírást. Amíg az aláíró rendesen kezeli a titkos kulcsát minden OK.
"Sokkal nehezebb a JRE vagy az oprendszer terjesztési folyamatába egy mérgezett cacerts fájlt elhelyezni"
Most nem nézek utána, de pl. javanál van per user keystore, amit az user írhat.

"Miért kellene magyar hatóságnak egy külföldi rootca-t felügyelnie? A láncban benne lenne mindhárom cég, csak nem legfelül, hanem egyel lentebb, oszt azt felügyelhetné bármelyik állami szerv, ahogy jólesik... várj, tényleg nem jó, ez így még működne is. :)"

A jobgiztonság fontosabb, mint az hogy a böngésző mit ugat. Amúgy az IE ismeri a e-szigno CA-t, használd azt ha zavar a FF szerencsétlenkedés.

---
Song of the 2nd Moon http://youtu.be/MSoAzONw-a4

nem azért, hanem mert így a magyarországi lawful interceptre jogosult szervezetek könnyebben kaphatnak egy CA:TRUE attríbútumos certet, amivel szemrebbenés nélkül lehet a (basic) felhasználó által nem érzékelhetően SSL keybridgelni és MITM módon megfigyelni az SSL-ben menő trafficot. Ezt egyes cégek is előszeretettel alkalmazzák, ahol a céges gépekre terítik a céges trusted CA-t.

(Ez a hozzászólás a puszta fantázia szüleménye.)

Pl. a Microsoft tűzfala (TMG 2010) pontosan így valósítja meg a https forgalom vizsgálatát. Nem is ez a nagy szó, hanem az, hogy ebben az esetben egy viszonylag olcsó, átlagrendszergazda által kezelhető, bármelyik sarkon megvásárolható termékről beszélünk, nem hájtek titkosszolgálati cuccról.

Én meg azoktól félek, akik nem képesek átlátni, hogy mi az a tanúsítványkiadó, mit jelent a "megbízni", és inkább üveges szemekkel bíznak valamiben csak azért, mert az nagyobb, külföldi, meg jól hangzik a neve, és főleg nem kell gondolkodni, mer' a firefoksz/szafari/króm tuggya és kész.

Akkor lassabban.
Az írod, hogy "Azt nem értem, hogy miért erőltetik ennyira, hogy rootca legyen a magyarországi három nagy cég tanúsítványa, amikor megtehetnék, hogy egy nagyobb világcég alá betagozódnak, amely már ott van az összes szükséges kliens gyűjteményében."
Azért, mert vannak, akiknek a pillanatnyi kényelmi szempontok (lásd: nem kell a CA root tanúsítványát importálni) nem elegek ahhoz, hogy elfogadja azt a döntést, hogy lényeges infrastruktúra - itt a hitelesítésszolgáltatás -, aminek felhasználásával akár komoly joghatást kiváltó adatcsere történik, ne tisztán magyar jogi körülmények között működjön. Egy világcég betagozódott cége, egy subordinate CA mindig függeni fog a root CA-tól, minimum műszakilag és jogilag (így gazdaságilag is). Ezért kell erőltetni.

Engem pl. pont az zavar, hogy a gyártók mindenféle, általam ismeretlen tanúsítványkiadót helyettem "megbízhatónak" minősítenek, ld. gyári root CA certificate-k bármilyen termékben (böngésző, oprendszer, java és tsai). A magyar - pláne kormányzati - weboldalon magyar tanúsítványkiadó alkalmazását pedig pártolom. A magyar szolgáltató ugyanis a magyar jogszabályoknak megfelelően kell, hogy működjön, ezért egy esetleges jogvita sokkal egyszerűbb.

( bitvadasz | 2011. 06. 06., h – 11:37 )

XP - chrome 12.0.733.0 dev : ok.
XP - firefox 3.6.13 : ok

Ubuntu 10.04 LTS - chrome 11.0.696.71 : ok
Ubuntu 10.04 LTS - firefox 3.6.17 : ok

lehet, hogy cserélték a bizonyítványt?

mert ugyanakkor XP és Ubuntu alól:

chrome - Megpróbálta elérni a(z) unixlinux.tmit.bme.hu címet, de a szerver olyan tanúsítványt mutatott fel, amelyet egy olyan kibocsátó állított ki, amelyben nem bízik meg számítógépének operációs rendszere. Ez azt jelentheti, hogy a szerver hozta létre a saját maga biztonsági tanúsítványát, amelyet a Google Chrome nem tud elfogadni, vagy egy támadó próbálja meg nyomon követni a kommunikációját. Javasoljuk, hogy ne menjen tovább, különösen akkor, ha ezt a figyelmeztetést még nem látta ezen a webhelyen

firefox - Azt szerette volna, hogy a Firefox biztonságosan kapcsolódjon a következőhöz: unixlinux.tmit.bme.hu, de nem garantálható, hogy a kapcsolat biztonságos.
Általában a biztonságos kapcsolat létrehozásakor a webhelyek megbízhatóan azonosítják magukat, hogy bizonyítsák, hogy a felhasználó jó helyen jár. Ennek a webhelynek viszont nem ellenőrizhető az azonossága.

szerk.
a ffx-ban "Builtin Object Token" a NetLock: Express(class C); Minősített Közjegyzői(class QA); Közjegyzői(class A); Üzleti(class B) Tanúsítvány

???:
nem emlékszem rá, hogy lehet megnézni adott https oldal hiteles(érvényes) tanúsítványát?

Firefox: Jobb gomb -> Oldal adatainak megjelenítése -- Erre kapsz egy új ablakot.

Ebben jobboldalt alul a "Részletek" gombra kattintasz. Az ablak tartalma megváltozik és láthatsz többek között egy ilyen gombot: "Tanúsítvány megtekintése" Ennek megnyomásakor kapsz egy újabb ablakot ahol kedvedre kitombolhatod magadat. :-)

Szerintem a helyzet az, hogy bár a whitehouse.gov az Akamai CDN-t használja a tartalma terítésére, nem adhatja a nevét (SSL tanúsítvány formájában) az Akamai által terjesztett tartalmakhoz, mert a tanúsítvány bővebb kört fedne le, mint csak a whitehouse.gov tartalmait. Az Akamai szerverei ezért csak a saját tanúsítványaikat használhatják a whitehouse.gov tartalmainak terítésekor.

( dash | 2016. 08. 16., k – 11:00 )

https://kerelem.valasztas.hu/vareg/MagyarCimKerelemInditasa.xhtml

Firefox ESR 45.3.0 írta:

kerelem.valasztas.hu uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER

e-Szigno SSL CA 2014

A weboldaluk szerint a 3-as verzió óta ismeri a Firefox a Microsec tanúsítványát.

--------------------------------------------------------------------
http://www.kmooc.uni-obuda.hu/
http://www.memooc.hu/
http://www.hbone.hu/hu/hirek/hbone_workshop
http://videotorium.hu/hu/channels/details/814,BME_Villamosmernoki_es_In…

( kruska v | 2023. 10. 25., sze – 09:15 )

Chrome/MacOS most szintén:

https://idopontfoglalo.kh.gov.hu/kormanyablak-xxx

NET::ERR_CERT_AUTHORITY_INVALID

Subject: *.kh.gov.hu
Issuer: NetLock Expressz (Class C) Tanúsítványkiadó
Expires on: 23 Jan 2024
Current date: 25 Oct 2023