Mivel a macOS Big Sur megjelenésével egyidőben az Apple több szolgáltatása is akadozott, ez nem csak a telepítő letöltődésében okozott problémákat, hanem a már feltelepült rendszer esetén is jelentkeztek olyan problémák, hogy a külső fejlesztők alkalmazásai adott esetben lassan, vagy egyáltalán nem akartak elindulni. És noha erre például azonnali megoldást kínált, ha elvettük az internetkapcsolatot a géptől, ez nem tekinthető igazi megoldásnak.

Ha pedig ezek mellé hozzávesszük azt is, amit már a Little Snitch 5 megjelenéséről szóló cikkben is megemlítettünk, tehát hogy az új a System Extension API-t jelenleg kikerülik az operációs rendszer egyes saját folyamatai és alkalmazásai, és így ezeket sem nem tudja kijelezni a Little Snitch, sem nem tudjuk őket engedélyezni vagy letiltani, ez csak további kérdéseket és elméleteket szült. Ezek után kezdtek el megjelenni a médiában és a különféle oldalakon, YouTube csatornákon az arról szóló hírek és videók, hogy “a macOS Big Sur-rel és az új Mac-ekkel végleg megfigyeli minden lépésünket az Apple”, és hogy “minden app megnyitásánál elküld egy programazonosítót, hogy mikor indították azt el, valamint egy IP címet”. A legnagyobb port talán Jeffrey Paul beszédes, Your Computer Isn’t Yours (A számítógéped nem a tiéd) című bejegyzés kavarta, amire az egyébként kiváló szervizes, Louis Rossmann is ráugrott. És bár Jeffrey Paul közben többször is frissítette az írását, az sajnos még mindig több pontatlanságot tartalmaz, ahogy arra Jacopo Jannone rá is világít. Az alábbi cikkünk az ő blogposztján alapul. Nézzük, mit kell tudni erről a kérdésről!

TL;DR

Azok számára, akik nem szeretnék – bár érdemes! – végigolvasni az egész cikket, röviden összefoglalnánk, miről is van szó:

• Nem, a macOS nem küldi el az Apple-nek minden egyes app hash-ét azok minden egyes elindításakor.
• A macOS ugyan elküld információkat az adott app fejlesztői tanúsítványáról, de ezek nem alkalmasak arra, hogy bármi hasznos információra lehessen következtetni belőlük. Ezek az információk ugyanakkor titkosítás nélkül, egyszerű szövegként (plaintext) kerülnek elküldésre.
• Több szempontból sem érdemes blokkolni az elérést az ocsp.apple.com-hoz, tegyük ezt például a Little Snitch-csel vagy a hosts fájlunkkal.

Mi az az OCSP?

Az OCSP az Online Certificate Status Protocol betűszava. Ahogyan azt a név már maga jelzi is, ez arra szolgál, hogy ellenőrizni tudjuk egy tanúsítvány érvényességét anélkül, hogy le kellene töltenünk a visszavont tanúsítványok listáját, ami jellemzően elég nagy méretű, és ami miatt az ellenőrzés akkor jelentősen lassabb lenne. A macOS az OCSP használatával megbizonyosodik arról az adott app futtatása előtt, hogy az adott fejlesztő tanúsítványa érvényes-e – tehát nem került-e visszavonásra.

Ezt kapta fel Jeff Johnson is:

A fentiekben leírtak tehát azt jelentik, hogy ha a macOS nem képes csatlakozni az Apple OCSP szerveréhez, akkor egyszerűen kihagyja a tanúsítvány ellenőrzését, és elindítja az appot, ami gyakorlatilag egy fail-open típusú megoldás.

A macOS Big Sur megjelenésekor azonban az Apple OCSP szervere elérhető volt, viszont extrém módon lelassult az elérése, ezzel megakadályozva a soft fail-t, és hogy így a macOS átugorja a tanúsítvány ellenőrzését, ami az alkalmazások lassú megnyitását és így az egész rendszer lassú működését eredményezte.

Az tehát világos, hogy ez az ellenőrzési mechanizmus megköveteli a macOS-től, hogy felvegye a kapcsolatot az Apple szerverével még azelőtt, hogy az appot elindítaná. Ez az ellenőrzés már a macOS Mojave esetén is megvolt, tehát igazából nem új dolog, de az Apple-nek a macOS Big Sur megjelenésével egyidejűleg jelentkező szerverproblémái hirtelen nagy nyilvánosság előtt mutatták meg, hogy problémás megoldás lehet, illetve adatvédelmi aggályokat is felvetettek egyesek részéről.

Ezek közül a leginkább Jeffrey Paul írása lett kifejezetten népszerű Twitteren, amiben azt állítja, hogy:

It turns out that in the current version of the macOS, the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it.

Mint az kiderült, a macOS jelenlegi verziója elküldi az Apple-nek minden egyes alkalmazás hash-ét, azok minden egyes indításakor.

Ha ez valóban így lenne, az tényleg meredek lenne. Persze nincs így, de erről részletesebben egy kicsit később.

Hogy a helyzet még rosszabb legyen, az OCSP esetén megszokott a HTTP használata – és ez a jó öreg, plaintext HTTP a 80-as porton keresztül, nem pedig a titkosítással is rendelkező HTTPS. Ennek persze jó oka van, ami rögtön világossá válik, ha az OCSP-t webböngészőkkel használjuk: mégpedig az ellenőrzési hurkok megelőzése. Ha ugyanis HTTPS-t használtunk arra, hogy az OCSP-n keresztül ellenőrizzünk egy tanúsítványt, akkor ellenőrizni kellene azt a tanúsítványt is, amit a HTTPS kapcsolat felépítéséhez használtunk, amihez akkor egy újabb HTTPS kapcsolat kellene, amit ismét ellenőrizni kellene… És akkor szépen bele is futottunk egy végtelen ellenőrzési hurokba.

És noha az OCSP nem teszi kötelezővé a titkosítást, mégis megköveteli, hogy az általa visszaküldött válaszokat a szerver aláírja. Ez persze nem küszöböli ki az eredeti aggodalmat, hogy bárki, aki a hálózatunkra csatlakozik, a forgalom megfigyelésével képes lehet “lehallgatni”, hogy melyik appokat indítottuk el, és mikor.

Mélyebbre ásva

Most, hogy már tudunk egy keveset az OCSP működéséről, még több kérdés merül fel. Ha az OCSP a tanúsítványok ellenőrzésére szolgál, akkor miért küldené el az általunk futtatott appok hash-ét? Komolyan minden egyes alkalmazás esetén hash-eket számol a macOS minden egyes indításukkor? Mi a helyzet az igazán nagy méretű appokkal? Minél nagyobb méretű ugyanis valami, annál hosszabb időt vesz igénybe a hash kiszámítása – lehetséges lenne, hogy ez a jelentősen hosszabb idő senkinek nem tűnt volna fel? Talán a hash-t csak egyszer, például az adott app legelső indításakor számolja ki a rendszer, és valahol eltárolja. Ez a sok kérdés tehát további kutatást igényel.

Egy OCSP lekérdezést elég egyszerűen el tudunk csípni, egyszerűen létre kell hozni egy HTTP proxy-t – vagy ami még egyszerűbb, elindítani a Wiresharkot. Mivel mindez a sima HTTP-n keresztül megy, tehát nem HTTPS-en, így nincs titkosítás, nincsenek tanúsítványok, és egyéb problémák.

Egy OCSP lekérdezés a következőképpen néz ki, amit például a Firefox elindításakor küld el a rendszer:

GET /ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e%2Fba
LCFIU0u76%2BMSmlkPCpsBBRXF%2B2iz9x8mKEQ4Py%2Bhy0s8uMXVAIIBseUIWx6
qTA%3D HTTP/1.1
Host: ocsp.apple.com
Accept: */*
User-Agent: com.apple.trustd/2.0
Accept-Language: it-it
Accept-Encoding: gzip, deflate
Connection: keep-alive

Itt érdemes kiemelni azt, hogy az app bezárása majd újbóli elindítása után a rendszer nem küldött újabb lekérdezést. Ez egyben észszerű is, és azt jelzi, hogy a tanúsítványok érvényességét a rendszer nem ellenőrzi minden indításukkor, hanem csak bizonyos idő eltelte után.

Ez a lekérdezés egy egyszerű GET, amiben base64-es kódolású string formájában található maga a payload. A tényleges adatokat tehát könnyen kinyerhetjük, ha dekódoljuk ezt a stringet:

echo 'ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e/baLCFIU0u76+MSml
kPCpsBBRXF+2iz9x8mKEQ4Py+hy0s8uMXVAIIBseUIWx6qTA=' | base64
--decode > output.bin

Ezzel egy 80 bájt hosszú payloadot kapunk, ami nem úgy néz ki, mint bármi hash. Ebből az OpenSSL segítségével szedhetjük ki olvasható formában az adatokat.

openssl ocsp -text -reqin output.bin

Ami után az alábbiakat kapjuk:

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6C
Issuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754
Serial Number: 06C794216C7AA930

Hoppá, itt már van hash? Akkor most lebukott a dolog? Nem. Itt az Issuer Name Hash és az Issuer Key Hash szerepel, amelyekről kicsit később lesz szó bővebben is, és abból az is egyértelműen látszik majd, hogy ezek minden esetben ugyanazok, függetlenül attól, hogy melyik alkalmazást indítottuk el.

A macOS-ben található trustd daemon tehát nem küldi el minden egyes app hash-ét azok indításakor. Ehelyett csak egy tanúsítványról küld információt, ami igazából várható is volt azután, hogy megértettük, mire is szolgál az OCSP.

De ez így most még nem válaszolta meg a kérdést egyértelműen. Hiszen ha egyszer minden app egyedi tanúsítvánnyal rendelkezik, akkor még mindig létre lehetne hozni egy táblázatot, amely párosítja az adott sorozatszámokat az egyes appokkal, és így továbbra is fennállna az adatvédelmi aggály. De akkor most nézzük meg, hogy tényleg ez-e a helyzet.

A fejlesztői tanúsítványok…

Az ebben a cikkben példaként bemutatott információk a Firefox app tanúsítványából származnak, és a kibontásukhoz az Apple codesign eszközét tudjuk használni. Ehhez az alábbi parancsot kell lefuttatnunk:

codesign -d --extract-certificates /Applications/Firefox.app

Ez a parancs több fájlt is eredményez, codesign0, codesign1, stb. Ezek közül az első az úgynevezett leaf certificate (“a bizalmi fa levéleleme”), míg a többi pedig a bizalmi lánc eleme egészen a gyökértanúsítványig. Ezekből tehát akkor a codesign0 az, ami nekünk kell, és ismét az OpenSSL segítségével tudjuk kibontani belőle az információkat:

openssl x509 -inform der -in codesign0 -text

Ezt lefuttatva az alábbiakat kapjuk vissza:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 488521955867797808 (0x6c794216c7aa930)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Developer ID Certification Authority, OU=Apple
Certification Authority, O=Apple Inc., C=US
Validity
Not Before: May 8 19:08:58 2017 GMT
Not After : May 9 19:08:58 2022 GMT
Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla
Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation,
C=US...

Itt is találunk egy sorozatszámot. Emlékszünk még az OCSP lekérdezésből kibontott payloadban lévő sorozatszámra? Ha összehasonlítjuk a kettőt, láthatjuk, hogy ezek egyeznek, ami pedig bizonyítja, hogy az OCSP lekérdezéskor nem az alkalmazások hash-ét küldi el a rendszer, hanem a fejlesztői tanúsítvánnyal kapcsolatos információkat. (A sorozatszámok esetén hexadecimális számról van szó, így a második esetén az elején lévő “0x” prefix ezt jelzi, illetve itt igazából hiányzik egy nulla az elejéről a 0x után, de az meg azért nem lett kiírva, mert az az úgynevezett leading 0, ami miatt például a 16-ot sem írjuk 016-ként. A hash-eket, amelyek sem nem “számok”, sem nem mennyiségek jellemzésére valók a szó szoros értelmében, hexadecimális kiíráskor általában ki szokták írni az összes lehetséges helyiértékre, hogy mindig ugyanolyan hosszú helyet foglaljanak el, mert ez a kódban való kezelésüket leegyszerűsíti.)

A fenti információk alapján pedig az is világosan látható, hogy mit jelent az OCSP lekérdezésben az Issuer Name Hash és az Issuer Key Hash, és hogy ezek miért azonosak minden lekérdezés esetén: a kulcsszó itt az “Issuer”, azaz a tanúsítvány kibocsátója. Mivel ezeket a tanúsítványokat az Apple biztosítja a fejlesztők számára, ezért a tanúsítványok kibocsátója is az Apple, és ezért az adott hash minden egyes esetben az Apple adatait tartalmazza a certificate name és certificate key esetén.

…amelyek nem is egyediek minden egyes app esetén

Szintén érdemes kiemelni, hogy egy fejlesztő az esetek döntő többségében ugyanazzal a tanúsítványával írja alá az összes alkalmazását, tehát ugyanaz a tanúsítvány lesz benne az összes alkalmazásában. Ezt persze nem kell csak így “bemondásra” elhinni, hiszen bárki ellenőrizheti saját maga is. Ebben a példában akkor vegyük elő a Firefoxot fejlesztő Mozilla egy másik appját, a Thunderbirdöt.

Ehhez az alábbi parancsokat kell lefuttatnunk:

codesign -d --extract-certificates /Applications/Thunderbird.app
openssl x509 -inform der -in codesign0 -text

Erre az alábbiakat kapjuk vissza eredményül:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 488521955867797808 (0x6c794216c7aa930)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Developer ID Certification Authority, OU=Apple
Certification Authority, O=Apple Inc., C=US
Validity
Not Before: May 8 19:08:58 2017 GMT
Not After : May 9 19:08:58 2022 GMT
Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla
Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation,
C=US...

Ez pedig pontosan ugyanaz a tanúsítvány, amit a Firefox esetén már láthattunk – ami nyilvánvalóan nem meglepő, hiszen a fejlesztőjük ugyanaz. Így aztán Jeffrey Paul alábbi, és a médiában sokak által átvett megállapításai nem pontosak, amikor azt írja, hogy a macOS az adott alkalmazás egyedi azonosítóját küldené el:

The OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it.

[An IP address] allows for a table that has the following headings: Date, Time, Computer, ISP, City, State, Application Hash

[This means that Apple knows] what apps you open there, and how often. They know when you open Premiere over at a friend’s house on their Wi-Fi, and they know when you open Tor Browser in a hotel on a trip to another city.

És noha a rendszer elküld bizonyos adatokat, itt tehát mégsem arról van szó, hogy a macOS Big Sur-rel és az új Mac-ekkel végleg megfigyelné minden lépésünket az Apple, hiszen nem azt teszi, hanem az abban található tanúsítványt ellenőrzi vissza, ami egy adott fejlesztő összes alkalmazása esetén azonos. Ez pedig az adatvédelmi aggályok szempontjából azonnal más környezetbe helyezi az egészet.

Notarization – pár szó az alkalmazások hitelesítéséről

Van olyan helyzet, amikor a macOS valóban elküldi egy adott futtatható fájl hash-ét, és valószínűleg ez okozhatott némi félreértést az egész kapcsán. Ez pedig az az eset, amikor a Gatekeeper ellenőrzi az adott alkalmazás legelső indításakor, hogy az Apple szerverein megtalálható-e a hitelesítési ticket, ha az nincs csatolva magában az alkalmazásban.

Ennek viszont semmi köze nincs az OCSP-hez. Ez csak bizonyos esetekben fordul elő, és a rendszer mindezt biztonságos (HTTPS) kapcsolaton keresztül kérdezi le az  -on keresztül, és erről közben természetesen egy előugró ablak is tájékoztatja a felhasználót.

Lehet-e illetve érdemes-e blokkolni az OCSP elérését?

Ahogyan az már a cikk elején megtalálható tweetből is látszik, az Apple OCSP szerveréhez való hozzáférést természetesen blokkolni tudjuk, amihez használhatjuk akár a Little Snitch-et, vagy pedig hozzáadhatjuk a hosts fájlunkhoz, elküldve localhostra.

És hogy érdemes-e letiltani? A fentieket végigolvasva láthatjuk, hogy az OCSP elérését letiltva egy fontos biztonsági funkció működését akadályozzuk meg.

Persze ha valaki a fentiek után is úgy gondolja, hogy az OCSP-vel az Apple belegázol a privát szférájába, és inkább lehetőséget ad a letiltással az esetleges kártékony alkalmazások működésére, lelke rajta.

Az Apple egyébként már változtatott a folyamaton, és már nem loggolja a szerver a lekérdezéskor a felhasználó gépének IP-címét, illetve a korábban begyűjtött IP-címeket is törlik a logokból. Ezeken túl pedig a jövő év során(!) az alábbi változásokat eszközlik majd a biztonsági ellenőrzésekhez:

• Egy új, titkosított protokoll a fejlesztői tanúsítványok érvényességének ellenőrzéséhez
• Szerverhibák elleni védelem
• Opció a felhasználók számára a biztonsági funkciók kikapcsolására

Az alkalmazások biztonságos megnyitásáról és azok ellenőrzéséről további információk olvashatóak ebben a támogatási szócikkben – de az adatvédelemmel kapcsolatos bekezdés egyelőre csak az angol nyelvű változatban van benne, a magyarban nem: Alkalmazások biztonságos megnyitása Mac számítógépen.