Secure Sockets Layer (SSL)—acum cunoscut din punct de vedere tehnic ca Transport Layer Security(TLS)—este un bloc comun pentru comunicațiile criptate între clienți și servere. Este posibil ca o aplicație să utilizeze SSL incorect, astfel încât entitățile rău intenționate să poată intercepta datele unei aplicații prin rețea., Pentru a vă ajuta să vă asigurați că acest lucru nu se întâmplăpentru aplicația dvs., acest articol evidențiază capcanele comune atunci când utilizați protocoale de rețea securizate și abordează unele preocupări mai mari cu privire la utilizarea infrastructurii cu cheie publică (PKI).
ar trebui să citiți, De asemenea, AndroidSecurity Prezentare generală, precum și PermissionsOverview.
concepte
într-un scenariu tipic de utilizare SSL, un server este configurat cu un certificat care conține cheie apublic, precum și o cheie privată de potrivire., Ca parte a strângerii de mână între un server CLIENTAND SSL, serverul dovedește că are cheia privată prin semnarea certificatului său cu criptografie cu cheie publică.
cu toate Acestea, oricine poate genera propria lor certificatul și cheia privată, deci, un simplu handshakedoesn nu dovedește nimic despre server, altele decât că serverul cunoaște cheia privată thatmatches cheii publice din certificat. O modalitate de a rezolva această problemă este de a avea clientulau un set de unul sau mai multe certificate în care are încredere. Dacă certificatul nu este în set, serverul nu trebuie să aibă încredere.,există mai multe dezavantaje ale acestei abordări simple. Serverele ar trebui să poată trece la chei mai puternice în timp („rotirea cheilor”), care înlocuiește cheia publică din certificat cu una nouă. Din păcate, acum aplicația client trebuie actualizată din cauza a ceea ceeste în esență o modificare a configurației serverului. Acest lucru este deosebit de problematic dacă serverulnu este sub controlul dezvoltatorului de aplicații, de exemplu dacă este un serviciu web terț. Thisapproach are, de asemenea, probleme în cazul în care aplicația trebuie să vorbească cu servere arbitrare, cum ar fi un browser web oremail app.,
pentru a aborda aceste dezavantaje, serverele sunt de obicei configurate cu certificatede la emitenți bine cunoscuți numiți autorități de certificare (CAs).Platforma gazdă conține, în general, o listă de CAs bine cunoscute că trusts.As de Android 4.2 (Jelly Bean), Android conține în prezent peste 100 CAs care sunt actualizateîn fiecare versiune. Similar cu un server, un CA are un certificat și o cheie privată. La emiterea unui certificat pentru un server, CA semneazăcertificatul serverului folosind cheia sa privată. Theclient poate verifica apoi dacă serverul are un certificat emis de un CA cunoscut platformei.,cu toate acestea, în timp ce rezolvarea unor probleme, folosind CAs introduce un alt. Deoarece ca emite certificate pentru multe servere, mai aveți nevoie de o modalitate de a vă asigura că vorbiți cu serverul pe care îl doriți. Pentru a rezolva acest lucru, certificatul emis de către AC identifică servereither cu un nume specific, cum ar fi gmail.com sau o wildcarded set gazde, cum ar fi *.google.com.
următorul exemplu va face aceste concepte un pic mai concret., În fragmentul belowfrom o linie de comandă, opensslinstrument de e s_client comanda se uită la Wikipedia server certificat de informare. Itspecifică portul 443, deoarece acesta este implicit pentru HTTPS. Comanda sendsthe ieșire de openssl s_client și openssl x509, care formate informații despre certificate în conformitate cu X. 509 standard. Mai exact, comanda solicită subiectul, care conține informațiile despre numele serverului, și emitentul, care identifică CA.,
puteți vedea că certificatul a fost emis pentru serverele de potrivire *.wikipedia.org prin RapidSSL CA.presupunând că aveți un server web cu certificat emis de un CA bine cunoscut, puteți face o solicitare sigură cu codul assimple acest lucru:
da, într-adevăr poate fi atât de simplu. Dacă doriți să adaptați cererea HTTP, puteți arunca toan HttpURLConnection., Documentația Android pentruHttpURLConnection are mai multe exemple despre cum să se ocupe cu requestand anteturile de răspuns, postarea de conținut, gestionarea cookie-urilor, folosind proxy-uri, cache răspunsuri,și așa mai departe. Dar în ceea ce privește detaliile pentru verificarea certificatelor și a numelor de gazdă, Androidframework are grijă de el prin intermediul acestor API-uri.Acest lucru este în cazul în care doriți să fie dacă este posibil. Acestea fiind spuse, mai jos sunt câteva alte considerente.,
probleme Comune verificarea certificatelor de server
să Presupunem că în loc de a primi conținut de getInputStream(), se aruncă o excepție:
Acest lucru se poate întâmpla din mai multe motive, inclusiv:
- AC care a emis certificatul de server a fost necunoscut
- certificat de server nu a fost semnat de un AC, dar a fost auto-semnat
- server configuration lipsește o CA intermediar
următoarele secțiuni discuta despre modul de a aborda aceste probleme în timp ce păstrarea yourconnection la server securizat.,
Necunoscut autoritate de certificare
În acest caz, SSLHandshakeException occursbecause ai CA care nu este de încredere de către sistem. Ar putea fi pentru că aveți un certificat de la un CA nou care nu este încă de încredere de către Android sau aplicația dvs. rulează pe o versiune mai veche fără CA. Mai des, un CA este necunoscut, deoarece nu este apublic CA, ci unul privat emis de o organizație, cum ar fi un guvern,o corporație sau o instituție de învățământ pentru uz propriu.din fericire, puteți învăța HttpsURLConnectionsă aveți încredere într-un set specific de CAs., La procedurecan fi un pic complicat, deci, mai jos este un exemplu care are un specific CA froman InputStream, foloseste-l pentru a crea un KeyStore,care este apoi utilizat pentru a crea și de a inițializa unTrustManager. Un TrustManager este ceea ce systemuses pentru a valida certificatele de serverand—prin crearea unul de la un KeyStore cu una sau mai multe CAs—thosewill fi doar CAs de încredere de care TrustManager.,
Având în vedere noua TrustManager,de exemplu inițializează un nou SSLContext care providesan SSLSocketFactory puteți folosi pentru a trece peste implicitSSLSocketFactory de laHttpsURLConnection. În acest fel, conexiunea va utiliza CAs-ul dvs. pentru validarea certificatului.
Aici este un exemplu în deplină folosind o organizare CA la Universitatea din Washington:
Cu un custom TrustManager care știe despre CAs,sistemul este capabil să validatethat server certificat provin dintr-o încredere emitent.,
atenție: multe site-uri web descriu o soluție alternativă slabă, care este de a instala unTrustManager care nu face nimic. Dacă faci asta s-ar putea la fel de bine ca nu criptarea de comunicare, pentru că oricine poate ataca utilizatorii de la un Wi-Fi public hotspotby folosind DNS trucuri pentru a trimite utilizatorilor’traffic printr-un proxy de propria lor, care pretinde a fi server. Atacatorul poateînregistrați parolele și alte date personale., Acest lucru funcționează pentru că atacatorul poate genera certificat și fără un TrustManager că actuallyvalidates că certificatul vine de la un trustedsource—aplicația ar putea fi vorba de cineva. Așa că nu face asta, nici măcar temporar. Puteți face întotdeauna aplicația dvs. să aibă încredere în emitentul certificatului serverului, așa că faceți-o.
Auto-semnat certificatul serverului
Al doilea caz de SSLHandshakeException isdue la un certificat auto-semnat, ceea ce înseamnă că serverul se comportă ca și propriile AC.,Acest lucru este similar cu o autoritate de certificare necunoscută, astfel încât să puteți utilizaaceeași abordare din secțiunea anterioară.
puteți crea propriul TrustManager, de data aceasta având încredere în certificatul de server direct. Acest lucru are toate thedownsides discutate mai devreme de a lega aplicația direct la un certificat, dar poate fi doesecurely. Cu toate acestea, ar trebui să aveți grijă să vă asigurați că certificatul dvs. auto-semnat are o cheie extrem de puternică. Începând cu 2012, o semnătură RSA de 2048 biți cu un exponent de 65537 expiringyearly este acceptabilă., Când rotiți tastele, ar trebui să verificați recomandările de la anautoritate (cum ar fi NIST) despre ceea ce este acceptabil.
lipsă autoritate de certificare intermediară
al treilea caz de SSLHandshakeException apare din cauza lipsei unui CA intermediar. Cele mai multe publicCAs nu semnează certificate de server direct. În schimb, ei folosesc certificatul principal CA, denumit ca rădăcină, pentru a semna CAS intermediar. Ei fac acest lucru astfel încât rădăcina CA poate fi storedoffline pentru a reduce riscul de compromis., Cu toate acestea, sistemele de operare, cum ar fi Android typicallytrust numai rădăcina CAs direct, care lasă un scurt decalaj de încredere între servercertificate—semnat de către intermediar CA—și a certificatului de verificator,care stie CA rădăcină. Pentru a solvethis, serverul nu trimite clientul este certificat în timpul SSL handshake, buta lanț de certificate de server CA prin orice intermediari necesar pentru a ajunge încrezut CA rădăcină.pentru a vedea cum arată acest lucru în practică, iată e-mailul.google.,com certificatechain fi vizualizate de către openssls_client command:
Acest lucru arată că serverul trimite un certificat pentru e-mail.google.emis de ca Thawte SGC, care este un CA intermediar, și un al doilea certificat pentru ca Thawte SGC emis de un Ca Verisign, care este CA primar care este încredințat de Android.
cu toate acestea, nu este neobișnuit să configurați un server pentru a nu include Ca-ul necesarintermediat., De exemplu, aici este un server care poate provoca o eroare în browsere Android andexceptions în aplicații Android:
ceea Ce este interesant de reținut aici este că pe acest server, în cele mai multe desktop browsersdoes nu provoca o eroare ca un complet necunoscut AC sau auto-semnat certificatul serverului wouldcause. Acest lucru se datorează faptului că majoritatea browserelor desktop cache CAS intermediar de încredere în timp. Odată ce un browser a vizitat și a aflat despre un CA intermediar de la un site, acesta nu va trebui să aibă CA intermediar inclus în lanțul de certificate data viitoare.,unele site – uri fac acest lucru în mod intenționat pentru serverele web secundare utilizate pentru a servi resurse. Forexample, ei ar putea avea pagina lor HTML principal servit de un server cu un certificatechain complet, dar au servere pentru resurse, cum ar fi imagini, CSS, sau JavaScript nu includ theCA, probabil pentru a salva lățime de bandă. Din păcate, uneori aceste servere ar putea furnizaun serviciu web pe care încercați să îl apelați din aplicația Android, care nu este la fel de iertător.există două abordări pentru a rezolva această problemă:
- Configurați serverul pentru a include ca intermediar în lanțul de servere., Majoritatea CAs furnizează documentație despre cum se poate face acest lucru pentru toate serverele web comune. Aceasta este singura abordare dacă aveți nevoie ca site-ul să funcționeze cu browserele Android implicite cel puțin prin Android 4.2.
- sau, tratați ca intermediar ca orice alt CA necunoscut și creați un
TrustManagerpentru a avea încredere în el direct, așa cum s-a făcut în cele două secțiuni anterioare.
probleme comune cu verificarea numelui de gazdă
așa cum am menționat la începutul acestui articol,există două părți cheie pentru verificarea unei conexiuni SSL., Primul este de a verifica certificatul este dintr-o sursă de încredere, care a fost punctul central al precedentuluisecțiune. Accentul acestei secțiuni este partea a doua: asigurați-vă că serverul pe care vă adresațivorbind să prezinte certificatul potrivit. Când nu, veți vedea de obicei o eroarecum ar fi:
un motiv pentru care se poate întâmpla acest lucru se datorează unei erori de configurare a serverului. Serverul esteconfigurat cu un certificat care nu are un subiect sau subiect nume alternative fields care se potrivesc cu serverul pe care încercați să ajungă. Este posibil să se utilizeze un singur certificatcu multe servere diferite., De exemplu, se uită la google.com certificat cuopenssl s_client -connect google.com:443 | openssl x509 -text puteți vedea că o subjectthat acceptă *.google.com dar, de asemenea, obiectul unor denumiri alternative pentru *.youtube.com,*.android.com, și altele. Eroarea apare numai atunci când numele serverului la care vă conectați nu este listat de certificat ca acceptabil.din păcate, acest lucru se poate întâmpla și dintr-un alt motiv: găzduirea virtuală. Când partajați aserver pentru mai mult de un nume de gazdă cu HTTP, serverul web poate spune din HTTP/1.1 requestwhich nume de gazdă țintă clientul caută., Din păcate, acest lucru este complicat withHTTPS, deoarece serverul trebuie să știe ce certificat să se întoarcă înainte de a vedea HTTPrequest. Pentru a rezolva această problemă, versiuni mai noi de SSL, în special tlsv.1.0 și mai târziu,Suport Server Name Indication (SNI), care permite clientului SSL pentru a specifica intendedhostname la server, astfel încât certificatul propriu-zis poate fi returnat.din fericire, HttpsURLConnection supportsSNI deoarece Android 2.3. Un workaroundif aveți nevoie pentru a sprijini Android 2.,2 (și mai vechi) este de a configura o alternativăhost virtual pe un port unic, astfel încât să fie clar ce certificat de server să se întoarcă.
alternativa mai drastică este să înlocuiți HostnameVerifier cu unul care nu utilizează numele de gazdă al gazdei dvs. virtuale, ci cel returnat de server în mod implicit.
Atenție: Înlocuirea HostnameVerifierpoate fi foarte periculos dacă cealaltă gazdă virtuală nu este sub controlul tău, pentru că anon-pathattacker ar putea direcționa trafic către anotherserver fără știrea dumneavoastră.,
Dacă sunteți sigur că doriți să suprascrie hostname verificare, aici este o examplethat înlocuiește verificator pentru un singur URLConnectioncu unul care încă mai verifică dacă numele de gazdă este cel puțin la temperatura de aplicație:
Dar amintiți-vă, dacă vă aflați înlocuirea hostname verificare, especiallydue pentru virtual hosting, este foarte periculos dacă cealaltă gazdă virtuală nu este sub controlul tău și tu ar trebui să găsească o alternativă hosting arrangementthat evită această problemă.,
Avertismente despre utilizarea SSLSocket direct
Așa mai departe, exemplele s-au concentrat pe HTTPS folosind HttpsURLConnection.Uneori, aplicațiile trebuie să utilizeze SSL separat de HTTP. De exemplu, o aplicație de e-mail poate utiliza variante SSL de SMTP, POP3 sau IMAP. În aceste cazuri, aplicația ar dori să utilizeze SSLSocketdirect, la fel cum HttpsURLConnection face intern.
tehnicile descrise sofar pentru a face față problemelor de verificare a certificatului se aplică și pentru SSLSocket.,De fapt, atunci când se utilizează un obicei TrustManager, ceea ce este trecut laHttpsURLConnection este un SSLSocketFactory.Deci, dacă aveți nevoie pentru a utiliza un obicei TrustManager cu unSSLSocket, urma aceeași pași și de a folosi că SSLSocketFactory pentru a creaSSLSocket.
atenție:SSLSocket nu efectuează verificarea numelor de gazdă. Depinde de aplicația dvs. să facă propria verificare a numelui de gazdă, de preferință apelând getDefaultHostnameVerifier() cu numele de gazdă așteptat., Furtherbeware că HostnameVerifier.verify()nu arunca o excepție de la eroare dar în loc de a se întoarce un rezultat boolean care le mustexplicitly verifica.
Iată un exemplu care arată cum puteți face acest lucru. Acesta arată că, atunci când conectarea togmail.com portul 443 fără SNI sprijin, vei primi un certificat formail.google.com. Acest lucru este de așteptat în acest caz, astfel încât asigurați-vă că certificatul este într-adevăr pentru mail.google.com:
Denylisting
SSL se bazează foarte mult pe CAs să emită certificate numai verificate în mod corespunzător ownersof servere și domenii., În cazuri rare, CAs sunt fie păcălite, fie, în cazul Comodo sau DigiNotar,încălcate, rezultând certificatele pentru un nume de gazdă care urmează să fie eliberat altcuiva decât proprietarul serverului sau domeniului.pentru a atenua acest risc, Android are capacitatea de a adăuga anumite certificate sau chiarîntreg CAs la un denylist. În timp ce această listă a fost construită istoric în sistemul de operare, începândîn Android 4.2 această listă poate fi actualizată de la distanță pentru a face față compromisurilor viitoare.,
Pinning
o aplicație se poate proteja în continuare de certificatele emise în mod fraudulos de atechnique cunoscut sub numele de pinning. Acest lucru utilizează practic exemplul furnizat în cazul ca necunoscut de mai sus pentru a restricționa CAs-ul de încredere al unei aplicații la un set mic cunoscut a fi utilizat de serverele aplicației. Acest lucru împiedică compromisul unuia dintre celelalte 100 + CAs din sistem să ducă la o încălcare a canalului securizat al aplicațiilor.
certificate client
Acest articol s-a concentrat pe utilizatorul SSL pentru a securiza comunicațiile cu serverele., SSL, de asemeneasprijină noțiunea de certificate client care permit serverului să valideze identitatea aclient. În timp ce dincolo de domeniul de aplicare al acestui articol, tehnicile implicate sunt similare cu specifyinga personalizat TrustManager.nogotofail este un instrument care vă oferă o modalitate ușoară de a confirma că aplicațiile dvs. sunt sigure împotriva vulnerabilităților TLS/SSL cunoscute și a configurațiilor greșite. Este un instrument automatizat, puternic și scalabil pentru testarea problemelor de securitate a rețelei pe orice dispozitiv al cărui trafic de rețea ar putea fi făcut să treacă prin el., Nogotofail este util pentru trei cazuri principale de utilizare:
- găsirea de erori și vulnerabilități.
- verificarea remedierilor și urmărirea regresiilor.
- înțelegerea aplicațiilor și dispozitivelor care generează trafic. Nogotofail funcționează pentru Android, iOS, Linux, Windows, Chrome OS, OSX, de fapt orice dispozitiv pe care îl utilizați pentru a vă conecta la Internet. Există un client ușor de utilizat pentru a configura setările și pentru a primi notificări pe Android și Linux, precum și motorul de atac în sine, care poate fi implementat ca router, server VPN sau proxy.