SSL

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Új oldal)
 
(új fejezet: szégyenfal)
106. sor: 106. sor:
 
* [https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ 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).
 
* [https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ 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).
 
* A Google Chrome-ba [http://dev.chromium.org/sts bedrótozhatók] site-ok ismert tanúsítványai, í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. Kétélű fegyver.
 
* A Google Chrome-ba [http://dev.chromium.org/sts bedrótozhatók] site-ok ismert tanúsítványai, í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. Kétélű fegyver.
  +
  +
== Szégyenfal ==
  +
  +
2012. október végén a [http://www.naih.hu/bejelentkezes.html 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 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.

A lap 2012. október 30., 13:39-kori változata

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.
        • 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.
        • 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.
  • 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).
  • A Google Chrome-ba bedrótozhatók site-ok ismert tanúsítványai, í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. Kétélű fegyver.

2 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.

Személyes eszközök