Hej Habr!
Hodiaŭ mi parolos pri tio, kion miaj kolegoj kaj mi faras jam de kelkaj monatoj: puŝaj sciigoj por poŝtelefonaj tujmesaĝiloj. Kiel mi jam diris, en nia aplikaĵo la ĉefa emfazo estas sur sekureco. Tial ni eksciis, ĉu puŝaj sciigoj havas "malfortajn punktojn" kaj, se jes, kiel ni povas ebenigi ilin por aldoni ĉi tiun utilan opcion al nia servo.
Mi publikigas tradukon de nia kun kelkaj etaj aldonoj de mi mem. Ĝi enhavas la rezultojn de la "enketo" kaj rakonton pri kiel la problemo estis solvita.
Ni ekzamenas la materialon
En la klasika modelo, puŝaj sciigoj igas mesaĝistojn vundeblaj al atakoj MITM (Homo-en-la-mezo). Ekzemple, kun Google, Microsoft, kaj la malnova versio de iMessage, la aplikaĵo sendas ĉifrajn ŝlosilojn al Apple-serviloj - sur la servilo, uzantoj estas aŭtentikigitaj kaj la mesaĝo-kapo (aŭ ĝia enhavo) estas deĉifrita.
Kiel rezulto, estas ŝanco legi la korespondadon akirante aliron al la puŝa sciiga servilo. Ĉi tio signifas, ke ĉiu ĉifrado de korespondado estas senutila: puŝaj sciigoj ankoraŭ lasos la eblecon esti legitaj de triaj partioj. La aŭtoroj de la artikolo diskutis ĉi tiun eblecon pli detale. en Xaker.ru, dediĉita al metodoj de ĉifrado de mesaĝoj.
Se vi pensas, ke la serviloj de Apple kaj Google estas 100% sekuraj kontraŭ likaj uzantaj ĉifradaj ŝlosiloj, konsideru la fakton, ke iliaj dungitoj havas aliron al ili. Kaj dungitoj estas homoj.
Malgraŭ ĉiuj vundeblecoj de puŝaj sciigoj, multaj "sekuraj" tujmesaĝiloj, inkluzive de Signal kaj Telegram, uzas ilin. Alie, uzantoj devos "mane" monitori novajn mesaĝojn konstante ensaluti en la aplikaĵon. Kio estas tre maloportuna, kaj konkurantaj mesaĝistoj ricevos avantaĝon.
Paranojo kaj komuna racio
En nia projekto, ni traktis ĉi tiun aferon proksime antaŭ pluraj monatoj. Ni bezonis aldoni puŝan sciigan opcion por esti konkurencivaj. Sed samtempe, ne malfermu sekurecan truon, ĉar ajna datumfluo subfosos fidon al la projekto.
Tamen ni jam havas gravan avantaĝon: nia mesaĝisto estas malcentralizita (datumoj estas stokitaj sur la blokĉeno), kaj dungitoj ne havas aliron al kontoj. Nur uzantoj havas ĉifrajn ŝlosilojn, kaj publikaj ŝlosiloj de interparolantoj estas disponeblaj sur la blokĉeno por protekti kontraŭ MITM-atakoj.
En la unua versio de puŝaj sciigoj, ni decidis ludi ĝin sekure kiel eble plej multe kaj tute ne transdoni la mesaĝan tekston. La puŝservo ne ricevis la tekston de la mesaĝo de la nodo, sed nur signalon pri la fakto de ĝia ricevo. Tial la uzanto vidis la sciigon "Nova mesaĝo alvenis". Eblis legi ĝin nur en la mesaĝisto.
.
Post tio, ni eksciis, ke la plej nova versio de sciigoj de Apple havas novajn sekurecajn funkciojn. Ili UNNotificationServiceExtension, kiu permesas al programistoj sendi plene ĉifritajn sciigajn datumojn per APNS. La apo sur la aparato de la finuzanto tiam elfaras la deĉifradon (aŭ elŝutas pliajn datumojn) kaj montras sciigon. Ni prenis ĝin kiel bazon por la dua versio de puŝaj sciigoj.
Ni nun evoluigis la duan version de puŝaj sciigoj por iOS, kiu ebligas al vi montri la tekston de la mesaĝo sen sekureca risko. En la nova koncepto, la logiko aspektas jene:
- La puŝservo sendas puŝan sciigon kun la transakcia numero (la ĉifrita mesaĝo povas esti tre granda, kaj la grandeco de sciigoj estas tre limigita)
- Kiam la aparato ricevas sciigon, ĝi lanĉas nian NotificationServiceExtension - mikroaplikaĵon, kiu petas transakcion de la nodo per identigilo, malĉifras ĝin per la konservita pasfrazo kaj sendas novan sciigon al la sistemo. La pasfrazo estas konservita en sekura stokado.
- La sistemo montras sciigon kun deĉifrita mesaĝo aŭ traduko.
- La ŝlosiloj ne iras ien, same kiel la simpla teksta mesaĝo. La puŝservo ne havas manieron deĉifri la mesaĝon.
Ni akceptis ĉi tiun version kiel funkcianta kaj efektivigis ĝin en la plej nova ĝisdatigo de la iOS-aplikaĵo.
Interesatoj pri la teknika flanko povas vidi la fontkodon: .
fonto: www.habr.com