A Secure Sockets Layer (SSL)—jelenleg technikailag Transport Layer Security(TLS) néven ismert-közös építőelem az ügyfelek és szerverek közötti titkosított kommunikációhoz. Lehetséges, hogyegy alkalmazás helytelenül használja az SSL-t, hogy a rosszindulatú entitások esetleg képesek legyenek elfogni egy alkalmazás adatait a hálózaton keresztül., Annak biztosítása érdekében, hogy ez ne történjen megalkalmazásában, ez a cikk kiemeli a biztonságos hálózati protokollok használatakor felmerülő általános buktatókat, és foglalkozik a nyilvános kulcsú infrastruktúra (PKI) használatával kapcsolatos néhány nagyobb aggodalommal.
el kell olvasnia az AndroidSecurity áttekintést, valamint a PermissionsOverview-t is.
fogalmak
egy tipikus SSL-Felhasználási forgatókönyvben a kiszolgáló konfigurálva van egy apublic kulcsot tartalmazó tanúsítvánnyal, valamint egy megfelelő privát kulccsal., Az SSL ügyfél és a szerver közötti kézfogás részeként a szerver bizonyítja, hogy rendelkezik a privát kulccsal, ha tanúsítványát nyilvános kulcsú kriptográfiával írja alá.
azonban bárki létrehozhat saját tanúsítványt és privát kulcsot, így egy egyszerű handshakedoesn nem bizonyít semmit a szerverről, kivéve, hogy a szerver ismeri a privát kulcsot, amely megfelel a tanúsítvány nyilvános kulcsának. A probléma megoldásának egyik módja az ügyfél rendelkezikvan egy vagy több tanúsítványkészlete, amelyben bízik. Ha a tanúsítvány nincs a készletben, akkor aszerver nem megbízható.,
ennek az egyszerű megközelítésnek számos hátránya van. A szervereknek képesnek kell lenniük arra, hogy idővel erősebb kulcsokra váltsanak (“kulcsforgatás”), amelyek a nyilvános kulcsot helyettesítikegy új. Sajnos most az ügyfélalkalmazást frissíteni kell, mi miatt lényegében a szerver konfigurációs módosítása. Ez különösen problematikus, ha a kiszolgáló nem az alkalmazásfejlesztő irányítása alatt áll, például ha harmadik fél webszolgáltatása. Thisapproach is problémái vannak, ha az alkalmazás beszélni önkényes szerverek, mint például a böngésző oremail app.,
ezeknek a hátrányoknak a kezelése érdekében a kiszolgálók jellemzően a Certificate Authorities (CAs) nevű jól ismert kibocsátóktól származó tanúsítványokkal vannak konfigurálva.A host platform általában tartalmaz egy listát a jól ismert CAs, hogy trusts.As az Android 4.2 (Jelly Bean) közül az Android jelenleg több mint 100 CAs-t tartalmaz, amelyek frissítésre kerülnekminden kiadásban. A kiszolgálóhoz hasonlóan a CA tanúsítvánnyal és privát kulccsal is rendelkezik. A kiszolgáló tanúsítványának kiadásakor a CA aláírjaa kiszolgáló tanúsítványa a saját kulcsával. Theclient ezután ellenőrizheti, hogy a szerver rendelkezik-e a platform által ismert CA által kiadott tanúsítvánnyal.,
azonban néhány probléma megoldása közben a CAs bevezet egy másikat. Mivel a CA issuescertificates sok szerver, még mindig szükség van valamilyen módon, hogy megbizonyosodjon arról beszél, hogy theserver szeretne. Ennek kezelésére a CA által kiadott tanúsítvány azonosítja a servereither-t egy adott névvel, például gmail.com vagy egy wildcarded készlethosts mint *.google.com.
a következő példa egy kicsit konkrétabbá teszi ezeket a fogalmakat., A parancssorból a openssleszköz s_client parancs a Wikipedia szerver tanúsítványinformációit vizsgálja. Itspeifies port 443 mert ez az alapértelmezett HTTPS. A parancs elküldia openssl s_client openssl x509 kimenete, amely az X. 509 szabvány szerinti tanúsítványokat formázza. Pontosabban, a parancs kéri a témát,amely tartalmazza a szerver nevét, valamint a kibocsátót, amely azonosítja a CA-t.,
láthatja, hogy a tanúsítványt a * – nak megfelelő kiszolgálókhoz adták ki.wikipedia.org by the RapidSSL ca.
HTTPS példa
feltételezve, hogy van egy webszerver acertificate által kiadott egy jól ismert CA, akkor lehet, hogy egy biztonságos kérelmet kód assimple ezt:
Igen, ez tényleg lehet, hogy ilyen egyszerű. Ha azt szeretnénk, hogy testre a HTTP kérés, akkor leadott toan HttpURLConnection., AHttpURLConnection Android dokumentációja további példákat tartalmaz a követelmények kezelésérőlés válaszfejlécek, tartalom közzététele, cookie-k kezelése, proxyk használata,gyorsítótárazási válaszok stb. De ami a tanúsítványok és a hostnevek ellenőrzésének részleteit illeti, az Androidframework gondoskodik róla ezen API-kon keresztül.Ez az, ahol akarsz lenni, ha egyáltalán lehetséges. Hogy az említett, az alábbiakban néhány más megfontolások.,
a Gyakori problémák ellenőrzése szerver tanúsítványok
Tegyük fel, ahelyett, hogy megkapta a tartalom getInputStream(), akkor kivételt dob:
Ennek több oka lehet, többek között:
- A CA, hogy ki a kiszolgálói tanúsítvány ismeretlen volt
- A szerver tanúsítvány nem volt aláírt egy CA által, de volt saját aláírású
- A szerver konfigurációs hiányzik egy köztes CA
A következő szakaszok beszéljétek meg, hogyan kezeli ezeket a problémákat, miközben yourconnection, hogy a szerver biztonságos.,
ismeretlen tanúsítvány hatóság
ebben az esetben a SSLHandshakeException előfordulmert van egy CA, amely nem megbízható a rendszer. Ennek oka lehet, hogy van egy új CA tanúsítványa, amelyet az Android még nem bízott meg, vagy az alkalmazás egy régebbi verzióra fut a CA nélkül. Gyakrabban a CA ismeretlen, mert nem apublic CA, hanem egy olyan szervezet által kiadott magán,mint egy kormány, vállalat, vagy oktatási intézmény saját használatra.
szerencsére megtaníthatja a HttpsURLConnection – ot, hogy bízzon egy adott CAs-készletben., Az eljárásegy kicsit bonyolult lehet, tehát az alábbiakban egy példa, amely egy adott CA froman InputStream – t használ, egy KeyStorelétrehozásához, amelyet ezután aTrustManagerlétrehozására és inicializálására használnak. ATrustManager ez az, amit a rendszer a serverand tanúsítványainak validálására használ—egyKeyStore egy vagy több CAs—t használva-ez lesz az egyetlen CAs, amelyet aTrustManagermegbízható.,
tekintettel az új TrustManager,a példa inicializálja egy új SSLContext amely providesan SSLSocketFactory használhatja, hogy felülírja az alapértelmezettSSLSocketFactory. Így a kapcsolat a CAS-t fogja használni a tanúsítvány érvényesítéséhez.
itt van a példa infull egy szervezeti CA A University of Washington:
egy egyéni TrustManager hogy tud a CAs,a rendszer képes érvényesíteni, hogy a szerver tanúsítvány jön egy megbízható kibocsátó.,
Vigyázat: sok webhely egy rossz alternatív megoldást ír le, amely egyTrustManager telepítése, amely semmit sem tesz. Ha ezt megteszi, akkor akár nem is titkosítja a kommunikációt, mert bárki megtámadhatja a felhasználókat egy nyilvános Wi-Fi hotspoton DNS-trükkökkel, hogy a felhasználók traffic-jét saját proxyján keresztül küldje el, amely úgy tesz, mintha a szerver lenne. A támadó ezután jelszavakat és egyéb személyes adatokat is rögzíthet., Ez azért működik, mert a támadó képes acertificate—et generálni, és—TrustManager nélkül, ami ténylegvalidálja, hogy a tanúsítvány trustedsource-ból származik-az alkalmazás bárkivel beszélgethet. Tehát ne csináld ezt, még ideiglenesen sem. Az alkalmazás mindig megbízhat a kiszolgáló tanúsítványának kibocsátójával, ezért csak tegye meg.
önaláírt szerver tanúsítvány
A második esetben a SSLHandshakeException isdue, hogy egy önaláírt tanúsítvány, ami azt jelenti, hogy a szerver úgy viselkedik, mint a saját CA.,Ez hasonló egy ismeretlen tanúsítványhatósághoz, így használhatjaugyanaz a megközelítés az előző szakaszból.
akkor létrehozhat saját TrustManager, ezúttal bízva a szerver tanúsítványt közvetlenül. Ez az összes thedownsides korábban tárgyalt árukapcsolás az alkalmazás közvetlenül egy tanúsítványt, de lehet donesecurely. Ugyanakkor ügyelni kell arra, hogy az önaláírt tanúsítványnak legyen egy nagyon erős kulcsa. 2012-től elfogadható egy 2048 bites RSA aláírás, amelynek exponense 65537 expiringyearly., A kulcsok forgatásakor ellenőrizze az anauthority (például a NIST) ajánlásait arról, hogy mi elfogadható.
hiányzó köztes tanúsító hatóság
a SSLHandshakeException harmadik eset egy hiányzó köztes CA miatt fordul elő. A legtöbb publicCAs nem írja alá közvetlenül a szerver tanúsítványokat. Helyette, használják a fő CA tanúsítvány, a továbbiakban a root CA, aláírására közbenső CAs. Ezt azért teszik, hogy a root CA tárolható legyen a kompromisszum kockázatának csökkentése érdekében., Azonban az olyan operációs rendszerek, mint az Android,általában csak a root CAs—t bízzák meg közvetlenül, ami rövid bizalmat hagy a servercertificate—a közbenső CA által aláírt-és a tanúsítvány hitelesítő között, amely ismeri a root CA-t. A solvethis-hez a szerver nem csak az SSL kézfogás során küldi el az ügyfél tanúsítványát, hanem egy tanúsítványláncot is a szerver CA-tól a megbízható root CA eléréséhez szükséges intermediereken keresztül.
annak megtekintéséhez, hogy ez hogyan néz ki a gyakorlatban, itt van a levél.google.,com certificatechain által megtekintett openssls_client parancs:
Ez azt mutatja, hogy a szerver küld egy igazolást mail.google.a Thawte SGC CA, amely egy köztes CA, és egy második tanúsítványa Thawte SGC CA által kiadott Verisign CA, amely az elsődleges CA, hogy ” strusted by Android.
azonban nem ritka, hogy konfigurálja a szerver nem tartalmazza a szükséges intermediate ca., Például itt van egy szerver, amely hibát okozhat az Android böngészőkben ésfogalmak az Android alkalmazásokban:
érdekes megjegyezni, hogy a szerver látogatása a legtöbb asztali böngészőbennem okoz hibát, mint egy teljesen ismeretlen CA vagy önaláírt szerver tanúsítvány. Ez azért van, mert a legtöbb asztali böngésző cache megbízható közbenső CAs idővel. Az Oncea browser felkereste és megismerte az egyik oldalról érkező közbenső CA-t, a következő alkalommal nem kell a közbenső CA-t a tanúsítványláncba bevinni.,
egyes webhelyek szándékosan ezt teszik az erőforrások kiszolgálására használt másodlagos webszervereknél. Forexample, lehet, hogy a fő HTML oldal szolgált egy szerver teljes certificatechain, de szerverek erőforrások, mint a képek, CSS, vagy a JavaScript nem tartalmazza theCA, feltehetően menteni sávszélesség. Sajnos néha ezek a szerverek biztosíthatnakegy webes szolgáltatás, amelyet megpróbál hívni az Android alkalmazásból, ami nem olyan megbocsátó.
a probléma megoldására két megközelítés létezik:
- konfigurálja a kiszolgálót úgy, hogy a közbenső CA-t a szerverláncba tartalmazza., A legtöbb CAs dokumentációt nyújt arról, hogyan kell ezt megtenni az összes közös webszerver számára. Ez az egyetlen megközelítés, ha szüksége van a webhelyre, hogy legalább az Android 4.2-en keresztül működjön az alapértelmezett Android böngészőkkel.
- vagy kezelje a közbenső CA-t, mint bármely más ismeretlen CA-t, és hozzon létre egy
TrustManager– t, hogy közvetlenül bízzon benne, ahogy az előző két szakaszban történt.
gyakori problémák a hostname ellenőrzéssel
amint azt a cikk elején említettük, az SSL-kapcsolat ellenőrzésének két kulcsfontosságú része van., A tanúsítvány első ellenőrzése megbízható forrásból származik, amely az előző szakasz középpontjában állt. Ennek a szakasznak a középpontjában a második rész áll: győződjön meg róla, hogy az Ön által megadott kiszolgáló bemutatja a megfelelő tanúsítványt. Ha nem, akkor általában egy hiba jelenik meg:
ennek egyik oka a kiszolgáló konfigurációs hibája. A kiszolgáló olyan tanúsítvánnyal van konfigurálva, amely nem rendelkezik olyan alany vagy tárgy alternatív névmezőkkel, amelyek megfelelnek az elérni kívánt kiszolgálónak. Lehetőség van egy tanúsítvány felhasználásárasok különböző kiszolgálóval., Például az google.com tanúsítványopenssl s_client -connect google.com:443 | openssl x509 -text láthatjuk, hogy egy tárgyhogy támogatja *. google.com de alternatív nevek is *.youtube.com,*. android.com és mások. A hiba csak akkor fordul elő, ha a kiszolgáló neve, amelyhez csatlakozik, nem szerepel a tanúsítványban elfogadhatónak.
sajnos ez más okból is megtörténhet: virtuális tárhely. Ha több hostnevet is megoszt az aserverrel a HTTP-vel, a webszerver a HTTP/1.1 kérelemből tudja megmondani, hogy melyik cél hostname-t keresi az ügyfél., Sajnos ez bonyolulthttps, mert a kiszolgálónak tudnia kell, hogy melyik tanúsítványt kell visszatérnie, mielőtt látja a HTTPrequest-et. A probléma megoldásához az SSL újabb verziói, különösen a TLSv.1.0 vagy újabb,support Server Name Indication(SNI), amely lehetővé teszi az SSL kliens, hogy adja meg a intendedhostname a szerver, így a megfelelő tanúsítványt lehet vissza.
szerencsére HttpsURLConnection supportsSNI mivel Android 2.3. Egy workaroundif támogatnia kell az Android 2-t.,A 2 (vagy annál régebbi) egy alternativevirtual host létrehozása egy egyedi porton, hogy egyértelmű legyen, melyik szerver tanúsítványt kell visszaküldeni.
a drasztikusabb alternatíva a HostnameVerifiercseréje olyanra, amely nem a virtuális gazdagép nevét használja, hanem azt, amelyet alapértelmezés szerint a szerver visszaküldött.
Vigyázat: aHostnameVerifiercseréje nagyon veszélyes lehet, ha a másik virtuális gazdagép nem az Ön irányítása alatt áll, mert az anon-pathattacker a forgalmat egy másikhoz irányíthatjaszerver az Ön tudta nélkül.,
Ha még mindig nem biztos, hogy szeretné bírálni hostname ellenőrzés, itt van egy examplethat helyettesíti a hitelesítő egyetlen URLConnectionaz egyik, hogy még mindig ellenőrzi, hogy a gépnév legalább a várható által az alkalmazás:
De ne feledd, ha találsz magadnak cseréje hostname ellenőrzés, especiallydue, hogy virtuális tárhely, ez még mindig nagyon veszélyes, ha a másik virtuális host, nem a mi irányításunk alatt meg kell találni egy másik hosting arrangementthat elkerüli ezt a kérdést.,
figyelmeztetések az SSLSocket közvetlen használatáról
eddig a példák a HTTPS-re összpontosítottak a HttpsURLConnectionhasználatával.Néha az alkalmazásoknak SSL-t kell használniuk a HTTP-től elkülönítve. Például egy e-mail alkalmazás SSL variantsof SMTP, POP3 vagy IMAP-ot használhat. Ezekben az esetekben az alkalmazás szeretné használni a SSLSocketközvetlenül, ugyanúgy, mint a HttpsURLConnection belsőleg.
a tanúsítványellenőrzési kérdések kezelésére leírt technikák aSSLSocket – ra is vonatkoznak.,Valójában, ha egyéni TrustManager – t használ, akkor aHttpsURLConnection egy SSLSocketFactory.tehát ha egyéni TrustManager – ot kell használni egySSLSocket kövesse ugyanazokat a lépéseket, és használja a SSLSocketFactorySSLSocketlétrehozásához.
Vigyázat:SSLSocket nem végez hostname ellenőrzést. It isup az alkalmazás, hogy nem a saját hostname ellenőrzés, lehetőleg hívja getDefaultHostnameVerifier() a várt hostname., Továbbaz HostnameVerifier.verify()nem dob kivételt a hibára, hanem egy logikai eredményt ad vissza, amelyet feltétlenül ellenőriznie kell.
itt van egy példa, amely bemutatja, hogyan lehet ezt megtenni. Ez azt mutatja, hogy amikor csatlakozik togmail.com port 443 SNI támogatás nélkül, akkor kap egy tanúsítványt formail.google.com. ez ebben az esetben várható, ezért ellenőrizze, hogy eza tanúsítvány valóban az mail.google.com:
Denylisting
az SSL nagymértékben támaszkodik a CAs-ra, hogy csak a kiszolgálók és domainek megfelelően ellenőrzött tulajdonosainak adjon ki tanúsítványokat., Ritka esetekben a CAs-t becsapják, vagy a Comodo vagy a DigiNotar esetében megsértik, ami azt eredményezi,hogy a hostname tanúsítványait ki kell adnimindenki más, mint a szerver vagy a domain tulajdonosa.
a kockázat csökkentése érdekében az Android képes bizonyos tanúsítványokat vagy akár teljes CAs-t hozzáadni egy denilistához. Bár ez a lista történelmileg be volt építve az operációs rendszerbe, elkezdveaz Android 4.2-ben ez a lista távolról frissíthető a jövőbeli kompromisszumok kezelésére.,
Pinning
egy alkalmazás tovább védheti magát az atechnique által csalárd módon kiadott tanúsítványoktól, amelyeket pinning néven ismertek. Ez alapvetően az ismeretlen CA-ügyben megadott példát használjaa fentiek alapján az alkalmazás megbízható CAs-ját egy kis készletre korlátozhatja, amelyet az alkalmazás szerverei használnak. Ezmeglehetetleníti a rendszer másik 100+ CAs-jának kompromisszumát, ami az alkalmazások biztonságos csatornájának megsértését eredményezi.
ügyfél tanúsítványok
Ez a cikk az SSL felhasználójára összpontosított, hogy biztosítsa a kiszolgálókkal való kommunikációt., Az SSL támogatja az ügyfél tanúsítványok fogalmát is, amelyek lehetővé teszik a szerver számára az aclient személyazonosságának érvényesítését. Bár a cikken kívül az érintett technikák hasonlóak a specifikációhozegy egyedi TrustManager.
Nogotofail: a network traffic security testing tool
Nogotofail egy olyan eszköz ad egy egyszerű módja annak, hogy erősítse meg, hogy az alkalmazások biztonságosak az ismert TLS / SSL biztonsági rések és téves konfigurációk. Ez egy automatizált, nagy teljesítményű és skálázható eszköz a hálózati biztonsági problémák tesztelésére minden olyan eszközön, amelynek hálózati forgalma áthidalható.,
a Nogotofail három fő felhasználási esetben hasznos:
- hibák és sebezhetőségek keresése.
- a javítások ellenőrzése és a regressziók figyelése.
- annak megértése, hogy milyen alkalmazások és eszközök generálják a forgalmat.
a Nogotofail Android, iOS, Linux, Windows, Chrome OS, OSX operációs rendszereken működik, valójában minden olyan eszköz, amelyet az internethez való csatlakozáshoz használ. Van egy könnyen használható kliens, hogy konfigurálja a beállításokat, és kap értesítést az Android és a Linux, valamint a támadás motor maga, amely lehet telepíteni, mint egy router, VPN szerver, vagy proxy.