Oled ilmselt kuulnud HTTPS-ist ja sellest, kuidas roheline tabalukk brauseris annab meile meelerahu. Rakenduste arendamise maailmas ei ole aga sertifikaadi kehtivuse pimesi usaldamine alati piisav. On varjatud oht, et isegi krüptitud ühenduse korral võib keegi salaja pealt kuulata, mis sinu seadme ja serveri vahel toimub.
Selle turvanõrkuse lahendamiseks on välja töötatud tehnika nimega sertifikaadi kinnitamine . Põhimõtteliselt ütleb see meie rakendusele: "Ärge usaldage suvalist sertifikaadiasutust; aktsepteerige ühendus ainult siis, kui server esitab täpselt selle sertifikaadi või avaliku võtme." See on nagu meie suhtluse ukse taha väga range väravavahi panemine.
Mis täpselt on SSL-i kinnitamine ja miks me seda vajame?
Selle õigeks mõistmiseks peame kõigepealt meeles pidama, et standardne HTTPS põhineb usaldusahelal . Serveriga ühenduse loomisel saadab see teile oma digitaalse sertifikaadi. Teie mobiilseade kontrollib, kas see dokument on allkirjastatud sertifitseerimisasutuse (CA) poolt, mida operatsioonisüsteem usaldab. Kui allkiri on kehtiv ja sertifikaat pole aegunud, luuakse ühendus.
Probleem tekib siis, kui ründajal õnnestub ühenduse keskele tungida – see on kurikuulus nn. „ Man-in-the-Middle“ (MITM) rünnak . Kui häkker saab sertifitseerimisasutuselt (CA) petturliku, kuid kehtiva sertifikaadi või kui tal õnnestub ohvri seadmesse installida pahatahtlik juursertifikaat, kiidab operatsioonisüsteem ühenduse heaks. Sel hetkel saab ründaja pealt kuulata ja muuta tundlikke andmeid, näiteks pangarekvisiite või paroole, ilma et kasutaja midagi ebatavalist märkaks.
Siin tulebki mängu kinnitamine. Rakendus ei usalda ühtegi tunnustatud sertifitseerimisasutust, vaid salvestab serveri sertifikaadi või avaliku võtme räsi koopia. Käepigistuse ajal võrdleb rakendus vastuvõetud sertifikaati salvestatud sertifikaadiga. Kui need ei ühti osahaaval, katkestatakse ühendus kohe, hoides ära serveri võltsimise.
Ankurdamise tüübid: sertifikaadid vs avalikud võtmed
Mitte kõiki kinnitusi ei tehta ühtemoodi. Sõltuvalt sellest, mida me otsustame "kinnitada", on meil kaks peamist lähenemisviisi. Esimene on sertifikaadi kinnitamine , kus salvestame kogu sertifikaadifaili (.pem või .der). See on kõige lihtsam rakendada, kuid kõige tüütum hooldada, kuna iga kord, kui serveri sertifikaat aegub ja seda uuendatakse, peame rakendust poes värskendama, vastasel juhul kaotavad kasutajad teenuse.
Teine võimalus on avaliku võtme kinnitamine . Sellisel juhul salvestame ainult sertifikaadi avaliku võtme räsi (tavaliselt SHA-256). Peamine eelis on see, et avalik võti jääb puutumata isegi sertifikaadi uuendamisel, mis annab meile suurema sertifikaadi paindlikkuse ja vähendab sunnitud rakenduste värskenduste sagedust. Lisaks on ainult räsi salvestamise tõttu kood puhtam ja seda on pöördprojekteerimisel raskem välja võtta.
Tehniline teostus erinevatel platvormidel
Kui me töötame koos AndroidKõige kaasaegsem viis on faili kasutamine network_security_config.xmlSelles XML-failis defineerime autoriseeritavate sertifikaatide (PIN-koodide) domeenid ja räsi, mis võimaldab meil Aktiveerige Androidis olulised turvaseaded natiivselt. Seejärel lingime selle faili lihtsalt AndroidManifest.xmlVarem tehti keerukamaid asju klassi ülekirjutamise teel. DefaultHttpClient ja Java sertifikaadihoidlate haldamine läbi keytoolXML-põhine konfiguratsioon on aga palju tõhusam.
aasta ökosüsteemis iOSAsjad muutuvad veidi. Saame rakenduse transpordi turvalisust (ATS) ära kasutada faili konfigureerides Info.plist ankurdatud domeenide määratlemiseks. Täieliku kontrolli saavutamiseks on aga tavaline rakendada käitusaja valideerimist, kasutades URLSessionDelegateAutentimise läbikutsumise meetodis ammutame serverist sertifikaadi ja võrdleme seda kohalik salvestatud sertifikaat rakenduste komplektis.
Neile, kes kasutavad Kondensaator- või hübriidraamistikudOn olemas pluginad nagu @capgo/capacitor-ssl-pinning mis protsessi ühtlustavad. Sellistel juhtudel tehakse konfigureerimine tavaliselt rakenduse konfiguratsioonifailis, määrates sertifikaatide loendi ja lubades valideerimise. Nende rakenduste testimine selliste tööriistadega nagu Charlesi puhverserver, simuleerides MITM-rünnakut, et kinnitada, et rakendus lükkab ühenduse tegelikult tagasi, kui sertifikaat ei ole oodatud.
Riskid, piirangud ja hooldus
Kinnitamine pole ainult ilus ja ilus. Suurim oht ​​on nn aegumislukustus . Kui serveri sertifikaat aegub ja te pole rakendust uue PIN-koodiga värskendanud, näevad kõik teie kasutajad ühenduse vigu. Selle katastroofi vältimiseks on parim tava rakendada varu-PIN-koode . Me salvestame teisese avaliku võtme räsi, mida kasutame ainult hädaolukorras või ootamatu vahetamise korral.
Teisest küljest võib kinnitamine olla peavalu arendajatele, kes peavad oma kommunikatsiooni siluma. Jälgimisvahendite toimimiseks on mõnikord vaja kinnitamine arenduskeskkondades keelata või luua spetsiaalsed silumisversioonid, tagades alati, et see funktsioon on lõppkasutajani jõudvas tootmisversioonis lubatud.
Veebi osas oli Chrome sarnaste kontseptsioonide rakendamisel teerajaja. See kasutab HSTS-i (HTTP Strict Transport Security), et tagada HTTPS-i kasutamine, ja haldab "eelinstallitud" saitide nimekirja, et vältida esimese kokkupuute haavatavust. Kuigi HPKP standard veebi jaoks eksisteeris, jäi see lõpuks kasutusest maha, kuna see oli liiga riskantne ja võis konfiguratsioonivea korral veebisaidid ligipääsmatuks muuta.
Sertifikaatide kinnitamise rakendamine on strateegiline otsus, mis tasakaalustab maksimaalse turvalisuse ja teenuse toimimise. Piirates usaldust kindlate üksustega, kaitseme suhtlust keerukate rünnakute eest, eeldusel, et säilitame oma võtmete ja sertifikaatide elutsükli üle range kontrolli, et vältida klientide juurdepääsuta jätmist.
