Magyar Opera

Címkék » biztonsági_hiba


A pudli és az Opera

Az elmúlt napokban igen nagy visszhangot kapott informatikai körökben a POODLE nevű biztonsági hiba, ami a fél éve felszínre került Heartbleedhez hasonlóan szintén a biztonságos(nak hitt) HTTPS technológiát érinti.

Mi az a POODLE?

A Padding Oracle On Downgraded Legacy Encryption magyarul nagyjából azt jelenti, hogy bélésből jóslás a leminősített örökölt titkosításon. Ennek így nem sok értelme van, ezért inkább részletezzük egy kicsit, hogy miről is van szó.

A ma használt titkosítási eljárások fix méretű, úgynevezett blokkokkal dolgoznak. Az AES például 16 byte-os, a 3DES pedig 8 byte-os blokkokat használ. A titkosítandó adat viszont ritkán bontható egész számú blokkokra, ezért a bitsorozat végét egy úgynevezett béléssel szokták feltölteni, hogy az utolsó blokk is ugyanolyan méretű legyen, mint a többi. Ha az adat pont olyan hosszúságú, hogy egészszámú blokkokra lehet osztani, akkor az algoritmus hozzárak még egy blokkot, ami csak a bélést fogja tartalmazni. A bélés utolsó byte-ja egy számot tartalmaz, ami azt mondja meg, hogy az utolsó blokkban hány byte hosszú a bélés. Ha tudjuk, hogy az eredeti üzenet hány byte hosszú volt, akkor könnyedén megmondhatjuk, hogy hány byte hosszúságú ez a bélés anélkül, hogy a titkosítást visszafejtenénk.

Ha szerencsénk van, és az adat pont olyan hosszú, hogy az utolsó blokk csak bélés, akkor a bélés utolsó byte-ja csupa egyest fog tartalmazni. Ha a bélés utolsó egy byte-ját kicserélhetjük egy másik titkosított bitsorozattal, és az így képzett blokkot a szerver elfogadja, az azt jelenti, hogy a kicserélt bitsorozat csupa egyesből állt. Ebben az esetben máris megszereztünk egy byte-nyi információt a titkosított adatból. Ha a feltörni kívánt bitsorozat minden byte-jával eljátszuk ezt a trükköt, akkor minden olyan byte-ot megtalálunk, ami csupa egyest tartalmaz. Ezzel persze önmagában még nem sokra megyünk, de az SSL egy korábbi, BEAST nevű sérülékenységét kihasználva viszont vissza tudjuk fejteni a többi byte-ot is.

A titkosított adatok visszafejtéséhez tehát együtt kell használni a POODLE és a BEAST sebezhetőségeket. A jó hír az, hogy a BEAST hibát már 2006-ban, a TLS 1.1-es verziójában javították. A rossz hír viszont az, hogy a mai szerverek még mindig támogatják az elavult SSL 3.0-t. (A sorrend: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2)

Az SSL/TLS alkudozás problémája

Amikor két számítógép HTTPS kapcsolaton keresztül akar adatokat küldeni egymásnak, akkor kölcsönösen közlik egymással, hogy milyen titkosítási eljárásokat ismernek, vagyis hogy melyik az a legmagasabb SSL/TLS verzió, amit közösen használni tudnak. Viszont egy rossz megoldásnak köszönhetően, ha a kapcsolódást kezdeményező gépnek magasabb az SSL/TLS verziószáma, mint a másiknak, akkor a kapcsolat nem mindig jön létre, és ilyenkor a kapcsolódást kezdeményező gép nem tudja, hogy miért szakadt meg a kommunikáció. Ezt a problémát a mai böngészők úgy kerülik meg, hogy újra kapcsolódni próbálnak, és azt hazudják a másik gépnek, hogy egyel alacsonyabb számú verziót tudnak használni, mint amit az előbb mondtak. Mindezt addig ismétlik, amíg végre létre nem jön a kapcsolat.

Mivel még mindig vannak olyan aktív szerverek az interneten, amik az SSL 3.0-nál modernebb titkosítást nem ismernek, sokszor a biztonságosabb gépek is lebutítják a saját kapcsolatukat, hogy működjön a kommunikáció. Az SSL 3.0 pedig artalmazza a POODLE sebezhetőséget, így máris megvan a baj.

Az Opera intézkedései

Egyedi esetekben működhet az SSL 3.0 teljes tiltása, globálisan viszont nem jöhet szóba, mert ezzel az összes legfeljebb SSL 3.0 titkosítással rendelkező szerver elérhetetlenné válna. A következő logikus megoldás az lenne, hogy a böngésző a TLS 1.0-s verziója alá nem hazudná magát. Ezt ki is próbálták, de sok szervernél kapcsolódási problémát okozott, így elvetették. Létezik erre egy szabványos megoldás is, amit viszont még csak kevés szerver támogat, így jelenleg nem orvosolja a problémát. Az Opera a saját szerverein viszont már elvégezte a szükséges módosításokat.

A Windowsos, Maces, Linuxos és Androidos kiadásokban bevezettek egy technológiát, ami megakardályozza a POODLE támadást. Ez csak ideiglenes megoldást nyújt, de időt ad a szerverek üzemeltetőinek, hogy frissítsék a titkosítási eljárást a legmodernebb TLS szabványra. Ezzel együtt kikapcsolták a biztonsági plecsnit is az SSL 3.0-nál, így a böngésző címsorában ugyanaz az ikon fog megjelenni, mint a sima HTTP kapcsolat esetében.

Az iOS-es kiadás az Apple beépített megoldását használja, ezért ott az Apple-re kell várni a hiba javításához. A Mini egyáltalán nem érintett a problémában. A régi Opera esetében viszont meglépték az SSL 3.0 teljes tiltását, így a 12-es vagy annál régebbi verziót használók belefuthatnak elérhetetlen weboldalakba. A tiltás távoli eléréssel történt, nem adtak ki hozzá külön frissítést.

A teljes megoldás persze az SSL 3.0-s verziójának teljes kukázása lenne, de a fent említett problémák miatt erre még minimum néhány hónapot várni kell.

Opera 12.17

Az előző bejegyzésben megénekelt OpenSSL hiba miatt a régi Windowsos Opera kapott egy biztonsági frissítést. A hiba csak és kizárólag a Windowsos kiadás automatikus frissítőjét érintette, ezért a Maces és Linuxos kiadás nem frissül.

A hiba javítása közben találtak egy másik biztonsági rést is, ami viszont csak egy attól független Windowsos hibával együtt volt kihasználható, ráadásul még egy érvényes Opera tanúsítvány is kellett hozzá. Természetesen ezt is javították.

Az új verzió telepítése ajánlott!

A Heartbleed bug és az Opera

Bizonyára mindenki hallott már az OpenSSL szolgáltatás Heartbleed nevű sebezhetőségéről az elmúlt napokban. A technikai részletekbe nem megyünk bele. A hiba lényegét jól összefoglalja ez az xkcd comic strip.

Felmerül a kérdés, hogy az Opera böngésző milyen téren érintett. Átlagos felhasználók szempontjából a rövid válasz az, hogy sehogy. Ennél azonban kicsit részletesebb a jelentés, ami az Opera blogján jelent meg.

A régi Opera (Presto) használta ugyan az OpenSSL-t, de azt a modulját nem, amiben a sebezhetőség megjelent, így a Prestót használó programok (régi Opera, Mini, Mail) nem érintettek. Egyetlen kivétel van, a régi Opera automatikus frissítője, ami használta a hibás modult, viszont a program csak az Opera szervereihez csatlakozott, és több különböző azonosítást is használt, így a hiba kihasználása inkább csak elméleti lehetőség. Ennek ellenére valószínűleg lesz egy biztonsági frissítés a 12-tes verzióhoz.

Az új Opera (Chromium) asztali verziói nem használják az OpenSSL-t, így nem érintettek. Az Androidos és iOS-es verziók használják, de a régi Operához hasonlóan azt a modult nem, ami sebezhető, így szintén nem érintettek.

Összességében az Opera által gyártott böngészők nem sebezhetőek ezzel a hibával. Ez viszont nem vonatkozik a beépülőkre (pluginek). Azokkal kapcsolatban a gyártók (Adobe, Oracle, stb) az illetékesek.

Az Opera által nyújtott különböző webes szolgáltatások közül több is használta a hibás modult, de csak a beléptetés után, így a jelszavak ilyen szempontból biztonságban voltak. Azóta az Opera lecserélte a tanúsítványait. A külső féltől származó szolgáltatások esetében (blog, fórum) viszont az Opera nem tudja garantálni, hogy nem kerültek ki a jelszavak, ezért ezeken a helyeken érdemes cserélni.

süti beállítások módosítása