Secure Sockets Layer (SSL)—nyní technicky známý jako Transport Layer Security(TLS)—je všeobecnou stavební blok pro šifrované komunikace mezi klienty a servery. Je možné, že aplikace může používat SSL nesprávně tak, že škodlivé entity mohou zachytit data aplikace v síti., Abychom vám pomohli zajistit, že se tak nestane, tento článek zdůrazňuje společná úskalí při používání zabezpečených síťových protokolů a řeší některé větší obavy z používání infrastruktury veřejného klíče (PKI).
měli byste si také přečíst přehled AndroidSecurity a PermissionsOverview.
koncepty
v typickém scénáři použití SSL je server nakonfigurován s certifikátem obsahujícím apublic klíč a odpovídajícím soukromým klíčem., V rámci handshake mezi klientem SSL a serverem server prokáže, že má soukromý klíč podepsáním certifikátu kryptografií veřejného klíče.
Nicméně, každý může vygenerovat vlastní certifikát a soukromý klíč, tak jednoduché handshakedoesn nic nedokazuje o server jiný než server zná soukromý klíč thatmatches veřejný klíč certifikátu. Jedním ze způsobů, jak tento problém vyřešit, je mít klientmají soubor jednoho nebo více certifikátů, kterým důvěřuje. Pokud certifikát není v sadě, pakserver není důvěryhodný.,
tento jednoduchý přístup má několik nevýhod. Servery by měly být schopny v průběhu času přecházet na silnější klíče („rotace klíčů“), které nahrazují veřejný klíč v počítači novým. Bohužel nyní musí být klientská aplikace aktualizována kvůli tomu, coje v podstatě změna konfigurace serveru. To je obzvláště problematické, pokud servernení pod kontrolou vývojáře aplikací, například pokud se jedná o webovou službu třetí strany. Thisapproach má také problémy, pokud aplikace musí mluvit s libovolnými servery, jako je webový prohlížeč oremail app.,
aby bylo možné tyto nevýhody řešit, jsou servery obvykle konfigurovány s certifikátyod známých emitentů nazývaných certifikační orgány (CAs).Hostitelské platformě obecně obsahuje seznam známých CAs že věří.Jako Android 4.2 (Jelly Bean), Android v současné době obsahuje více než 100 CAs, které jsou aktualizováno vletech každém vydání. Podobně jako server má CA certifikát a soukromý klíč. Při vydávání certifikátu pro server podepisuje CASERVEROVÝ certifikát pomocí soukromého klíče. Klient pak může ověřit, že server má certifikát vydaný CA známou platformě.,
při řešení některých problémů však použití CAs zavádí další. Protože CA issuescertificates pro mnoho serverů, budete ještě potřebovat nějaký způsob, jak ujistěte se, že jste mluvil na server, který chcete. K řešení tohoto certifikátu vydaného CA identifikuje servereither s určitým názvem, např. gmail.com nebo wildcarded nastavit ofhosts jako *.google.com.
následující příklad bude tyto pojmy trochu konkrétnější., V úryvku pod příkazovým řádkem se příkazopensslnástrojs_client podívá na informace o certifikátu serveru Wikipedie. Itspecifies port 443, protože to je výchozí pro HTTPS. Příkaz sendsthe výstup openssl s_client openssl x509, který formátů informace certifikáty podle X. 509 standard. Konkrétně příkaz požádá o předmět, který obsahuje informace o názvu serveru, a emitenta, který identifikuje CA.,
můžete vidět, že certifikát byl vydán pro servery odpovídající*. wikipedia.org bythe RapidSSL CA.
HTTPS příklad
za Předpokladu, že máte webový server s osvědčení vydané známým CA, můžete vytvořit bezpečnou žádost s kódem assimple toto:
Ano, je to opravdu může být tak jednoduché. Chcete-li přizpůsobit požadavek HTTP, můžete cast toan HttpURLConnection., Android dokumentace proHttpURLConnection má další příklady o tom, jak se vypořádat s requestand hlaviček odpovědí, vkládání obsahu, správa cookies, pomocí proxy, do mezipaměti odpovědi,a tak dále. Ale pokud jde o podrobnosti pro ověření certifikátů a hostitelů, Androidframework se o vás postará prostřednictvím těchto API.To je místo, kde chcete být, pokud je to vůbec možné. To znamená, že níže jsou uvedeny některé další úvahy.,
Běžné problémy ověření certifikátu serveru
Předpokládejme, že místo toho přijímat obsah z getInputStream(), vyhodí výjimku:
To se může stát z několika důvodů, včetně:
- CA, která vydala certifikát serveru byl neznámý
- certifikát serveru nebyl podepsán CA, ale byl self signed
- konfigurace serveru chybí intermediate CA
následující oddíly popisují, jak řešit tyto problémy při zachování yourconnection k serveru bezpečné.,
Neznámé certifikační autority
V tomto případě SSLHandshakeException occursbecause máte CA není důvěryhodný systém. To by mohlo být, protože mají certifikát od nového CA, že ještě není důvěryhodné Android nebo vaše aplikace spuštěna na starší verzi bez CA. Častěji CA je Neznámý, protože to není apublic CA, ale soukromý vydaný organizací, jako je vláda,korporace, nebo vzdělávací instituce pro vlastní potřebu.
naštěstí můžete naučitHttpsURLConnectiondůvěřovat konkrétní sadě CAs., Na procedurecan být trochu zamotané, takže níže je příklad, že bere konkrétní CA froman InputStream, používá k vytvoření KeyStore,který je pak použit k vytvoření a inicializovatTrustManager. TrustManager je to, co systemuses k ověření certifikáty z serverand—tím, že vytvoří jeden z KeyStore s jedním nebo více CAs—thosewill být jen CAs důvěřuje, že TrustManager.,
nový TrustManagerv příkladu inicializuje novou SSLContext, který providesan SSLSocketFactory můžete použít k přepsat výchozíSSLSocketFactoryHttpsURLConnection. Tímto způsobempřipojení použije vaše CAs pro ověření certifikátu.
Zde je příklad vplná pomocí organizační CA z University of Washington:
S vlastní TrustManager, který ví o vašem CAs,systém je schopen validatethat certifikát serveru pocházet z důvěryhodného emitenta.,
upozornění: mnoho webových stránek popisuje špatné alternativní řešení, kterým je instalaceTrustManager, které nic nedělá. Pokud to uděláte, může stejně dobře být šifrování vaší komunikace, protože každý může zaútočit na váš uživatelů na veřejných Wi-Fi hotspotby pomocí DNS triky, aby se poslat své uživatele’traffic přes proxy z jejich vlastní, že předstírá, že je váš server. Útočník pak může zadávat hesla a další osobní údaje., To funguje, protože útočník může generovat osvědčení a—bez TrustManager actuallyvalidates, že certifikát pochází z trustedsource—vaše aplikace by mohla být s nikým mluvit. Tak to nedělej, ani dočasně. Můžete vždy, aby vaše aplikace důvěřovala emitentovi certifikátu serveru, takže to prostě udělejte.
Self-signed certifikát serveru
druhý případ SSLHandshakeException isdue na self-signed certifikát, což znamená, že server se chová jako jeho vlastní CA.,To je podobné neznámé certifikační autoritě, takže můžete použítstejný přístup z předchozí části.
můžete Si vytvořit svůj vlastní TrustManager,tentokrát důvěřovat certifikát serveru přímo. To má všechny thedownsides diskutované dříve vázání aplikace přímo k certifikátu, ale může být provedenočistě. Měli byste však být opatrní, abyste se ujistili, že váš vlastní podepsaný certifikát má areasonably silný klíč. Od roku 2012 je přijatelný 2048bitový RSA podpis s exponentem 65537 exspirace., Při otáčení klíčů byste měli zkontrolovat doporučení od anauthority (například NIST) o tom, co je přijatelné.
Chybějící zprostředkující certifikační autority
třetí případ SSLHandshakeExceptiondochází z důvodu chybějící intermediate CA. Většina publicCAs nepodepisuje serverové certifikáty přímo. Místo toho používají svůj hlavní certifikát CA,označovaný jako kořen CA, k podpisu intermediate CAs. Dělají to tak, aby kořen CA mohl být skladován, aby se snížilo riziko kompromisu., Operační systémy jako Android však typickydůvěřujte pouze root CAS přímo, což zanechává krátkou mezeru důvěry mezi servercertifikátem-podepsaným intermediate CA-a ověřovatelem certifikátu, který zná kořen CA. Chcete vyřešit tenhle server není odeslat pouze klient je certifikát během handshake SSL, buta řetězu certifikátů od CA serveru prostřednictvím některého meziprodukty potřebné k dosažení atrusted root CA.
Chcete-li vidět, jak to vypadá v praxi, zde je pošta.Microsoft.,com certificatechain jako prohlížet openssls_client příkaz:
To ukazuje, že server odešle certifikát pro mail.Microsoft.comissued pomocí Thawte SGC CA, což je meziprodukt, CA, a druhý osvědčenípro Thawte SGC CA vydané Verisign CA, který je hlavním CA, že’strusted Android.
není však neobvyklé nakonfigurovat server tak, aby neobsahoval nutnéintermediate CA., Například, zde je server, který může způsobit chybu v Android prohlížeče, andexceptions v Android aplikací:
Co je zajímavé, je, že návštěva tohoto serveru ve většině plochy browsersdoes není příčinou chyby jako zcela neznámý CA nebo self-signed certifikát serveru wouldcause. Je to proto, že většina stolních prohlížečů cache důvěryhodné intermediate CAs v průběhu času. Jakmile prohlížeč navštíví a dozví se o meziproduktu CA z jednoho webu, nebude muset mít meziprodukt CA zahrnut do certifikačního řetězce příště.,
některé weby to dělají úmyslně pro sekundární webové servery používané k obsluze zdrojů. Forexample, mohou mít svou hlavní stránku HTML obsluhovanou serverem s plným certifikátem, ale mají servery pro zdroje, jako jsou obrázky, CSS nebo JavaScript, které nezahrnují theCA, pravděpodobně pro uložení šířky pásma. Bohužel, někdy tyto servery mohou být poskytoványvěcovou službu, kterou se snažíte volat z aplikace Android, což není tak odpouštějící.
existují dva přístupy k vyřešení tohoto problému:
- nakonfigurujte server tak, aby zahrnoval meziprodukt CA v řetězci serverů., Většina CAs poskytuje dokumentaci o tom, jak to udělat pro všechny běžné webové servery. Toto je jediný přístup, pokud potřebujete web pro práci s výchozími prohlížeči Android alespoň prostřednictvím systému Android 4.2.
- Nebo, léčit intermediate CA stejně jako jakékoliv jiné neznámé CA a vytvořit
TrustManagervěřit to přímo, jak tomu bylo v předchozích dvou částech.
časté problémy s ověřením názvu hostitele
jak je uvedeno na začátku tohoto článku, existují dvě klíčové části pro ověření připojení SSL., První ověření certifikátu je z důvěryhodného zdroje, na který se dříve zaměřili. Zaměření této části je druhá část: ujistěte se, že server, který chcete zobrazit, představuje správný certifikát. Pokud tomu tak není, obvykle uvidíte chybu:
jedním z důvodů, proč k tomu může dojít, je chyba konfigurace serveru. Server isconfigured s certifikátem, který nemá předmět, nebo předmět alternativní název fieldsthat zápas serveru, který se pokoušíte dosáhnout. Je možné použít jeden certifikáts mnoha různými servery., Například, při pohledu na google.com certifikát sopenssl s_client -connect google.com:443 | openssl x509 -text můžete vidět, že subjectthat podporuje *.google.com ale také předmět alternativní názvy pro *.youtube.com,*.android.com a další. K chybě dochází pouze tehdy, když název serveru, ke kterému se připojujete, není certifikátem uveden jako přijatelný.
bohužel se to může stát i z jiného důvodu: virtuální hosting. Při sdílení aserver pro více než jeden název hostitele s HTTP, webový server může říct, z HTTP/1.1 requestwhich cílový hostname klient hledá., Bohužel je to komplikovánohttps, protože server musí vědět, který certifikát se má vrátit, než uvidí HTTPrequest. Chcete-li tento problém vyřešit, novější verze SSL, konkrétně TLSv.1.0 a novější,podpora Server Name Indication (SNI), který umožňuje klientovi SSL zadat zamýšlené jméno serveru, takže správný certifikát může být vrácen.
naštěstí HttpsURLConnection podporuje Android 2.3. Jeden workaroundpokud potřebujete podporovat Android 2.,2 (a starší) je nastavit alternativuvirtuální hostitel na jedinečném portu tak, aby bylo jednoznačné, který certifikát serveru se má vrátit.
drastičtější alternativou je nahradit HostnameVerifiertou, která nepoužívá název virtuálního hostitele,ale ten, který server ve výchozím nastavení vrátil.
Upozornění: Nahrazení HostnameVerifiermůže být velmi nebezpečné, pokud další virtuální hostitele není pod vaší kontrolou, protože anon-pathattacker mohl nasměrovat provoz na anotherserver bez vašeho vědomí.,
Pokud jste stále jisti, že chcete přepsat název hostitele ověření, zde je examplethat nahrazuje ověřovatel pro jeden URLConnections jedním, který stále kontroluje, že název hostitele je alespoň na očekávané aplikace:
Ale pamatujte si, že pokud se ocitnete nahrazení hostname ověření, especiallydue k virtuální hosting, je to stále velmi nebezpečné, pokud další virtuální hostitele není pod vaší kontrolou a vy byste měli najít alternativní hosting arrangementthat vyhýbá tento problém.,
varování před použitím SSLSocket přímo
zatím se příklady zaměřily na HTTPS pomocí HttpsURLConnection.Někdy aplikace potřebují používat SSL odděleně od HTTP. Například, e-mailová aplikace může používat SSL variantsof SMTP, POP3, nebo IMAP. V těchto případech by aplikace chtěla používat SSLSocketpřímo, stejně jako HttpsURLConnection interně.
popsané techniky sofar pro řešení problémů s ověřováním certifikátů platí také pro SSLSocket.,Ve skutečnosti, při použití vlastní TrustManager, co je předán doHttpsURLConnection SSLSocketFactory.Takže pokud potřebujete použít vlastní TrustManagerSSLSocket způsobem postupujte stejným způsobem a použít SSLSocketFactory vytvořitSSLSocket.
upozornění:SSLSocket neprovádí ověření názvu hostitele. Je na vaší aplikaci, aby provedla vlastní ověření názvu hostitele, nejlépe voláním getDefaultHostnameVerifier() s očekávaným názvem hostitele., Dále, že HostnameVerifier.verify()nevyhodí výjimku z chyby, ale místo toho vrátí booleovský výsledek, který musíte implicitně zkontrolovat.
zde je příklad ukazující, jak to můžete udělat. Ukazuje se, že při připojování togmail.com port 443, aniž SNI podporu, obdržíte certifikát formail.google.com. Očekává se, že v tomto případě, takže ujistěte se, že certifikát je opravdu pro mail.google.com:
Denylisting
SSL spoléhá na CAs vydávat certifikáty pouze řádně ověřené ownersof serverů a domén., Ve vzácných případech, CAs jsou buď podveden, nebo, v případě Comodo nebo DigiNotar, porušení,což má za následek certifikáty pro hostname mají být vydány tosomeone jiný, než majitel serveru nebo domény.
aby se toto riziko zmírnilo, má Android Možnost přidat určité certifikáty nebo evenwhole CAs k denylistovi. Zatímco tento seznam byl historicky zabudován do operačního systému, začítv Androidu 4.2 tento seznam lze vzdáleně aktualizovat, aby se vypořádal s budoucími kompromisy.,
Pinning
aplikace se může dále chránit před podvodně vydanými certifikáty atechnique známými jako pinning. To je v podstatě pomocí příkladu uvedeného v neznámé CA caseabove omezit aplikace je důvěryhodný CAs na malou sadu známo, že se používá aplikace, servery. Tím se zabrání kompromisu jednoho z dalších 100 + CAs v systému z toho důvodu, že dojde k porušení zabezpečeného kanálu apps.
klientské certifikáty
tento článek se zaměřil na uživatele SSL pro zabezpečení komunikace se servery., SSL taképodporuje pojem klientských certifikátů, které umožňují serveru ověřit totožnost klienta. Zatímco nad rámec tohoto článku, použité techniky jsou podobné specifikacivlastní TrustManager.
Nogotofail: síťový provoz bezpečnostní nástroj pro testování
Nogotofail je nástroj, který vám dává snadný způsob, jak potvrdit, že vaše aplikace jsou bezpečné proti známo, že TLS/SSL zranitelnosti a chyby konfigurace. Je to automatizovaný, výkonný a škálovatelný nástroj pro testování problémů se zabezpečením sítě na jakémkoli zařízení,jehož síťový provoz by mohl být proveden.,
Nogotofail je užitečný pro tři hlavní případy použití:
- Hledání chyb a zranitelností.
- ověření oprav a sledování regresí.
- pochopení toho, jaké aplikace a zařízení generují jaký provoz.
Nogotofail funguje pro Android, iOS, Linux, Windows, Chrome OS, OSX, ve skutečnosti jakékoli zařízení, které používáte k připojení k internetu. K dispozici je snadno použitelný klient pro konfiguraci nastavení a upozornění na Android a Linux, stejně jako samotný útočný motor, který lze nasadit jako směrovač, VPN server nebo proxy.