SSL

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2015. április 2., 14:39-kor történt szerkesztése után volt.

Az SSL/TLS hivatott a Webet és számos más szolgáltatást biztonságossá, hitelessé tenni. Vizsgáljuk meg, hogyan működik (magas szinten), és milyen bajok vannak vele.

Tartalomjegyzék

1 Tanúsítványok

A tanúsítvány lényegében nem más, mint egy nyilvános kulcs, egy érvényességi idő, plusz a tulajdonos neve (vagy hosztneve, IP-címe, emailcíme stb.), digitálisan aláírva (hiszen amúgy bárki állíthatná, hogy ő teszemazt az OTP Bank, és a nyilvános kulcsa a mellékelt kulcs). Az aláírás készítője az aláírás elkészítésével azt jelenti ki, hogy meggyőződött arról: a nyilvános kulcs valóban a tanúsítványban megnevezett entitáshoz tartozik.

A tanúsítvány-alapú hitelesítés tehát legfeljebb annyira jó, amennyire az aláírások készítői alaposak -- amennyire (hihető, hogy) lehetetlen olyan aláírt tanúsítvány birtokába jutni, amely valaki másnak a nevére szól.

Arra, hogy az aláírást ki készíti, két elterjedt modell van:

  1. Web of Trust (bizalmi háló). A kulcstulajdonosok egymás tanúsítványait hitelesítik (egy tanúsítványt tipikusan egynél több aláírással is ellátnak).
    • Ha Katona Anna, Varga Bence, Pór Jutka, Fazekas Marci, Fazekas Eszter, Domokos Matyi, Vas Pista, Pengő Gyöngyi, Fodor Dávid és Kovács Vicu egybehangzóan állítja (és saját digitális aláírásával megerősíti), hogy a mellékelt nyilvános kulcs Vackoré, a piszén-pisze kölyökmackóé, akkor ezt hajlamosak lehetünk elhinni (míg ha csak a közismerten szeleburdi Pór Jutka és az iszákos, ufóhívő Vas Pista állítja, akkor esetleg nem).
      • Mindennek persze csak akkor van értelme, ha amúgy már más hiteles forrásból ismerjük az aláírók legalább egy részének a nyilvános kulcsát, és feltételezzük róluk, hogy ők maguk meggyőződtek arról, hogy a szóban forgó kulcs tényleg Vackoré -- pl. Vackor maga mondta nekik.
      • Tehát a legnagyobb gond: minél több kulcs valódiságáról saját magunknak kell meggyőződnünk, hogy utána a velük készült aláírásokat elfogadhassuk.
      • Bárki könnyen csinálhat magának 5000 aláírással ellátott tanúsítványt (elég hozzá 5000 automatikusan generált kulcspár); a bizalmat nem (csak) az aláírások száma, hanem a minősége alapozza meg.
      • A bizalmi gráf sűrűségének fokozására aláíró-rendezvényeket szoktak tartani, ahová az adott városban tartózkodó, kulcspárral rendelkező emberek elmehetnek, és hitelesíthetik egymás tanúsítványait -- miután meggyőződtek a másik személyazonosságáról.
        • Gond: emberi tényező. Sokan egy Balaton szeletért bármit hitelesítenek. Az ismeretlen személyek aláírásai már csak emiatt sem érnek semmit, arra viszont világméretű rendszer esetében kevés az esély, hogy egy véletlenszerűen kiválasztott résztvevő tanúsítványát hitelesítette valamelyik megbízhatónak gondolt ismerősöm.
          • Az ilyen értelemben vett megbízhatóságnak nagyon kevesen vannak birtokában: gondosan ügyelni kell(ene) arra, hogy az aláírandó tanúsítványban tényleg a kulcspárt birtokló személy vagy szervezet neve legyen, ne egy ahhoz megtévesztésig hasonló név (Kovács vs. Kováts, Sípos vs. Sipos, OTP Bank NyRt. vs. Országos Takarékpénztár, Gáz Géza vs. dr. Gáz Géza stb.).
        • Névváltozáskor új tanúsítványra van szükség; újra össze kell gyűjteni elegendő számú és minőségű aláírást, ami nem egyszerű.
          • A cégek neve "naponta" változik (Pannon GSM -> Pannon -> Telenor; Matávnet -> Axelero -> T-Home stb.).
          • A személyek új címeket vesznek fel a nevükbe, férjhez mennek, megnősülnek stb.
  2. Központi hitelesítés. Van egy vagy néhány definíció szerint megbízható hitelesítőközpont (vagy hitelesítő/hitelesítési hatóság: CA, Certification Authority), és minden tanúsítványt ezek valamelyike hitelesít (többnyire jó pénzért).
    • A tanúsítványok pontosan annyira megbízhatóak, amennyire az őket aláíró hitelesítőközpont az.
    • Ezt a modellt használja az SSL (és így a https).
      • A világméretű hitelesítő hatóságok tanúsítványai (nyilvános kulcsai) be vannak építve a böngészőkbe (és egyéb alkalmazásokba) -- szintén jó pénzért (amit a CA fizet a böngésző gyártójának; neki megéri, mert a böngészők támogatása teszi eladhatóvá a szolgáltatását).
        • Így a böngészők tudják ellenőrizni a CA-k által aláírt tanúsítványok (www.otpbank.hu, mail.google.com stb.) hitelességét -- vagyis el tudják dönteni, hogy a tanúsítványt valamelyik általuk ismert CA írta-e alá.
      • 2012-ben ezres nagyságrendű ilyen (a böngészők által elismert) hitelesítőközpont van.
      • Ezek megbízhatósága... "ellentmondásos megítélésű". Egymást érik a botrányok, és elég, ha az egyik nem elég szigorú, máris kérdésessé válik az egész rendszer biztonságossága.
        • Az egyik CA hitelesített egy olyan, a Microsoft nevére szóló, kód-aláírásra szolgáló tanúsítványt, amely nem a Microsofté volt (röviddel később visszavonták).
        • Forgalomban vannak nem globálisan egyedi nevekre szóló tanúsítványok (pl. "localhost", "mail").
        • Némelyik hitelesítőközpont joker-tanúsítványokat adott cégeknek vagy kormányoknak azért, hogy az általuk felügyelt hálózaton lebonyolított SSL-el védett forgalom könnyedén lehallgatható legyen.
          • Pl. Irán 2011. júliusától augusztusáig egy "hamis" (elismert CA által hitelesített) tanúsítvány segítségével lehallgatta állampolgárai és a Google között zajló titkosított kommunikációt. Nem zárható ki, hogy ez ellenzékiek szabadságába vagy akár életébe került.
          • 2015-ben a CNNIC adott ki egy olyan köztes CA-tanúsítványt, amelyet ezt követően egy man-in-the-middle proxyban használtak. A Google válaszul kivette a CNNIC tanúsítványát a Chrome által megbízhatónak vélt CA-k listájából és nem is hajlandó visszatenni addig, amíg a CNNIC nem vezeti be a Google által a Certificate Transparency program keretében szorgalmazott folyamatokat.
        • Lehetséges (volt?) a nullás ASCII-kódú karaktert tartalmazó névre szóló tanúsítványt kérni és kapni. Pl: "www.otpbank.hu\000.akarmi.cn". A böngészők jelentős része a nullás karaktert a sztring végeként értelmezte.
        • Ezzel rokon problémát okoznak a nemzetközi domain-nevek. Bejegyezhetem pl. a hu⁄portal⁄hu⁄OTPdirekt⁄Belepes.cn domaint (a "⁄" és a "/" karakter nem azonos; az előbbi előfordulhat domain-névben), és ez alatt a domain alatt a www.otpbank hosztot. Az ezen a hoszton üzemelő SSL-es webszerverre mutató URL a következő: https://www.otpbank.hu⁄portal⁄hu⁄OTPdirekt⁄Belepes.cn/ -- ez vizuálisan nagyon hasonlít arra, hogy https://www.otpbank.hu/portal/hu/OTPdirekt/Belepes. Természetesen minden további nélkül kaphatok a kínai domain-névre szóló tanúsítványt, ha az a domain az enyém, és máris eszményi phishing-pozícióban vagyok.
          • Hasonló a helyzet a cirill betűkkel: А, В, Ѕ, Ј, М, Н, О, Р, С, Т, Х, Ԝ, Ү, ӏ, а, е, о, р, с, у, х, ѕ, ј, ѵ, ѹ, ү, ԁ, ԛ, ԝ stb. Ember legyen a talpán, aki ránézésre megkülönbözteti a bank szót a bаnk szótól (utóbbiban az a-t egy cirill "а" helyettesíti).
        • Előfordult, hogy úgy hitelesítették a tanúsítványt kérőt, hogy megnézték, képes-e levelet fogadni pl. a root@ címen a választott domainben; ha igen, elhitték, hogy ez az ő domainje, és kapott tanúsítványt. Csakhogy számos web-alapú email-szolgáltatónál a "root" usernevet nem kezelik speciálisan; a felhasználók nyugodtan regisztrálhatják.
      • A rendszer célja eredetileg az volt, hogy a felhasználók hitelkártya-adatait megvédje a bűnözőktől. Ma arra is használják, hogy a felhasználók magánszféráját megvédjék az abba behatolni próbáló állami szervektől, és erre nem biztos, hogy alkalmas.

Jelenleg az ún. X.509-es típusú tanúsítványok a legelterjedtebbek (az SSL ilyeneket használ). Ezek a következő adatokat tartalmazzák:

  • sorozatszám (a CA rendeli hozzá);
  • érvényességi idő;
  • a kiállító CA neve;
  • a tanúsítvány tulajdonosának neve;
  • a tulajdonos nyilvános kulcsa;
  • "basic constraints": használható-e a tanúsítvány más tanúsítványok hitelesítésére, ill. a maximális úthossz a hitelesítési láncban a gyökér és a levelek között;
  • opcionális egyéb mezők;
  • a CA titkos kulcsával készített, a fentiek kivonatára (hash-ére) vonatkozó aláírás.
    • Kb. 2009-ig számos CA MD5 hasht használt erre a célra. Így lehetségessé vált az alábbi támadás:
  1. Keressünk egy olyan CA-t, amely MD5-öt használ kivonatképzésre.
  2. Vizsgáljuk meg az általa kiadott tanúsítványok sorozatszámait. Véletlenszerűek? Ha igen, nehezebb dolgunk lesz, úgyhogy keressünk másik CA-t.
  3. Ha a sorozatszámok megjósolhatók (pl. egyesével növekednek), akkor állítsunk elő két tanúsítványt:
    • Az egyik legyen egy közönségesnek látszó website-tanúsítvány, amelynek a nyilvános kulcsa azonban a CA számára észlelhetetlen értelemben speciális (úgy választjuk meg, hogy a második tanúsítványunknak ugyanaz legyen az MD5 hash-e, mint ennek). Mivel sejtjük, milyen sorozatszámot fog kapni a tanúsítvány a CA-tól, az egész aláírandó adathalmazt ismerjük, vagyis tudjuk, milyen MD5 hash-hez fog aláírást készíteni a CA.
    • A másik tanúsítványunk egy CA-tanúsítvány, amelynek az aláírandó része ugyanazzal az MD5 hash-sel rendelkezik, mint az első tanúsítványé.
  4. Írassuk alá az első tanúsítványt a CA-val.
  5. Az aláírást másoljuk át a másik tanúsítványra (amelyre az MD5 hash azonos volta miatt szintén érvényes lesz).
    • Így a CA -- anélkül, hogy tudta volna -- kibocsátott egy olyan tanúsítványt, amely alkalmas további tanúsítványok hitelesítésére.
  6. Az új CA-tanúsítványunkkal felvértezve tetszőleges névre szóló, érvényesnek látszó tanúsítványokat állíthatunk ki.
    • A sikeres támadáshoz a CA által generált tanúsítvány/aláírás érvényességi idejét is másodpercre pontosan meg kell jósolni. A valóságban ez könnyűnek bizonyult.
    • Az ütköző hash-ű tanúsítványok előállítása kb. 3 napba telt 2009-ben (200 darab PS3-as játékkonzolon), tehát 3 napra előre meg kellett tudni jósolni, milyen sorozatszámú tanúsítványokat fog kiadni a CA. Az idézett cikk szerzőinek megoldása:
      1. Néhány mintavétel (tanúsítvány-vásárlás) segítségével megállapították, hogy csütörtök estétől vasárnap estig kb. 800-1000 tanúsítványt állított ki a CA.
      2. Csütörtök este vásároltak egy tanúsítványt, hogy megtudják, éppen hol tart a számláló.
      3. Ehhez hozzáadtak 1000-et, arra számítva, hogy vasárnap este (amikorra elkészülnek a két, az érdemi támadásban felhasznált tanúsítványok) a számláló ezt az értéket még nem éri el.
      4. Az első támadó-tanúsítvány megvásárlásának ideje kötött (mivel előre meg kellett tippelni az érvényességi időt, a CA által beállított idő pedig a vásárlás időpontjától függött). Vasárnap este elkezdtek tanúsítványokat vásárolni, hogy a kiszemelt utolsó vásárlás előtti 30. másodpercben legyen a számláló értéke eggyel kisebb, mint a kívánt érték.
      5. A megfelelő pillanatban megrendelték a speciális tanúsítványt, abban a reményben, hogy az utolsó fél percben már senki nem vásárolt újabb tanúsítványt.
        • Ez a negyedik hétvégén sikerült; addigra 657 dollárt (kb. 130.000 Ft-ot) költöttek el tanúsítványokra.

1.1 Kitérő: Mennyire elterjedt a https?

  • 2010-ben kb. 16 millió nyilvános IP-cím nyújtott szolgáltatást a 443-as porton.
  • Ebből kb. 11,5 millió 443-as portján volt SSL-es szolgáltatás.
  • Kb. 4,3 milliónak volt érvényes tanúsítványa.
  • Kb. másfélmillió egyedi érvényes tanúsítvány volt.
  • Kb. 1500(!), az Internet Explorer vagy a Firefox által elismert CA van.
    • Ezeket kb. 650 szervezet üzemelteti, a Föld 52 országában.
      • Kb. 200 közülük német felsőoktatási intézmény. A Deutsche Telekom root CA az NIIF Intézet helyi megfelelőjének, a Deutsches ForschungsNetz Vereinnek adott CA-tanúsítványt, az pedig hitelesítette az egyetemek CA-inak tanúsítványait. Így most pl. egy német főiskola CA-ja elvileg simán hitelesíthetné az otpbank.hu tanúsítványát.
        • Van erről egy Mozilla hibajegy; abban azzal nyugtatják meg a kedélyeket, hogy a DFN-Verein maga üzemelteti az összes általa hitelesített CA-t, tehát az adott CA-k titkos kulcsai nincsenek az érintett egyetemeknél, a DFN pedig ellenőrzi, hogy az egyetemek által kért tanúsítványok az adott egyetemhez tartozó domainek valamelyikével kapcsolatosak-e.
      • A Deutsche Telekom és minden gyermeke együtt is csak kb. 4000 https-tanúsítványt hitelesített; egy-egy CA-ra csak kb. 16 tanúsítvány jut. Felmerül a kérdés, érdemes-e ezért fenntartani ennyi elvileg globális hatókörű CA-t?
        • (Elvileg elképzelhető, hogy a 4000 https-tanúsítvány mellett még van sokezer személyre szóló tanúsítvány is, vagy hogy sokkal több https-tanúsítvány van, csak azok nem látszanak San Franciscóból, ahol a felmérés készült.)
    • Jó részük "intermediate CA": a tanúsítványa nincs benne a böngészőben, de olyan CA írta alá, amelyik benne van. Tehát nem is egyszerű képet kapni arról, milyen tanúsítványokat is fogad el a böngészőnk.
    • Az újabb Windows- és IE-verziók már nem (kizárólag) bedrótozott listákkal dolgoznak; ha új CA-val találkoznak, a Microsoft szerverétől kérdezik meg, meg kell-e bízni benne.

1.2 További gondok az X.509-es tanúsítványokkal és az SSL-lel

  • ITU-T szabvány a '80-as évekből (a web előttről, tehát nem igazodik a web sajátosságaihoz).
  • Nincs pontosan meghatározva, milyen mezőknek kell benne lenni egy tanúsítványban, ezekben milyen adatnak kell szerepelnie és azt hogyan kell értelmezni.
    • Emiatt nagyon nehéz olyan szoftvert írni, amely helyesen dolgoz fel X.509-es tanúsítványokat.
    • Vannak önellentmondó tanúsítványok (egyszerre mondja, hogy nem CA-tanúsítvány és hogy használható más tanúsítványok hitelesítésére).
  • Rengeteg CA van.
  • A CA-k mindegyikének globális a hatóköre (nincs a DNS-ben látott autoritativitáshoz hasonló dolog, ami mondjuk egy kínai CA-t megakadályozna abban, hogy magyar domainre vonatkozó tanúsítványt bocsásson ki).
    • Emiatt az SSL egésze, globálisan ki van téve mindenféle nemzeti törvényhozások szeszélyeinek.
  • 2010-ben még mindig kb. 30.000 webszerver használt triviálisan kitalálható kulcsú tanúsítványt (Debian SSL bug); ezek közül 500-nak érvényes, globális CA által készített aláírása is volt.
    • Pl.: yandex.ru, diplomatie.be.
  • Nincs jó módszer arra, hogy egy CA-nak szóljunk, hogy valamelyik tanúsítványt vissza kellene vonnia.
    • A visszavonásról szóló információ terjesztése szintén problémás, és a böngészők alapértelmezés szerint gyakran nem foglalkoznak vele (mert igazából nincs sok értelme).
      • Korábban az volt a módszer, hogy aránylag nagy CRL-ek (certificate revocation list) formájában minden CA közzétette az elvileg még érvényes, de gyakorlatilag visszavont, általa kiállított tanúsítványok listáját (nyilván aláírva). A tanúsítványban benne volt (van) az adott CA CRL-jének az URL-je, így a böngésző letöltheti a teljes listát és megnézheti, rajta van-e az éppen meglátogatott szerver tanúsítványa. Mivel ez jelentősen megnövelheti a kapcsolódás időigényét, és mivel a https-t eredményesen támadni képes támadó általában arra is képes, hogy egy korábbi CRL-t játsszon vissza a kliensnek, nem szokás foglalkozni vele. (Külön bónusz lenne, ha a CRL is https URL-en lenne, mert akkor azt is meg kellene nézni, annak a https-es site-nek a tanúsítványát nem vonták-e vissza stb., de a valóságban http szokott lenni -- sajnos ez lehetővé teszi a visszajátszást.)
      • Egy újabb megoldás az OCSP (Online Certificate Status Protocol). A lényege az, hogy a kliens a tanúsítványban megadott, általában az aláíró CA által üzemeltetett webszerverhez fordulva lekérdezheti, hogy az épp most látott tanúsítványt nem vonták-e vissza. A választ a CA érvényességi idővel és aláírással látja el. Így a böngészőnek nem kell az egész CRL-t letölteni; cserébe a CA mindig megtudja, ha egy böngésző egy általa aláírt tanúsítvánnyal találkozik. Ha a tanúsítványt nagy forgalmú szerveren használják, a keletkező forgalom elég nagy lehet. További probléma, hogy az OCSP üzenetei lehallgathatók és visszajátszhatók; elvileg ugyan lehetne a kérésben egy nonce (mint a DNS-nél), amit a szerver a válaszban megismétel, de a gyakorlatban a kliensek nem rakják bele. Ezeknek a problémáknak egy részét enyhíti vagy oldja meg az OCSP stapling (l. alant).
  • Az "Extended Validation" tanúsítványok (amikor zöld az URL-mező a böngészőben) elvileg sokkal szigorúbb feltételeknek kellene, hogy eleget tegyenek: nagyobb kulcshossz, gondosabb hitelesítési folyamat stb. Csakhogy: a CA-k ezt nem tartják be.
    • Létezik pl. localhost névre szóló EV tanúsítvány;
    • vagy olyan, 1024 bites RSA kulcsot használó tanúsítvány, amely 2010 december 31-e után jár le, pedig elvileg ezeknek már 2048 bites kulcsot kellett volna tartalmazniuk.
      • Sőt, még egy 512 biteset is találtak, ami csak 2012-ben fog lejárni.
    • Elvileg szintén tilos lenne joker-tanúsítványt (*.domain.tld-re szólót) kiállítani EV folyamattal, mégis léteznek ilyenek.
    • Szintén létezik 192.168.x.y-os IP-re szóló EV-tanúsítvány.

1.3 Alternatívák, részleges segítség

  • Perspectives ill. "Convergence" -- figyelmeztet, ha egy site tanúsítványa nem az, amit más felhasználók láttak ugyanott.
    • Ezzel lényegében elkerültük a CA-kat, és P2P alapokra helyeztük a hitelesítést.
  • Certificate Patrol -- figyelmeztet, ha egy site tanúsítványa megváltozott a legutóbbi látogatásunk óta (akkor is, ha az új tanúsítvány is hitelesnek látszik).
  • Conspiracy -- a böngésző státuszsorában mutatja, milyen országok CA-i vettek részt az éppen meglátogatott site tanúsítványának hitelesítésében. Ha mondjuk malajziai tanúsítványt látunk egy olyan oldalon, amely egy német bank weboldalának látszik, gyanakodjunk.
  • Calomel SSL Validation -- egy színkódolt pajzzsal mutatja, mennyire erős az éppen meglátogatott site SSL-je (hánybites titkosítást használ, van-e perfect forward secrecy stb.)
  • A Google Chrome-ba és [https://wiki.mozilla.org/Security/Features/CA_pinning_functionality hamarosan a Firefoxba bedrótozhatók site-ok ismert tanúsítványai (pontosabban: előírható, hogy a tanúsítványláncban szerepeljen egy olyan tanúsítvány, amelynek a nyilvános kulcsát hash-elve adott értéket kapunk), így a böngésző ezeken a site-okon akkor sem fogad el más tanúsítványt, ha az amúgy hitelesnek tűnik. Lényegében előírható, melyik CA(k) hitelesítheti(k) a site-un tanúsítványát.

2 Gyakorlati tanácsok szerverüzemeltetőknek

  • A https://www.ssllabs.com/projects/best-practices/index.html címen tömören leírják, mire érdemes odafigyelni.
  • Kapcsoljuk be a HSTS-t. Ezzel előírjuk a böngészőnknek, hogy a site-unkat csak https-sel szabad elérni, továbbá hogy nem szabad lehetőséget adni a felhasználónak egy esetleges certificate warning átugrására. Ehhez mindössze a Strict-Transport-Security fejlécet kell beállítanunk, Apache-val pl. így:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  • Csak erős titkosítóalgoritmusokat és protokollokat támogassunk szerveroldalon, hogy egy man-in-the-middle támadó az SSL handshake-üzenetek átírásával ne tudja mondjuk 56 bites DES-re lenyomni a kliens és a szerver közötti kommunikációt. Apache-on pl:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
  • Kapcsoljuk be az OCSP stapling mechanizmust (ez csak akkor fog működni, ha a tanúsítványunkban van OCSP URI). Így a webszerverünk rendszeresen megkérdezi a CA-t, hogy nincs-e visszavonva a tanúsítványunk, amire a CA egy digitálisan aláírt, dátummal ellátott választ ad. Ezt a szerver hozzácsomagolhatja a tanúsítványunkhoz, amikor elküldi a kliensnek, így a kliens egyből látja, ha a közvetlen közelmúltban igaz volt, hogy a tanúsítványt nem vonták vissza.
  • A https://www.ssllabs.com/ssltest/index.html oldalon kérhetjük, hogy a webszerverünk SSL-beállításait egy script vizsgálja meg.

3 Szégyenfal

2012. október végén a Nemzeti Adatvédelmi és Információszabadság Hatóság oldalán van egy link a https://81.183.229.204:51111/abi/NAIH_Avatar2.exe-re. A tanúsítvány 2010. szeptemberében lejárt, self-signed és a C=DE/ST=Berlin/L=Berlin/O=Apache Friends/CN=localhost nevére szól.

2014. június elején a Fővárosi Közterület Fenntartó Zrt. még mindig egy 2010-ben lejárt tanúsítványt használt.

4 Potenciális ZH-kérdések

  • Mi a web of trust?
  • Hasonlítsa össze a "web of trust"-modellt a hitelesítő hatóságokon alapuló hitelesítési modellel!
  • Mi a tanúsítvány?
  • Mit tartalmaz egy X.509-es tanúsítvány?
  • Mik a főbb gondok az SSL-lel? Ne csak műszaki problémákra gondoljon!
Személyes eszközök