ssl kulcs - kulso szerveren

Security-all

Hi,

Van egy *.domain.com tanusítvány, amit több szerveren is használunk. Nyílván ezért vettünk wildcard certificate-et. Nem sokára beindul egy új weboldal, ami azonban nem saját szerveren lesz, hanem menedzselt szolgáltatás. Nekünk is teljes hozzáférésünk van, de külsős cég a saját szerverein működteti a mi domainünk alatt a mi ügyfeleink számára. Szóltak, hogy állítsam be apache alatt az ssl-t.

A kulcs nem jelszavas, tudom öreg hiba, ez van...

Mennyire legyek paranoiás? Nincs velük negatív tapasztalat. Egy ilyen kapcsolat a bizalomra épül megfelelő szerződéses garanciákkal megtámogatva, de valahogy mégsem akaródzik kirakni a kulcsot egy külsős szerverre. Ti vásárolnátok erre a célra egy külön tanúsítványt?

Fefe

  • 2644 megtekintés

( bambano | 2010. 07. 30., p – 16:46 )

akkor felraksz egy apacs frontendet, ami redirektorral vagy proxyval vagy amivel akarod, berángatja az ő szerverükről már nem titkosítva a cuccot és azt szolgálja ki.

a másik, egyszerűbb megoldás, hogy a cég vegyen tanusítványt.

( uid_17784 | 2010. 07. 30., p – 19:04 )

A hálózatbiztonság ott kezdődik, hogy megtanul az ember paranoiásan gondolkodni.

(Az biztos, hogy a tanúsítványomat nem adnám más kezébe.)

( Hunger | 2010. 07. 30., p – 19:16 )

Több megoldás van:

- Jelszót teszel utólag a kulcsra és te magad indítod el vele a kiszolgálót a rendszerükön (ezt szeretted volna eredetileg): abszolút nem javaslom, mert nem biztonságos. A visszafejtett kulcs kinyerhető futás közben is a memóriából vagy indításkor leloggolható a jelszó egy tty snifferrel.

- Felteszel egy https reverse proxyt és saját magad engeded át a forgalmat: nyilván problémás lehet, ha nagy forgalom van és nem akarjátok ezt a plusz terhet a hálózatotokon vagy ha a szerződésetek ilyet nem enged meg.

- Előállítasz egy kulcspárt és certificate requestet az adott hoszthoz és az alapján kiállítasz egy kifejezetten arra szóló új tanúsítványt a saját hitelesített *.domain.com certeddel: szerintem a legjobb megoldás, én ezt tenném. Elméletben minden további nélkül működnie kell, a gyakorlatban nem tudom, hogy minden böngésző támogatja-e korrektül az ilyen többszörösen láncolt tanúsítványokat, de furcsálnám, ha nem menne.

Szerintem a saját tanúsítványával nem tudja aláírni hitelesen az általa kiállított tanúsítványt.

Ha be akar lépni a "láncba" akkor azért súlyos pénzeket kell fizetni egy root ca felé.

Nekem jobb megoldásom van, igaz nem pont egyetlen tanúsítványra, hanem további tanúsítványok megbízható elfogadtatására.

A ti problémátokat, ha arra az egy vasra kell tanúsítvány, akkor egy root ca-val aláíratott tanúsítvány fogja megoldani.

Nálam több szerver, meg programok hitelesítése (e kettő független egymástól)indította be a hangyát.

Vagyis van több szerverem és nem akarok mindegyikre 15 ezret költeni, meg vannak programok, amiket mi állítunk elő, és hitelesíteni szeretnénk a felhasználóink felé. Azonban nem akarunk fizetni olyan szolgáltatásért feleslegesen, amit mi is meg tudunk oldani, legalábbis részben.

Az elmélet a következő, hátha találsz benne a számtokra is használhatót:

1.) Kijelölsz egy tanúsítványtároló webszervert.

2.) Erre az egyetlen vasra egy root ca-tól beszerzel egy tanúsítványt, kb 15 ezer forint/év.

3.) Kijelölsz egy aláíró ROOT CA-t a gépparkodon belül, és kiállítasz vele egy önaláírt tanúsítványt.

4.) Azokra a szervereidre, amelyekre szükséged van tanúsítványra, létrehozod hozzá, és aláíratod a saját ROOT CA-ddal.

5.) Az aláírt tanúsítvány privát kulcs nélküli változatát elhelyezed az 1-es pontban említett szerveren. Természetesen ez a szerver feltörhetetlen, stb.

6.) Az ügyfeleidet kiértesíted, hogy erről a szerverről letölthetik a számítógépük ROOT CA tárolójába a tanúsítványt; amely weblapjaidat látogatják, az azokhoz valót.

A lényeg a dologban, hogy teljes bizonyossággal hiteles tanúsítványt töltenek le, mivel a szerver, amelyikről letöltik a szükséges tanúsítványt, egy hiteles, legfelsőbb szintű tanúsítványkiadó által van aláírva, és a szervert te üzemelteted.

Kb. így zajlik a folyamat:

Az ügyfél rámegy a weblapodra.
Az ügyfél böngészője tanúsítványhibát fog jelezni.
A weblapon van egy link, ami rámutat a tanúsítványtároló szerveredre.
Az ügyfél elmegy a link alapján a tanúsítványért.
A böngészője jelzi, hogy a weblap tanúsítvány rendben van.
Az ügyfél azért megnézi a weblap tanúsítványát, és látja, hogy az valóban rendben van, és innentől megnyugodhat, hogy jó helyre lett irányítva, és valóban egy hamisítatlan tanúsítványt fog majd innen letölteni.
Az ügyfél letölti a te ROOT CA-d tanúsítványát, és beemeli azt a gépe tanúsítványtárába.

Innentől bármelyik vebszerveredet felkeresheti, amit a te ROOT CA-d írt alá, rendben fogja azt találni, mivel a root ca-d tanúsítványa már ott van a gépén.

Ettől fogva már aláírt programokat is letölthet, azt is rendben fogja találni.

Szerintem működik a dolog.
Persze ha a nagyvilág számára akarsz kirakni weblapot, akkor ott bukik a mutatvány, hiszen nem valószínű, hogy elmegy a linken a tanúsítványért, és telepíti azt a gépére.

Tehát alapvetően üzleti partnerek esetében látom működőképesnek a fenti elképzelést.

Szerintem a saját tanúsítványával nem tudja aláírni hitelesen az általa kiállított tanúsítványt.

Nem a saját tanúsítványával fogja aláírni, hanem a saját privát kulcsával, amelynek publikus párjához szól a tanúsítvány.

Ha be akar lépni a "láncba" akkor azért súlyos pénzeket kell fizetni egy root ca felé

Miért kellene, a *.domain.com-ra van tanúsítványa.

Annyit kell csak tennie, hogy a *.domain.com tanúsítványát privát kulcs nélkül beteszi az új partner.domain.com tanúsítványa és a publikus kulcsok mellé. Tehát a külsős szerveren ott lesz az új partner.domain.com privát kulcs, az ahhoz készített certificate és a *.domain.com certificate, a privát kulcsa nélkül. Ennyi.

Nekem jobb megoldásom van

A leírás alapján nem tűnik jobbnak... :P

Az egyiknek nincs koze a masikhoz. A wildcardos tanusitvany csak azt jelenti, hogy barmilyen, az adott tartomanyba eso szerver azonositasara alkalmas, a tanusitvany alairo szerepkor pedig azt jelenti, hogy joga van tanusitvanyt alairni (openssl x509 -text kimenetben a CA: TRUE)
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Annyit kell csak tennie, hogy a *.domain.com tanúsítványát privát kulcs nélkül beteszi az új partner.domain.com tanúsítványa és a publikus kulcsok mellé. Tehát a külsős szerveren ott lesz az új partner.domain.com privát kulcs, az ahhoz készített certificate és a *.domain.com certificate, a privát kulcsa nélkül. Ennyi.

a kiemelésnél publikus akart lenni a szó, igaz?
("privát kulcs nélkül" 2x is szerepel)

A SSL titkositasnal alapvetoen akarhany publikus kulcsot csinalhatsz ugyanahhoz a privat kulcshoz. Mivel a webszervernek ugy kell titkositania, hogy az pont a publikus kulccsal legyen kinyithato, az ismert szabalyok ertelmeben a webszervernek rendelkeznie kell a tanusitvanyokhoz rendelt - ebben az esetben kozos - privat kulccsal. Ezert tehat a webszerverre fel kell masolni a privat kulcsot, a domain.com es a *.domain.com tanusitvanyt - melyeknel ugye hallgatolagos egyezseg, hogy ugyanahhoz a privat kulcshoz kotodnek, csak mas domain van rajuk festve. A privat kulcs ugyanis nem hordoz semmilyen adatot a jelszon kivul.

Egyebkent az ujfajta SAN tanusitvanyoknal mar nem kell ket tanusitvany, elmeletileg eleg lenne az is, ha a *.domain.com tanusitvanyon alternativ domainkent ott lenne a domain.com, csak SAN tanusitvanyt egy picit macerasabb eloallitani (OpenSSL-lel).
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"A SSL titkositasnal alapvetoen akarhany publikus kulcsot csinalhatsz ugyanahhoz a privat kulcshoz."

Nem.
http://en.wikipedia.org/wiki/RSA#Key_generation
Itt van az egyszerusitett leirasa, ebbol belathato, hogy nem tudsz egy privat kulcshoz tobb publikus kulcsot generalni, mert a privat kulcs a publikus kulcsban tarolt informaciokhoz kapcsolodo informaciokat tarol.

Ugyanahhoz a primszamparhoz kereshetsz mas relativ primet ('e' a szocikkben), de ez befolyasolja a privat kulcs tartalmat is ('d' a szocikkben).

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

? A openssl req utan ugy tudom, a kulcsfile nem modosul. (szerk: tesztelve, nem modosul). Ergo ugyanarra a privat kulcsra kiallithatok ket tanusitvanyt. Nem tudom, hogy ez titkositasilag hogy mukodik, igazabol nem is nagyon izgat, az a lenyeg, hogy eleg egy privat kulcs.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( Jason v | 2010. 07. 30., p – 19:23 )

én vennék külön certet, de mint említetted, hogy pénzügyek is érintve vannak az alkalmazásodban, így lehet nem 3rd party gépén kéne futtatni. ha már paranoia.

És igen, a paranoia legyen a szókincsed első 42 szava...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( egeresz | 2010. 07. 30., p – 23:42 )

ugyan.

Nala vannak az adatok.
Nala vannak a tranzakciok.
Mitol felsz? hogy iszonyatosan latvanyos es utolag jol nyomonkovetheto modon visszael a certtel?
Vagy hogy bena, es elkotyaveteli, es egy tamado megszerzi?
Egy olyan certet, ami 1 ev mulva ugy is lejar?

Egy olyan szolgaltatashoz, ami van annyira csoro, hogy gondolkodik egy cert megvasarlasan?

Ez a certes dolog, meg az egesz ssl egy jopofa dolog. Eleg olcso, tehat alkalmazzuk. Viszont a tamadasi faban sok-sok SOKKAL olcsobb utvonal van sikeres tamadas vegrehajtasara, mint egy cert megszerzese, fake weboldal felrakasa, userek odaterelese, vagy plane egy jol megoldott man-in-middle attack valamelyik szerveretekhez.
Szerined a userek mekora resze kattint a biztonsagi figyelmeztetesek "engem ez nem erdekel" gombjara? (mind)

najo, csak elmondtam :-)

Azt írta a posztoló, hogy "a mi ügyfeleink számára".

Tehát nem arról van szó, hogy Mari néni vagy Jóska-Pista törődik-e azzal, hogy a böngésző jelzi, hogy rossz weboldalon jár.

Tehát a szolgáltatás cégek között zajlik, és egy cégnél azért van valamilyen szabályozott formálya, hogy milyen módon lehet az üzleti szolgáltatásokat igénybe venni, meg persze a szolgáltatói oldalon is kell, hogy legyen szabályozva. Pl. IBSZ-ben jól le van írva, a dolgozóktól meg jól meg van követelve a betartása.

Pontosan azért fontos a tanúsítvány, hogy hülyegyerekmódszerrel ne lehessen sikeres támadást indítani.

Tehát tanúsítvány kell, azonban nem kell egynél több tanúsítványt vásárolni, ha pl. az IBSZ-ben rögzítik, hogy az általam vázolt módszer szerint járnak el.

Egyszerűen a szolgáltatást igénybe vevő cég tudomásul veszi, hogy számítógépeinek a ROOT CA tárolójába be kell tenni a szolgáltatást adó cég saját ROOT CA-ját.

A módszer pedig, amit vázoltam pontosan arra jó, hogy biztonságosan hozzá tudjanak jutni a szolgáltatást igénybe vevő cégek a szolgáltató tanúsítványához.

Ebben egy a bokkeno: ezt sok ceg policyje egyszeruen nem engedi meg, inkabb keresnek egy olyan partnert, akinek ervenyes certje van. Raadasul szerver-identifikacios certtel tovabbra sem lehet tanusitvanyt alairni. Nincs joga ra.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A "szerver-identifikációs cert"-tel nem is kell aláírnia semmit.

Amit a "hivatalos" magyar root ca kiállít, az a tanúsítvány csak arra kell, hogy a webszerver hiteles legyen az ügyfélkör felé, az a webszerver, amelyikről letölthetik a mi saját magunk által felállított root ca-nk tanúsítványát.

Tehát a hivatalosan aláírt szervertanúsítvány csak arra van használva, hogy a saját szervereink által kiállított, "amilyent akarok, olyan tanúsítványt" biztonságosan el lehessen juttatni az ügyfelek gépeinek root ca tárolójába. Persze igazándiból csak egyetlen tanúsítványt kell eljuttatni az ügyfelekhez, a saját root ca-nk tanúsítványát.

Innentől a sínen vagyunk, azaz olyan, mintha a saját root ca-nkat maga a Microsoft vette folna fel a Windowsos gépek root ca tanúsítvány tárába. Linuxon hasonló a helyzet.

Azt kell tehát megérteni, hogy a cél, hogy egy saját magunk által felállított root ca privát kulcs nélküli tanúsítványa valahogy jusson el az "ügyfélgépekig". (Az ügyfélgép minden olyan gép, amely szolgáltatásokat vesz igénybe egy másik géptől, tehát lehet dedikált szerver is.)

Az eljuttatást biztonságosan kell elvégezni; erre jó, amit leírtam itt: http://hup.hu/node/90849#comment-1084141

Attol meg nem lesz a te root CA-d hiteles, hogy egy CAcert/NetLock/Verisign tanusitvany altal vedett geprol lehet letolteni a root tanusitvanyat, ugyanis az a tanusitvany csak egy file, es mint ilyent, akarhonnet is elokerulhet, nincs garancia arra, hogy csak a te gepedrol kerul ki.

Tessek mar vegre felfogni, hogy ha a te CA tanusitvanyod nincs alairva egy megbizhato CA altal akkor nem hiteles. Pont. Ezt innentol lehet ragozni, fejre allhatsz es kiabalhatsz, akkor sem leszel hiteles, ugyanis semmifele modon nem tudod bebizonyitani, hogy az a tanusitvanyfajl honnet szarmazik, sem pedig garantalni, hogy mashonnan nem kerulhet elo. Marpedig ez rengeteg helyen policyba utkozik. Egyebkent is, az SSL titkositasnak a tanusitvanyok hitelessege az alapja, es nem a tanusitvanyok forrasanak a hitelessege. Marpedig ez itt soha a budos eletbe nem lesz meg.

Jo lenne, ha felebrednel a rozsaszinu almaidbol, es elkezdenel vegre gondolkodni, hatha rajossz, hogy egetvero ostobasagokat irsz. Nem szemelyeskedesnek szanom, ez a szomoru valosag. Egyebkent pedig olvasgass tobbet adatbiztonsagi temakorben, mert szomoruan alulmuveltnek tunsz e teren.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Bírom, amikor valaki elszáll, és nem lát a lila ködtől! :)

Pont a lényeget nem érted.

Nem akárhonnan tölti le, hanem a szolgáltató szerveréről, amit hitelesítve van egy szaros, pl. netlock tanúsítvánnyal.

A kliensnek a felelőssége, hogy ne akárkitől akárki root ca-ját töltse le. Tehát a kliensgép szervezete felel azért, hogy jó forrásból jó root ca tanúsítványt töltsön le.

Az hogy a forrás jó legyen, megbízhatóan azonosítható a mindenki számára hiteles root ca által aláírt szervertanúsítvánnyal.

Tehát nem tud csak úgy előkerülni valahonnan egy root ca tanúsítvány.
A hülyék ellen nincs gyógyszer.

Nem értem, hogy a pr0n hitelességét miben érinti, hogy a webszerver certje trusted CA által aláírt...
A CA nem vizsgálja, hogy a majagold.avi-ban tényleg az van amit a neve mond, s nem Attenborough összes műveiből a 3. cd első fele.

Két külön dolog. Érted már, miért nem érti senki, hogy miről beszélsz?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Azt nem akarja megérteni senki, ill. elsiklik afölött, hogy alapvetően üzleti partnerek közti bizalmi viszonról van itt szó.

Tehát én vagyok az egyik üzleti partner (üpSz, azaz szolgáltató), aki szolgáltat valamit a másik üzleti partnernek (üpV, azaz vevő).

Az üzleti partnerem (üpV) megbízik bennem, ezért lép üzleti partnerségre velem.
Ez a bizalom azt jelenti, hogy megbízik abban a szerverben (üpSz szerverében), ami hitelesen alá van írva, pl. a szaros NetLock által. Tehát a szerverben meg tud bízni, és innentől, mivel az üzleti partnere szerveréről van szó, ezért a rajta lévő tartalmat is az üzleti bizalom részeként tudja kezelni.
Ezt nem fogja fel senki.

Tehát ha üp-V az említett szerverről (üpSz-Sz) letölt egy tanúsítványt, akkor biztos benne, hogy az a tanúsítván minden tekintetben rendben van, hiszen a szerver hiteltérdemlően alá van írva. A tanúsítvány pedig, amit letölt, az üzleti partnerének, üpSz-nek saját root ca-s tanúsítványa. Tehát megfogja a letöltött tanúsítványt, üpSz-certjét, és beimportálja a sajtát root ca tanúsítványtárába.

Innentől kezdve üpSz-nek nincs szüksége a NetLock-ot pénzzel tömnie, elég évente egy SSL-tanúsítványért pénzt kiadnia. Bármilyen tanúsítványt hiteltérdemlően alá tud írni a saját maga által kialakított PKI-infrastrulktúrájával, aminek része a saját maga által felállított CA.

Csak emlékeztetőül: üzleti partneri viszonyról beszélek, nem arról, amikor valaki beesik egy szatócsboltba, ahol svédek szolgálják ki.

Tehát ha üp-V az említett szerverről (üpSz-Sz) letölt egy tanúsítványt, akkor biztos benne, hogy az a tanúsítván minden tekintetben rendben van, hiszen a szerver hiteltérdemlően alá van írva. A tanúsítvány pedig, amit letölt, az üzleti partnerének, üpSz-nek saját root ca-s tanúsítványa. Tehát megfogja a letöltött tanúsítványt, üpSz-certjét, és beimportálja a sajtát root ca tanúsítványtárába.

Azt ugye érzed, hogy ez a "bizalom", amiről beszélsz, technikailag feljogosítja a szolgáltatót, hogy _bármilyen_ domain névre kiállítson egy tanúsítványt, és azt a vevő kliens gépei kérdezés és zokszó nélkül eredetinek és biztonságosnak elhiszik?

Szerinted épelméjű vevő mikor ad ekkora bizalmat a szolgáltatónak?

Ha a www.cib.hu-ra csinálsz tanúsítványt, akkor még a banki tranzakcióit is el bírod lopni...

Bammeg, de nehéz!

Nem egy általános szolgáltatóról beszélek! Két partnerről van szó, A-ról meg B-ről. B megbízik A-ban, A pedig nem C-nek állít ki tanúsítványt, hanem saját magának.

Nem arról görcsölök itt, hogy a NetLock mellé beavanzsáljak egy céget, hogy holnaptól mindenki bízzon meg benne, és jöhetnek kerek e világból, mert ez az új szolgáltató majd mindenkinek kiállít valamit, vagy aláírja a certjüket. Nem, nem erről bazseválok!

Amit nem tudtok felfogni, az arról szól, hogy Göncz Árpád kitalálja, hogy minden általa lefordított könyvet hitelesen alá fog írni a jövőben.

Felállít egy webszervert saját maga, vesz rá egy SSL-tanúsítványt.

Felállít egy CA-t, kiállítja és aláírja a saját root certjét.
Ezt a certet felrakja a webszerverre, hogy bárki letölthesse, és importálhassa a gépének root ca-i közé.

Elkezdi aláírni a könyveit, digitálisan persze.
Aki letölti akárhonnan a könyvét, az hiteltérdemlően eldöntheti, hogy valóban Árpi bácsi írta-e alá.

Nu, ennyi.

Most lehet jönni azzal, hogy bárki mondhatja magáról, hogy ő Göncz Árpád.
De nem. Nem mondhatja bárki, mert bárki nem tud olyan webszervert üzemeltetni, amelyikre egy hitelesítő szervezet, pl. a szaros NetLock azt mondaná, hogy ne itt van egy cert, kiállítottuk neked, hogy te vagy Gönz Árpád szervere.

Tehát, semmi dolga annak, aki hiteles Gönz Árpád fordításokat akar olvasni, minthogy elmegy Árpi bácsi szerverére, és letölti azokat.

Persze a példa sántíyt ott, hogy ha már van Árpi Bácsinak egy webszervere, akkor felesleges aláírnia a rajta elhelyezett tartalmat, mert biztos lehetek benne, hogy ha onnan töltöm le, akkor azt Árpi Bácsi rakta fel oda.

De!

Árpi bácsi úgy dönt, hogy legalább további 100 szerverre tolja fel a könyveit, hogy ne a saját kis webszerverét terhelje az olvasni vágyó közönség.

Tehát Árpi bácsi jól alárja a könyveit, és jól feltölti a világháló 100 különböző szerverére.

Ha most én letöltöm az Al-Kaida egyik szerveréről Árpi bácsi könyvét, akkor is nyugodt szívvel fogom kinyitni, mert Árpi bácsi volt olyan kedves, és jól aláírta, én meg Árpi bácsi webszerveréről már korábban telepítettem Árpi bácsi root ca-jának certtjét.

Na, van-e valaki, aki nem érti még most sem?

Morálisan esélyesnek tartod, hogy kötsz egy üzletet egy üzleti partnereddel, az kiállít neked egy számlát, és te befogadod azt a számlát?
Megbízol benne, hogy valóban az, akinek mondja magát, vagy előtte futsz a cégbíróságra, és ellenőrzöd, hogy a cég létezik, adószáma megfelelő, stb.

Azért az általam vázolt technikában ott van ám egy legfelsőbb szintű hitelesítőszervetzet, pl. a szaros NetLock, aki miatt kellő bizalommal fogsz fordulni Árpi bácsi webszerveréhez.

Aki letölti akárhonnan a könyvét, az hiteltérdemlően eldöntheti, hogy valóban Árpi bácsi írta-e alá.

Nincs ehhez infrastruktúra, hogy _ezt_ dönthesd el.

Vagy mindent hiteltérdemlőnek fogadsz el, amit aláírt Árpi bácsi (akár a saját könyvéről van szó, akár máséról), vagy semmit, a root CA-sdi már csak így működik.

Persze elméletileg megnézheted minden egyes alkalommal, amikor valami secure site-t nézel, hogy pontosan melyik CA hitelesítette a weboldalt, de az emberek ezt nem szokták megtenni. Ami root CA által hitelesített, az biztonságos. Ha felveszek valakit a root CA-k közé, az _bármit_ aláírhat, és 99.99%, hogy nem fogom észrevenni, ha egy hamis banki oldalhoz írt alá egy tanúsítványt. És ugye míg egy normál root CA esetén vannak bizonyos biztonsági előírások (pl. biztosan nem elérhető az internetről az aláíró privát kulcsuk), addig egy random kis privát cég tuti nem ilyen körülmények között üzemelteti a CA-ját.

Ebben tökéletesen igazad van, Árpi bácsi meg más is mindent aláírhat, aki CA-t üzemeltet, és saját maga írta alá a root ca-ja tanúsítványát.

Bizalmi kérdés, az, hogy A cég megbízik B cégben. B céggel senki sem fog aláíratni semmit, mert miért is tenné bárki, ill. B cég nem fog aláírni senkinek, mert miért is tenné ezt.
Az természetesen lehetőség, hogy B cég azt mondja, hogy mostan jól megtréfálom az üzletfeleimet, azaz írok egy vírust, és aláírom. De hát ez az a kategória, amikor egy levélbombát küld az egyik cég a másiknak, azaz miért tenne ilyent?

Amúgy meg nem az otthoni felhasználókról szól a történet, hanem cégekről, ill. a céges rendszergazdákról. Én pl. megnézem az aláírást egy telepítendő program esetében, és megnézem a tanúsítványláncot, hogy kik vannak benne, és ki áll a tetején...
Mindezt teszem azért, mert nem akarok valami szart felnyomni a gépeinkre.

Tehát, ha van egy fejlesztő cég, Árpi bácsi cége, aki szoftvereket is készít, és mi üzleti kapcsolatba kerülünk velük, veszünk tőlük szoftvert, és ha a cég szarik fizetni a NetLocknak aláíró tanúsítványért, akkor mi ezt mélységesen megértjük, és letöltjük az SSL-tanúsítvánnyal védett szerverükről a root ca-s önaláírt tanúsítványukat, és beimportáljuk a megfelelő gépeinkre. Nem biztos, hogy mindre, csak ahová az szükséges.
Aztán, ha új verziót szeretnénk letölteni Árpi bácsiék valamelyik programjából, akkor letöltjük, és bizony megnézzük, hogy ki írta a letöltött programot alá, és ki hitelesítette azt, Ha Árpi bácsi, akkor oké, ha nem, akkor kukába megy a letöltött program, tehát nem telepítjük fel.

Szerinted hány nagyobb cég van, aki hajlandó felrakni a random root ca-d kulcsát a kliens gépeire? Ez ugyanis azt jelenti, hogy ha a random root ca-don hitelesítenek egy hamis www.gmail.com, vagy hasonló certet, majd azzal a hamis címmel csinálnak egy hamis weboldalt, aztán dns cache poisoninggal elérik, hogy az adott cég kliensei a hamis weboldalra érkezzenek, akkor random confidential információkat ellophatnak.
Magyarán: a root ca-k bármit aláírhatnak, azt a kliensek el fogják hinni. Ilyen szintű bizalmat nem könnyű kiérdemelni egy idegen cég biztonsági osztályán...

Akkor kis hazi dolgozat:

Magyarazd el, hogyan garantalod, hogy _sehonnan_, _semmilyen_ mas modon ne kerulhessen elo ez a root CA tanusitvany?

Illetoleg foglald ossze, hogyan bizonyitod be a mar letoltott CA tanusitvanyfajlrol utolag hitelt erdemloen, hogy az a te szerveredrol toltetett le. Feltetel: nem tamaszkodhatsz arra az allitasra, hogy ez a fajl csak a te szerveredrol toltheto le.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Van egy tanúsítvány a kezedben.
Hogy került oda? Oda fújta a szél?

Fogod magad, és elmész letölteni Gönz Árpád önaláírt tanúsítványát Göncz Árpád webszerveréről.

Felmész a webszerverre, jól megnézed, hogy valóban ott kötöttél-e ki.
Ha igen, akkor letöltöd Árpi bácsi önaláírt tanúsítványát, és jól kézbeveszed, szorosan fogod, nehogy egy szellő kifújja a kezedből, egy másik szellő meg egy másikat belefújjon.

Tehát semmi más dolgod nincs, mint jó szorosan megragadni a letöltött tanúsítványt, és betenni abba a pánczélterembe, amit úgy hívnak hogy megbízható legfelsőbb szintű hitelesítésszolgáltatók tárolója.

Ezt követően meg jól lezárod a pánczéltermet.
Mi ebben a nehoz?

Tehát nem a hülyegyerek tölti le az Al-Kaida szerveréről a Göncz Árpád névre kiállított önaláírt tanúsítványt, és nem mész oda a majálisba ehez a hülyegyerekhez, hogy adjon már egy másolatot Árpi bácsi root ca certjéből.
Nem, nem így jársz el!

Van agyad, meg egy szervezet/cég, akinek az érdekeit képviseled. Ez a szervezet üzleti kapcsolatba kerül egy másik szervezettel, de maradjunk Árpi bácsinál, tehát ennek a szervezetnek a vezetősége Göncz Árpád műveiért él-hal, tehát hiteles, Árpi bácsi által digitálisan aláírt anagokat akar letölteni a netről.
Tehát feladatot kap ennek a szervezetnek a rendszergazdája, hogy telepítse Árpi bácsi root ca certjét a szervezet gépeire.
A szervezet nem Gipsz Jakabot alkalmazza rendszergazdaként, hanem egy aggyal rendelkező, monjuk úgy, hogy normális embert.

Természetesen a pénztáros is normális ember, és ennek ellenére tud csalni sikkasztani, de a cég rendszergazdája abban van megfelelően támogatva, hogy ha normálisan akar eljárni, akkor valóban Göncz Árpád root ca sertjét fogja letölteni, és importálni a gépekre.

Egyéb iránt, ha az említett rendszergazda mégis csalni akarna, és Az Al-Kaida terrorszervezet bedolgozó munkatársa volna, akkor a NetLock root ca certjét is ki tudná cserélni bármi másra.

Tehát kérdezem én, hogy hogyan tudod hiteltérdemlően bizonyítani, hogy a számítógéped trusted certificate tárolójában valóban NetLock által önaláírt tanúsítvány figyel.

Nyilván megbízol a Microsoftban, hogy valóban azt rakta bele.

A kerdesre nem sikerult valaszolni, de azert koszonom ezt a hozzam intezett sok betut. Azert meg mindig varom a kerdeseimre a valaszt.

"Tehát kérdezem én, hogy hogyan tudod hiteltérdemlően bizonyítani, hogy a számítógéped trusted certificate tárolójában valóban NetLock által önaláírt tanúsítvány figyel."
Ehhm... itt az a baj, hogy Arpi bacsi akar fellepni hitelesitesszolgaltatokent, nem pedig egy elismert hitelesitesszolgaltato -> fail.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Egyszerűen a szolgáltatást igénybe vevő cég tudomásul veszi, hogy számítógépeinek a ROOT CA tárolójába be kell tenni a szolgáltatást adó cég saját ROOT CA-ját."

Csak remelni tudom, hogy keves olyan idiota ceg letezik, aki erre hajlando lenne.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

ha már nem hiszünk a fizetős CA-kban, akkor legalább keresztbe tegyük meg a dolgot :)
úgyértem ha valaki velem ilyet rendezne, akkor azt azért megpróbálnám elérni, hogy mondjuk o irja ala az en kulcsomat, így fogadja el, ne o ismerje el az en mindenfele cuccomat. Mar csak azertis, ha eccercsak nem bizik bennem, revoke-ol egyet szt kesz.
De ha az altalad idezett mondat all fenn, akkor jobb masik szolgaltatot keresni :)

(Na, ez most ilyen C2H5OH altal befolyasolt lett.)

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.