Secure Sockets Layer (SSL)—nyt teknisesti tunnetaan nimellä Transport Layer Security(TLS)—on yhteinen rakennuspalikka salattu viestintä asiakkaiden ja palvelinten välillä. On mahdollista, että thatan-sovellus voi käyttää SSL: ää väärin siten, että haitalliset yhteisöt voivat ehkä siepata sovelluksen tiedot verkon kautta., Jotta voit varmistaa, että tämä ei tapahdu sovelluksessasi, tässä artikkelissa korostetaan yhteisiä sudenkuoppia käytettäessä turvallisia verkkoprotokollia ja puututaan joihinkin suurempiin huolenaiheisiin julkisen avaimen infrastruktuurin (PKI) käytöstä.
kannattaa lukea myös AndroidSecurity Overview sekä PermissionsOverview.
käsitteet
tyypillisessä SSL-käyttöskenaariossa palvelimelle on määritetty apublic-näppäintä sisältävä varmenne sekä vastaava yksityinen avain., Osana SSL-asiakaskunnan ja palvelimen välistä kädenpuristusta palvelin todistaa, että sillä on yksityinen avain allekirjoittamalla varmenteensa julkisen avaimen salauksella.
Kuitenkin, kuka tahansa voi luoda oman varmenteen ja yksityisen avaimen, niin yksinkertainen handshakedoesn todista mitään-palvelin, muut kuin, että palvelin tietää yksityinen avain thatmatches julkisen avaimen varmenne. Yksi tapa ratkaista tämä ongelma on saada clienthave joukko yksi tai useampi varmenteita se luottaa. Jos varmenne ei ole asetettu, palvelimeen ei voi luottaa.,
tämän yksinkertaisen lähestymistavan varjopuolia on useita. Palvelimien pitäisi ajan mittaan pystyä kääntämään vahvemmat avaimet (”key rotation”), joka korvaa julkisen avaimen sertifikaatissa uudella avaimella. Valitettavasti, nyt asiakkaan sovellus on päivitettävä, koska whatis olennaisesti palvelimen kokoonpanon muutos. Tämä on erityisen ongelmallista, jos serverit eivät ole sovelluskehittäjän hallinnassa, esimerkiksi jos kyseessä on kolmannen osapuolen verkkopalvelu. Thisapproach on myös ongelmia, Jos sovellus on puhua mielivaltaisia palvelimia, kuten web-selain oremail sovellus.,
jotta käsitellä näitä haittoja, palvelimet ovat tyypillisesti määritetty certificatesfrom tunnettu liikkeeseenlaskijoiden kutsutaan Varmenteen myöntäjien (ca).Isäntä foorumi yleensä sisältää luettelon tunnettu CAs, että se luottaa.Koska Android 4.2 (Jelly Bean), Android sisältää tällä hetkellä yli 100 CAs, jotka ovat sitä on ajantasaistettu vuosina jokainen julkaisu. Palvelimen tapaan CA: lla on varmenne ja oma avain. Kun annat varmenteen palvelimelle, CA allekirjoittaapalvelintodistuksen käyttämällä sen yksityistä avainta. Tämän jälkeen asiakas voi tarkistaa, että palvelimella on Alustan tunteman CA: n myöntämä varmenne.,
kuitenkin, kun ratkotaan joitakin ongelmia, CAS: n käyttö tuo toisen. Koska CA liikkeeseenlaskuilmoittaa monille palvelimille, tarvitset silti jonkin keinon varmistaa, että puhut palvelimelle haluat. Tämän ongelman ratkaisemiseksi, CA: n myöntämä varmenne tunnistetaan servereither kanssa erityinen nimi, kuten gmail.com tai wildcarded asettaa ofhosts kuten *.google.com.
seuraava esimerkki tekee näitä käsitteitä hieman enemmän konkreettisia., Tässä pätkä belowfrom komentoriviltä, openssltyökalu s_client komento näyttää Wikipedian palvelimen varmenteen tiedot. Se määrittelee portin 443, koska se on oletuksena HTTPS. Komento sendsthe tuotos openssl s_client ja openssl x509, joka muotoilee tietoa todistusten mukaan X. 509-standardin mukaan. Erityisesti komento kysyy kohdetta, joka sisältää palvelimen nimitiedot, ja liikkeeseenlaskijaa, joka tunnistaa CA.,
näet, että varmenne on myönnetty palvelimille, jotka vastaavat*. wikipedia.org by the RapidSSL CA.
HTTPS-esimerkki
Olettaen, että sinulla on web-palvelin, acertificate antama tunnettu CA, voit tehdä turvallisen pyynnöstä koodi assimple tämä:
Kyllä, se todella voi olla, että yksinkertainen. Jos haluat räätälöidä HTTP-pyynnön, voit heittää toan HttpURLConnection., Android-dokumentaatiostaHttpURLConnection on lisää esimerkkejä siitä, miten käsitellä requestand vastaus otsikot, lähettämistä sisällön, toimitusjohtaja evästeet, käyttää valtakirjoja, välimuistin vastauksia,ja niin edelleen. Mutta suhteen yksityiskohtia tarkastaa todistukset ja isäntänimiä, että Androidframework huolehtii sen kautta nämä APIs.Täällä halutaan olla, jos suinkin mahdollista. Tämä sanoi, alla on joitakin muita näkökohtia.,
Yleiset ongelmat tarkastaa palvelimen varmenteet
Oletetaan, että sen sijaan, että vastaanottaa sisältöä getInputStream(), se heittää poikkeus:
Tämä voi tapahtua useista syistä, mukaan lukien:
- CA on myöntänyt palvelinvarmenteen oli tuntematon
- palvelimen varmenne ei ollut allekirjoittanut CA, mutta oli itse allekirjoittanut
- palvelimen configuration puuttuu väli-CA
seuraavat kohdat keskustella siitä, miten käsitellä näitä ongelmia, kun pitää yourconnection palvelimelle turvallista.,
Tuntematon varmenteen myöntäjä
tässä tapauksessa SSLHandshakeException occursbecause sinulla on CA, että ei ole luotettu järjestelmä. Se voi olla, koska sinulla on varmenne uudesta CA, joka ei ole vielä luottanut Android tai sovellus isrunning vanhempi versio ilman CA. Useammin CA on tuntematon, koska se ei ole apublic CA, mutta oma yksi antama organisaatio, kuten hallitus, yhteisö tai oppilaitos omaan käyttöön.
Onneksi, voit opettaa HttpsURLConnectionluottaa tietty joukko CAs., Se procedurecan olla hieman sekava, joten alla on esimerkki, joka kestää tietyn CA froman InputStream, käyttää sitä luoda KeyStore,joka on sitten käytetään luoda ja alustaaTrustManager. TrustManager on mitä systemuses vahvistaa todistusten alkaen serverand—luomalla yksi KeyStore jossa on yksi tai useampi CAs—thosewill olla ainoa CAs luottaa, että TrustManager.,
uusien TrustManager,esimerkiksi alustaa uuden SSLContext jotka esitetään SSLSocketFactory voit ohittaa oletuksenaSSLSocketFactory alkaenHttpsURLConnection. Näin konnektio käyttää CAS: ia varmenteen validointiin.
Tässä on esimerkki infull käyttää organisaation CA Washingtonin Yliopistossa:
mukautetun TrustManager jotka tietää CAs -, järjestelmä pystyy validatethat palvelimen varmenne on peräisin luotettu myöntäjä.,
Varoitus:Monet web-sivustot kuvaamaan huono vaihtoehto ratkaisu, joka on asentaaTrustManager tuo ei ole mitään. Jos voit tehdä tämän voit yhtä hyvin notbe salaamalla viestintä, koska kuka tahansa voi hyökätä käyttäjille julkisen Wi-Fi hotspotby käyttämällä DNS temppuja lähettää käyttäjille’traffic välityspalvelimen kautta oman, joka teeskentelee olevansa palvelimelle. Hyökkääjä voi sitten koordinoida salasanoja ja muita henkilötietoja., Tämä toimii, koska hyökkääjä voi luoda acertificate ja ilman TrustManager että actuallyvalidates, että todistus tulee trustedsource—app voi puhua kenellekään. Älä siis tee tätä edes väliaikaisesti. Voit tehdä app luottaa myöntäjä palvelimen varmenteen, joten tee se.
Itse allekirjoitetun varmenteen
toisessa tapauksessa SSLHandshakeException esitteen itse allekirjoitettu sertifikaatti, joka tarkoittaa, että palvelin käyttäytyy kuten oma CA.,Tämä on samanlainen kuin tuntematon varmenneviranomainen, joten voit käyttää samaa lähestymistapaa edellisestä osiosta.
Voit luoda oman TrustManagertällä kertaa luottaminen palvelimen varmenteen suoraan. Tämä on kaikki ownsidejä keskusteltu aiemmin sitomisesta sovelluksen suoraan varmenteen, mutta voidaan doneskevasti. Kuitenkin, sinun pitäisi olla varovainen varmista, että oma allekirjoitettu todistus on uskomattoman vahva avain. Vuodesta 2012, 2048-bittinen RSA allekirjoitus eksponentti 65537 expiringyearly on hyväksyttävää., Avaimia pyörittäessä kannattaa tarkistaa anauthorityn (kuten NIST) suositukset siitä, mikä on hyväksyttävää.
Puuttuu intermediate certificate authority
kolmannessa tapauksessa SSLHandshakeExceptiontapahtuu, koska puuttuu väli-CA. Useimmat publiccat eivät allekirjoita palvelintodistuksia suoraan. Sen sijaan he käyttävät pääasiallista CA-varmennettaan,jota kutsutaan juuri CA: ksi, allekirjoittaakseen väli-CAs: n. He tekevät tämän, jotta root CA voidaan storedoffline vähentää kompromissiriskiä., Kuitenkin, käyttöjärjestelmiä, kuten Android typicallytrust vain root CAs suoraan, joka jättää lyhyt aukko välisen luottamuksen servercertificate—allekirjoittanut intermediate CA—ja sertifikaatin todentajan,joka tuntee juuri-CA. Voit solvethis, palvelin ei lähetä asiakkaalle vain, että se on todistus aikana SSL-kättely, buta ketjun varmenteiden palvelimelta CA läpi kaikki välituotteiden tarpeen päästä turvannut root CA.
nähdäkseen, miltä tämä näyttää käytännössä, tässä on posti.google.,com certificatechain kuin katsella openssls_client komento:
Tämä osoittaa, että palvelin lähettää todistus mail.google.comissued tekemät Thawte SGC-CA, joka on väli-CA, ja toinen koskee euroopan Thawte SGC CA, myöntäjä Verisign CA, joka on ensisijainen CA’strusted Android.
ei kuitenkaan ole harvinaista määrittää, että palvelin ei sisällä tarpeenmukaista intermediate CA., Esimerkiksi, tässä on palvelin, joka voi aiheuttaa virhettä Android selaimet andexceptions Android-sovellukset:
Mikä on mielenkiintoista huomata tässä on, että vierailevat tämä palvelin useimmissa desktop browsersdoes ei aiheuta virhettä kuin täysin tuntematon CA tai itse allekirjoitetun varmenteen wouldcause. Tämä johtuu siitä, että useimmat työpöydän selaimet välimuistiin luotettu väli CAs ajan. Kerran selain on käynyt ja oppinut väli-CA yhdestä sivuston, se ei’tneed on keskitason CA-varmenteeseen ketjun seuraavan kerran.,
jotkut sivustot tekevät tämän tarkoituksellisesti toissijaisille palvelimille, joita käytetään resurssien palvelemiseen. Esimerkiksi, ne saattavat olla heidän tärkein HTML-sivu palveli palvelimen kanssa koko certificatechain, mutta on palvelinten resursseja, kuten kuvia, CSS, tai JavaScript ei sisällä kotelo, oletettavasti säästää kaistanleveyttä. Valitettavasti, joskus nämä palvelimet saattavat olla providinga web service yrität soittaa Android-sovellus, joka ei ole yhtä anteeksiantava.
tämän ongelman ratkaisemiseksi on olemassa kaksi lähestymistapaa:
- Määritä palvelin sisällyttämään keskitason CA palvelinketjuun., Useimmat CAs: t tarjoavat dokumentaation siitä, miten tämä tehdään kaikille tavallisille web-palvelimille. Tämä on ainoa lähestymistapa, Jos tarvitset sivuston toimimaan oletuksena Android selaimet ainakin Android 4.2.
- Tai hoitoon keskitason CA-kuten mikä tahansa muu tuntematon CA, ja luoda
TrustManagerluota suoraan, kuten on tehnyt kahdessa edellisessä osissa.
Yleiset ongelmat hostname todentaminen
Kuten edellä alussa tämän artikkelin,on olemassa kaksi keskeistä osaa tarkistaa SSL-yhteyden., Lisäksi tarkistaa todistus on luotettavasta lähteestä, joka oli painopiste previoussection. Tämän osan painopiste on toinen osa: varmista, että palvelin olettalking esittää oikean varmenteen. Kun näin ei ole, näet tyypillisesti errorikaisen tämän:
yksi syy, miksi näin voi käydä, johtuu palvelimen määritysvirheestä. Palvelin on konfiguroitu varmenteella, jolla ei ole subjektia tai subjektia vaihtoehtoista nimeä kenttiä, jotka vastaavat palvelinta, johon yrität tavoittaa. On mahdollista, että yhtä varmennetta käytetään monilla eri palvelimilla., Esimerkiksi katsomalla google.com todistus, jossaopenssl s_client -connect google.com:443 | openssl x509 -text voit nähdä, että subjectthat tukee *.google.com mutta myös aihe vaihtoehtoiset nimet *.youtube.com,*.android.com, ja toiset. Virhe ilmenee vain, kun palvelimen nimi olet liittäminen ei ole lueteltu todistuksen hyväksyttävänä.
valitettavasti näin voi käydä myös toisesta syystä: virtuaalisesta hostingista. Kun jakaminen aserver enemmän kuin yksi hostname HTTP, web-palvelin voi kertoa HTTP/1.1 requestwhich kohde hostname asiakas on etsimässä., Valitettavasti tämä on monimutkainen withHTTPS, koska palvelin on tietää, mikä todistus palata, ennen kuin se näkee HTTPrequest. Ongelman ratkaisemiseksi uudemmat SSL-versiot, erityisesti TLSv.1.0 ja myöhemmin,tuki-Palvelimen Nimi Käyttöaihe(SNI), jonka avulla SSL-asiakas määrittää intendedhostname palvelimelle, jotta asianmukainen todistus voidaan palauttaa.
Onneksi HttpsURLConnection supportsSNI vuodesta Android 2.3. Yksi työaroundif sinun täytyy tukea Android 2.,2 (ja vanhempi) on perustaa alternativirtual isäntä ainutlaatuinen portti niin, että se on yksiselitteinen, mikä palvelimen varmenne palauttaa.
enemmän rajuja vaihtoehto on korvata HostnameVerifierkanssa yksi, joka käyttää ei thehostname virtuaalinen isäntä, mutta palvelimen palauttama oletuksena.
Varoitus: Korvaa HostnameVerifiervoi olla hyvin vaarallista, jos muut virtuaalinen isäntä ei ole hallinnassasi, koska anon-pathattacker voisi ohjata liikennettä anotherserver tietämättäsi.,
Jos olet edelleen varma että haluat ohittaa hostname todentaminen, täällä on examplethat korvaa todentajan yhden URLConnectionkanssa, joka vielä tarkistaa, että nimi on ainakin odotettavissa sovellus:
Mutta muista, jos löydät itsesi vaihdat hostname todentaminen, especiallydue virtuaalinen hosting, se on edelleen hyvin vaarallinen, jos muut virtuaalinen isäntä ei ole hallinnassasi ja sinun pitäisi löytää vaihtoehto hosting arrangementthat vältetään tämä ongelma.,
Varoitukset Sslsocketin käytöstä suoraan
toistaiseksi esimerkit ovat keskittyneet HTTPS-käyttöön HttpsURLConnection.Joskus sovellusten täytyy käyttää SSL: ää erillään HTTP: stä. Esimerkiksi sähköpostisovellus saattaa käyttää SSL-variantteja SMTP: stä, POP3: sta tai IMAP: sta. Niissä tapauksissa, sovellus haluaa käyttää SSLSocketsuoraan, paljon samalla tavalla, että HttpsURLConnection ei sisäisesti.
kuvattuja tekniikoita sofar varmenteen todentaminen kysymykset koskevat myös SSLSocket.,Itse asiassa, kun käytät mukautetun TrustManager, mikä on siirtynytHttpsURLConnection on SSLSocketFactory.Joten jos haluat käyttää mukautettua TrustManager, jossaSSLSocket, seuraavat samat vaiheet ja käyttää sitä SSLSocketFactory luoSSLSocket.
Varoitus:SSLSocket ei suorita hostname todentaminen. Se isup app voit tehdä oman hostname todentaminen, mieluiten soittamalla getDefaultHostnameVerifier() odotettavissa hostname., Furtherbeware, että HostnameVerifier.verify()ei heittää poikkeus virhe, mutta sen sijaan palauttaa totuusarvon tulokseen, että mustexplicitly tarkistaa.
tässä esimerkki siitä, miten voit tehdä tämän. Se osoittaa, että kun liität togmail.com portti 443 ilman SNI tuki, saat todistuksen formail.google.com. Tämä on odotettavissa, tässä tapauksessa, joten varmista, että todistus on todellakin mail.google.com:
Denylisting
SSL nojaa vahvasti CAs antaa todistuksia vain asianmukaisesti todennettu ownersof palvelimet ja verkkotunnukset., Harvoissa tapauksissa, CAs on joko huijattu tai, tässä tapauksessa Avg tai DigiNotar, rikkonut,jolloin todistukset hostname annetaan tosomeone muu kuin omistaja palvelimen tai toimialueen.
jotta tämän riskin pienentämiseksi, Android on kyky lisätä tiettyjä todistuksia tai evenwhole CAs on denylist. Vaikka tämä luettelo on historiallisesti rakennettu käyttöjärjestelmään, startingin Android 4.2 tämä luettelo voidaan etänä päivittää käsittelemään tulevia kompromisseja.,
Kiinnitys
sovellus voi edelleen suojella itse alkaen vilpillisesti antanut todistukset atechnique tunnetaan pinning. Tämä on pohjimmiltaan käyttämällä tuntemattoman CA caseaboven tarjoamaa esimerkkiä rajoittaakseen sovelluksen luotetun CAs: n pieneen joukkoon, jota sovelluksen palvelimet tunnetusti käyttävät. Tämä enteilee jonkin muun 100+ CAs: n kompromissia järjestelmässä, joka johtaa sovellusten suojatun kanavan rikkomiseen.
Client todistukset
Tämä artikkeli on keskittynyt käyttäjä SSL secure viestintä palvelimia., SSL tukee myös sellaisten asiakastodistusten käsitettä, joiden avulla palvelin voi vahvistaa aclientin henkilöllisyyden. Vaikka tämän artikkelin soveltamisalan ulkopuolella, kyseessä olevat tekniikat ovat samankaltaisia kuin specifyinga custom TrustManager.
Nogotofail: verkon liikenteen turvallisuuden testaus työkalu
Nogotofail on työkalu, antaa sinulle helppo tapa varmistaa, että sovellukset ovat turvallisia vastaan tunnettuja TLS/SSL haavoittuvuudet ja virheellisiä. Se on automatisoitu, tehokas ja skaalautuva työkalu testaukseen tietoturvan kysymyksiä millä tahansa laitteella, jonka verkkoon liikenne voitaisiin käydä läpi.,
Nogotofail on hyödyllinen kolmessa pääkäyttötapauksessa:
- vikojen ja haavoittuvuuksien löytäminen.
- korjausten tarkistaminen ja regressioiden seuraaminen.
- ymmärtää, mitkä sovellukset ja laitteet tuottavat mitä liikennettä.
Nogotofail toimii Android -, iOS -, Linux -, Windows -, Chrome OS, OSX, itse asiassa mikä tahansa laite voit käyttää Internet-yhteyden muodostamiseen. Siellä on helppo-to-käyttää asiakas määrittää asetukset ja saada ilmoituksia Android-ja Linux, sekä hyökkäys itse moottorin, joka voidaan ottaa käyttöön reitittimenä, VPN-palvelimen tai proxy.