Lépéseket foganatosított a Mozilla a MITM tanúsítványokat kibocsátó hitelesítésszolgáltatókkal szemben

Mozilla

Nemrég nagy port kavart security körökben az a hír, hogy a Trustwave hitelesítésszolgáltató (CA) "subordinate root" tanúsítványt adott egy meg nem nevezett privát vállalatnak azért, hogy a vállalat azzal monitorozhassa a helyi hálózatából eredő SSL titkosított hálózati forgalmakat. A Trustwave saját maga vallotta be blogjában, hogy MITM lehallgatásra/forgalommonitorozásra alkalmas tanúsítványt bocsátott ki egy vállalatnak, amely - a cég szerint - nem kormányzati szerv, nem internetszolgáltató és nem törvény-végrehajtási szervezet. A hitelesítésszolgáltató szerint a tanúsítványt kizárólag belső hálózaton használták egy adatszivárgás elleni védelmet (data loss prevention - DLP) megvalósító rendszerben. A Trustwave állítja, hogy körültekintő hálózati, fizikai biztonsági stb. auditálás után adta át a tanúsítványt a vállalatnak egy olyan Hardware Security Module-ban (HSM) tárolva, amelyből a tanúsítványt a behelyezés után elvileg lehetetlen kinyerni.

A Trustwave azóta visszavonta a tanúsítványt és azt közölte, hogy a jövőben nem ad ki ilyen tanúsítványt többé. A hitelesítésszolgáltató azt állította, hogy összesen egyetlen alkalommal adott ki ilyen tanúsítványt.

A Mozilla Foundation egy levelet írt nemrég az összes, a Mozilla root programban résztvevő hitelesítésszolgáltatónak. Az alapítvány levelében felvázolja, hogy mit vár el a hitelesítésszolgáltatóktól. A Mozilla álláspontja szerint elfogadhatatlan az, hogy subordinate CA tanúsítványokat adjanak ki hitelesítésszolgáltatók azzal a céllal, hogy azzal valaki MITM SSL lehallgatást/forgalommonitorozást végezzen. A Mozilla szerint akkor is elfogadhatatlan, ha az effajta forgalomlehallgatás zárt, belső hálózatra korlátozódik.

A Mozilla az elvárásigénye mellett követelményeket is támaszt a root programjában részt vevő CA-kel szemben. A Mozilla azt akarja, hogy az összes ilyen tanúsítványt vonják vissza, illetve az összes, tárolásukra használt HSM-et semmisítsék meg. A határidő, amit az alapítvány megszabott: minél előbb, nem nem később mint 2012. április 27.

A Mozilla 2012. március 2-ig adott határidőt a CA-knek arra, hogy az általa kért információkat megadják.

A Mozilla kiemelte, hogy saját belátása szerint dönti el, hogy ki vehet részt a root programjában és meg fog tenni minden lépést a felhasználóinak biztonsága érdekében. Ebbe beletartozik az is, hogy szükség szerint eltávolítja a helytelen root tanúsítványokat és azokat a root CA-kat is, amelyek ezeket a tanúsítványokat kibocsátották.

Sebastian Wiesinger hibabejelentése a problémáról itt. További részletek itt.

( 4fonya | 2012. 02. 20., h – 15:01 )

Egy elírás: "ki vezet részt a root programjában"
Gondolom "ki vehet" akart lenni. :-)

Íme az intézményesített lehallgatás. Csak a Mozilla-nak fáj, másnak nem?

Az aggasztó ez:

"Trustwave defended itself by saying that the issuing of subordinate roots to private companies, so they can inspect the SSL-encrypted traffic that passes through their networks, is a common practice in the industry."

Kíváncsi leszek hány CA áll elő a farbával és vallja be, hogy ilyet tett.

--
trey @ gépház

Ez valóban aggasztó több szempontból is.
Pl. az internetes fizetések többnyire SSL-en keresztül mennek. Azaz ha "kitudódik", hogy valamelyik cég kapott ilyen MITM tanúsítványt, akkor attól kezdve elég az illető cég megfelelő gépeit támadni az on-line fizetések monitorozásához.

Ezért rossz a Chrome megközelítése a saját tanúsítványokhoz, miszerint nem tudod az általad leellenőrzött tanúsítványt eltárolni, hogy legközelebb lássad, hogy stimmel-e az újjlenyomat és jelezzen a böngésző ha nem stimmel - hanem ez helyett minden egyes alkalommal tovább gombot kell nyomnod - attól függetlenül hogy ugyanazzal a domain-hez tartozó cert-tel lett-e az adatfolyam titkosítva vagy nem.

És éppen ez miatt duplán rosszabbul járhatnak a Chrome böngészővel saját tanúsítványt használók:

1) Sosem látszik hogy az ujjlenyomat ugyanaz-e - minden alkalommal ellenőrizni kellene manuálisan

2) Ha kiderül hogy a root CA-t komprommitálják, akkor a semminél azért mégiscsak nagyobb a veszélye, hogy az általam nekik kiadott személyes adataim vagy cég adatai illetéktelenek kezébe kerülnek - és mindezt miért? Mert a szerveremhez akarok kapcsolódni összesen 2 vagy 3 userrel, akiknek a gépén beállíthatnám és ellenőrizhetném a cert-et - ez helyett másik böngészőt kell használni, ami meg sokkal lassabb.

A G direkt csinálja ezt? Azért hogy elősegítse hitelesített cert-ek vásárlását? Nem lennék meglepve.

Igen, sajnos nem működik. Több fajta Linux-on is próbáltam (illtve WindXP-ken). Sőt, 17.x-es Chrome-ot használok, van GUI-s Cert management rész is már benne, de az sem működik.

Ide is írtam, de ahogy látom, nem igazán sikerült megoldani a fórumozóknak. Te használsz Linux vagy Windows alatt Chrome-mal saját magad által generált cert-et, amit fel is tudtál venni Chrome-ba és meg is jegyezte, vagyis nem dob figyelmeztető oldalt az oldaladra visszalépéskor?

Régen biztosan működött. Most Fedora 16-on, Google Chrome 17.0.963.46 verziójában lévő beépített cert kezelőt használva hozzáadtam a helyi certem és az is jól működik. Nem dob figyelmeztető ablakot, de persze felül áthúzva marad a https, mert a localhostot írtam alá :)

Rákattintva a lakatra:
The identity of the server you are connected to cannot be fully validated. You are connected to a server using a name only valid within your network, which an external certificate authority has no way to validate ownership of. As some certificate authorities will issue certificates for these names regardless, there is no way to ensure you are connected to the intended website and not an attacker."

Az oldal alatt levo drupal kiemelten kezeli azokat a temakat, amihez hozzaszolt. Igy o a http://hup.hu/user/8663/track oldalon lathatja, hogy hozzaszolt-e valaki ezekhez.
Az a szokas, hogy ha valakinek epp nincs hozzafuznivaloja egy temahoz, de erdekli, akkor beir egy "sibscribe/feliratkozas/stb.." tartalmu kommentet (igazabol drupal hianyossag).

--
I have come to the conclusion, that the matrix must have some bad bullet lag.

Az a baj, hogy trey ellene van mindennek, ami nem a core drupalhoz kotodik. Ennek alapvetoen tobb oka van:
- az oldal jelenleg 5-os Drupallal megy, amiben meg mas szinu manok hordjak a biteket, mint az ujabb Drupalokban (magyarul totalisan maskepp mukodik)
- Raadasul mar eleg regota unsupported, vagyis ami modulok vannak hozza, azokat mar joreszt nem fejlesztik, hibajavitas 0
- Lehetne frissiteni, csak ez mar tul nagy site. Csak az export tomentelen ido, a konverzioba mar bele se akarok menni. Raadasul ugye most csak 2x lehet upgradelni, 1x D6-ra, egyszer D7-re, ugyanis direkt irany (D5-D7) nincs, es nem is lesz
- Es vegul, van egy olyan modul az oldalban, ami egyszeri keresre lett kifejlesztve, nem kozossegileg tamogatott, es nincs jelenleg eroforras portolni.

Szoval, itt csak akkor lesz erdemi valtozas, ha valaki teljes egeszeben felvallalja az oldal frissiteset, a modul es a smink portolasat, es az oldal Drupal reszenek teljes koru tamogatasat, lehetoleg garanciakkal. Es meg akkor is meg kell gyozni Trey-t, hogy van ertelme a dolognak.
-- 

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

( Oneill | 2012. 02. 20., h – 21:49 )

Vannak erre jo kis toolok, vállalati környezetbe:
http://www.mcafee.com/us/products/web-gateway.aspx
Domain policy felteszi a gépedre a "root" tanusítványát a gatewaynek és minden forgalmad látható rajta...
Mozilla/Chrome kiszurja mert nem a Windows Certificate storeját használja... IE usereknek nincs szerencséje.

Aggasztó inkább hogy azok a userek akiknek a biztonság az ha "a címsorban zöld a lakat" teljesen ki van szolgáltatva.

Izé... ezzel nem lehet megakadályozni az érzékeny adatok kiszivárgását... egy hangyányit nehezebbé lehet tenni, de megakadályozni nem... ebből következően hamis biztonságérzetet ad, s ha ki akarnak szivárogtatni érzékeny adatokat, akkor ki fogják szivárogtatni némi szteganográfiával vagy bármi olyan titkosítással, amely akár évekig fel se tűnik, mert nem ismernek és/vagy keresnek olyan mintákat, amelyekkel adatokat juttatnak ki. Persze elkapnak pár balfácánt, akiknek eszük ágában se volt információkat szivárogtatni, és a valódi "bűnösök" meg röhögnek a markukba...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Olvastam. Ha védeni szeretnénk a szenzitív adatokat, akkor nem engedünk se http-t, se https-t, befelé-kifelé durva motozás, mobiltelefon és minden egyéb személyes cucc a bejáratnál leadva, cég által adott munkaruhába átöltözés, ésatöbbi. Ha ez utóbbiak nincsenek meg, akkor teljesen felesleges a https-t bontogatni és belenézegetni, ha pedig ezek már megvannak, akkor úgy sincs elérhető net.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

+1
Ha korlátozni akarják az internetelérést, akkor tegyenek be proxy-t! Ha az alkalmazott bevihet magával telefont, vagy pendrive-ot, a proxy sem ér semmit, de legalább ki lehet szűrni a warezolást.
A MITM nem akadályoz meg semmit, csak a munkatársak elleni kémkedésre, megfigyelésre, adatgyűjtésre jó. Illetve gyakorlatilag tönkreteszi az egész SSL infrastruktúrát, mert a MITM támadást végző szervert teszi az adathalászok célpontjává, ami nyilvánvalóan sokkal sebezhetőbb, mint egy egyszerű SSL kapcsolat. (Ld. még RSA-hoz való betörés social engineering módszerrel.)

Azért ezek elég gyenge ellenérvek.

Az egyik, hogy azt kifogásolják, hogy a blogbejegyzés nem említi a Facebookot, ami szintén hasonló technikákat alkalmaz, és emögött máris egy összeesküvés-elméletet sejtenek, mivel a Facebook és a Microsoft partnerek. Csakhogy egyrészt az IE team blogja korántsem a Microsoft hivatalos álláspontja, másrészt a blogbejegyzés egyáltalán nem említi a Facebookot, azaz senki nem mondta, hogy a Facebooknak szabad, amit a Google-nek nem.

A másik, hogy a P3P-t outdated, senki által nem fejlesztett technológiának állítják be. Ez igaz is, de nem jogosíthat fel senkit arra, hogy hibás használatával szándékosan vezesse félre azokat a webbögészőket, amik támogatják.

A harmadik, hogy a mai webes technológiák nem működhetnének, ha a P3P miatt szigorúbban kezelnék a böngészők a cookie-kat. Mivel a böngésző beállításain múlik, hogy a P3P header alapján végül elfogadhatónak tekinti-e a cookiekat, ezért ez nem lehet probléma. Egyszerűen az alapértelmezett beállításokat kell gyengíteni, vagy megkérni a usert, hogy gyengítsen a beállításain, de el kell fogadni, hogy vannak felhasználók, akik szigorúbb beállításokat alkalmaznak.

A probléma az, hogy az IE team kipécézte magának a Google-t, miközben nem csak a Facebook állítja, hogy a P3P elavult, hanem egy felmérés szerint oldalak tízezres nagyságrendben hagyják figyelmen kívül, mert nem felel meg a modern web követelményeinek. Még az a Facebook is elhajtotta őket a halál faszára, akibe a Microsoft 2007-ben befektetett.

Érdekességként:

A 2010 research paper by Carnegie Mellon found that 11,176 of 33,139 websites were not issuing valid P3P policies as requested by Microsoft.

In the research paper, among the websites that were most frequently providing different code to that requested by Microsoft: Microsoft’s own live.com and msn.com websites.

A Microsoft pisálhat a széllel szemben, de nem hiszem, hogy érdemes. Ajánlások, szabványok leszarásáról beszélni a Microsoft-nak több mint vicces, főleg az IE-vel kapcsolatban.

Neki kell állni és elolvasni a reakciókat, nem csak azt, ami a Microsoft blogjában van.

--
trey @ gépház

"A probléma az, hogy az IE team kipécézte magának a Google-t"

második bekezdés

"miközben nem csak a Facebook állítja, hogy a P3P elavult, hanem egy felmérés szerint oldalak tízezres nagyságrendben hagyják figyelmen kívül, mert nem felel meg a modern web követelményeinek"

negyedik bekezdés

"A Microsoft pisálhat a széllel szemben, de nem hiszem, hogy érdemes. Ajánlások, szabványok leszarásáról beszélni a Microsoft-nak több mint vicces, főleg az IE-vel kapcsolatban."

Az, hogy a múltban az IE nem állt a szabványok támogatásában a helyzet magaslatán, egyáltalán nem releváns. Illetve még ha releváns is lenne, a Microsoft beismerte már korábban, hogy rossz volt a hozzáállásuk, és belátták, hogy a szabványok támogatása nekik is érdekük.

"Neki kell állni és elolvasni a reakciókat, nem csak azt, ami a Microsoft blogjában van."

elolvastam

"Az, hogy a múltban az IE nem állt a szabványok támogatásában a helyzet magaslatán"
Te, miota vagy MS berenc? Az IE most sem all a szabvanyok tamogatasaban a helyzet magaslatan. Meg mindig duhong az IE.css, meg mindig egy csomo ganyolas van a JS korul, ha nem valami frameworkot hasznalsz, ugyhogy ne kezdjunk el azon vitatkozni, hogy ki es mennyire tamogatja a szabvanyokat.
Bevallottak, szep-szep. En is bevallom neked, hogy evek ota bliccelek, de belatom, hogy nekem is erdekem lenne a jegyvasarlas. Es? Ettol mas lett a vilag? Nem. Attol lesz mas, ha vegre kezzelfoghato eredmenyei is lesznek a szanom-banomnak, addig csak kirakatpolitika. Esetemben ez a jegyvasarlas, a MS eseteben pedig az olyan IE piacradobasa, ami teljes mertekben kompatibilis a szabvanyokkal, es akkor valt kompatibilitasi modba, ha valami korabbi IE hackre utalo nyomot erzekel. Addig csak ures locsogas.

Aztan, #define nem mukodhetnenek. Ha a bongeszok helyesen kezelnek a sutiket, akkor masfajta megoldast kellene bizonyos dolgokra hasznalni, ennyi. No persze, ehhez mar esz is kene.
-- 

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

( egeresz | 2012. 02. 21., k – 16:30 )

Valami nem stimmel.

Ahhoz, hogy egy cég a saját belső hálózatából induló SSL kapcsolatokat kibontsa és beleolvasson, nem szükséges világszerte elfogadott root cert. Elég a sajátja, amit megetet a saját munkaállomásaival.

Itt viszont egy világszerte elfogadott aláíró certről van szó. Ez csak abban az esetben kellhet a cégnek, ha az általa nem felügyelt munkaállomások SSL forgalmát is monitorozni akarja. Vagyis sántít a "A hitelesítésszolgáltató szerint a tanúsítványt kizárólag belső hálózaton használták"

Kiemelném az alábbi mondatokat: "nem kormányzati szerv, nem internetszolgáltató és nem törvény-végrehajtási szervezet"
Vagyis az teljesen rendben van, hogy a kormányzati szervek, internetszolgáltatók és törvény-végrehajtási szervezetek bontogassák az SSL kapcsolatokat. Jó kis gondolat.

Ebbol a torveny-vegrehajtasi szervekkel egyetertek, bar nyilvan visszaelesekre ad lehetoseget, viszont a terrorizmus elleni harc miatt nagyon hasznos is lehet egy ilyen. A kormanyzati szerveknek csak akkor engednem meg, ha igazsagugyi vagy hasonlo celbol vennek igenybe, az internetszolgaltatok meg ne akarjanak ilyet csinalni.
-- 

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

viszont a terrorizmus elleni harc miatt nagyon hasznos is lehet egy ilyen

az értelmes terrorista és bármi értelmes nagystílű bűnöző saját CA-t, kliens certet (vagy PGP-t) használ, ezeket pont nem fogja meg a kormányzati hallgatózás.

A kormányzati hallgatózás alkalmas a kisstílűek megfogására, és a plebs széleskörű automatizált megfigyelésére.

Nem mondom, lehet bűncselekményekre utaló jeleket találni széleskörű, automatizált megfigyeléssel, de ez inkább a CÉG saját működésének fontosságát erősíti.