segurança com HTTPS e SSL

a camada segura Sockets (SSL)—agora tecnicamente conhecida como Transport Layer Security(TLS) – é um bloco de construção comum para comunicações criptografadas entre clientes e servidores. É possível que uma aplicação possa usar o SSL incorretamente, de modo que entidades maliciosas talvez possam interceptar os dados de um aplicativo através da rede., Para ajudá-lo a garantir que isso não aconteça com o seu aplicativo, este artigo destaca as armadilhas comuns ao usar protocolos de rede seguros e aborda algumas preocupações maiores sobre o uso de infra-estrutura de chave pública (PKI).

também deve ler a visão geral da Androidsegurança, bem como a visão geral das permissões.

Concepts

In a typical SSL usage scenario, a server is configured with a certificate containing apublic key as well as a matching private key., Como parte do aperto de mão entre um servidor de cliente SSL, o servidor prova que ele tem a chave privada assinando seu certificado com criptografia de chave pública.

no Entanto, qualquer pessoa pode produzir o seu próprio certificado e chave privada, de modo que um simples handshakedoesn não prova nada sobre o servidor que o servidor sabe que a chave privada thatmatches a chave pública do certificado. Uma maneira de resolver este problema é ter o clienth tem um conjunto de um ou mais certificados que ele confia. Se o certificado não estiver no conjunto, o servidor não é de confiança.,

Existem várias desvantagens nesta abordagem simples. Os servidores devem ser capazes de passar a chaves mais fortes ao longo do tempo (“rotação de chaves”), que substitui a chave pública no certificado por uma nova. Infelizmente, agora o aplicativo cliente tem que ser atualizado devido ao que é essencialmente uma mudança de configuração do servidor. Isto é especialmente problemático se o serveris não estiver sob o controle do desenvolvedor do aplicativo, por exemplo se for um serviço web de terceiros. This approach also has issues if the app has to talk to arbitrary servers such as a web browser oremail app.,

A fim de abordar estas desvantagens, os servidores são normalmente configurados com certificados de emitentes bem conhecidos denominados autoridades de Certificação (CAs).A plataforma host geralmente contém uma lista de CAs bem conhecidos que ele trusts.As do Android 4.2 (Jelly Bean), o Android contém atualmente mais de 100 CAs que são atualizados em cada versão. Semelhante a um servidor, uma AC tem um certificado e uma chave privada. Ao emitir um certificado para um servidor, a AC assina o certificado do servidor utilizando a sua chave privada. O cliente pode então verificar se o servidor tem um certificado emitido por uma AC conhecida da plataforma.,no entanto, ao resolver alguns problemas, o uso de CAs introduz outro. Uma vez que o issuescertificates da CA para muitos servidores, você ainda precisa de alguma forma para se certificar de que está a falar com o servidor que deseja. Para o efeito, o certificado emitido pelo CA identifica o servidor com um nome específico, como gmail.com ou um conjunto selvagem de lugares como *.google.com o exemplo seguinte tornará estes conceitos um pouco mais concretos., In the snippet below from a command line, the openssltool’s s_client command looks at Wikipedia’s server certificate information. Ele especifica o porto 443 porque este é o padrão para HTTPS. O comando envia a saída de openssl s_clientpara openssl x509, que formata a informação sobre certificados de acordo com a norma X. 509. Especificamente, o comando pede o assunto, que contém a informação do nome do servidor, e o emissor, que identifica a CA.,

pode ver que o certificado foi emitido para servidores correspondentes a *.wikipedia.org pelo RapidSSL CA.

um exemplo de HTTPS

assumindo que você tem um servidor web com acertificato emitido por uma ACA bem conhecida, você pode fazer um pedido seguro com o código assimple isto:

Sim, ele realmente pode ser tão simples. Se você quiser adaptar o pedido HTTP, você pode lançar toan HttpURLConnection., A documentação Android paraHttpURLConnection tem mais exemplos sobre como lidar com os cabeçalhos de requisição e resposta, postando conteúdo, gerindo cookies, usando proxies, respostas de cache,e assim por diante. Mas em termos de detalhes para verificar certificados e nomes de host, o quadro Androidframework cuida dele para você através destas APIs.É aqui que queres estar, se possível. Dito isto, abaixo estão algumas outras considerações.,

problemas Comuns de verificar os certificados de servidor

Suponha que em vez de receber o conteúdo de getInputStream(), ele lança uma exceção:

Isso pode acontecer por vários motivos, incluindo:

1. A autoridade de CERTIFICAÇÃO que emitiu o certificado do servidor foi desconhecido
2. O certificado do servidor não foi assinado por uma autoridade de CERTIFICAÇÃO, mas foi auto-assinado
3. A configuração do servidor está faltando uma autoridade de CERTIFICAÇÃO intermediária

as seções A seguir discutem como resolver estes problemas, mantendo o yourconnection para o servidor seguro.,

Autoridade de certificação desconhecida

neste caso, oSSLHandshakeException ocorre porque você tem uma AC que não é confiável pelo sistema. Pode ser porque você tem um certificado de uma nova CA que ainda não é confiável pelo Android ou seu app isrunning em uma versão mais antiga sem a CA. Mais frequentemente um CA é Desconhecido porque não é um ca público, mas um privado emitido por uma organização como um governo,corporação ou instituição de educação para seu próprio uso.

felizmente, você pode ensinar HttpsURLConnection para confiar em um conjunto específico de CAs., O procedurecan ser um pouco complicado, por isso abaixo está um exemplo que leva uma autoridade de CERTIFICAÇÃO específica froman InputStream, usa-o para criar uma KeyStore,que é usado para criar e inicializar umTrustManager. A TrustManager é o que o sistematiza para validar certificados do servidor—criando um a partir de um KeyStore com um ou mais CAs—thosew será o único CAs confiável por esse TrustManager.,

de acordo com a nova TrustManager,a exemplo inicializa uma nova SSLContext que providesan SSLSocketFactory você pode usar para substituir o padrãoSSLSocketFactory deHttpsURLConnection. Desta forma, a ligação utilizará o seu CAs para a validação do certificado.

Aqui está o exemplo infull usando uma CA organizacional da Universidade de Washington:

Com um personalizado TrustManager que sabe sobre o seu CAs,o sistema é capaz de validatethat seu certificado de servidor vir a partir de um emissor confiável.,

cuidado: muitos sites descrevem uma solução alternativa pobre que é instalar um TrustManager que não faz nada. Se você fizer isso, você pode muito bem não estar criptografando sua comunicação, porque qualquer um pode atacar seus usuários em um hotspotby Wi-Fi público usando DNS tricks para enviar o traffic de seus usuários através de um proxy próprio que finge ser o seu servidor. O atacante pode então ordenar senhas e outros dados pessoais., Isto funciona porque o atacante pode gerar acertificato e-sem um id

que na verdade valida que o certificado vem de uma fonte fidedigna—o seu aplicativo pode estar falando com qualquer um. Por isso, não faças isto, nem temporariamente. Você pode sempre fazer com que o seu aplicativo confie no emissor do certificado do servidor, por isso, basta fazê-lo.

certificado de servidor autossignado

o segundo caso de SSLHandshakeException é devido a um certificado autossignado, o que significa que o servidor está se comportando como sua própria CA.,Isto é semelhante a uma autoridade de certificado desconhecida, por isso pode usar a mesma abordagem da secção anterior.

pode criar o seu próprio TrustManager,desta vez confiando directamente no certificado do servidor. Isto tem todas as partes baixas discutidas anteriormente de amarrar o seu aplicativo diretamente a um certificado, mas pode ser donesecom segurança. No entanto, deve ter o cuidado de certificar-se de que o seu certificado assinado por si próprio tem uma chave razoavelmente forte. A partir de 2012, uma assinatura RSA de 2048 bits com um expoente de 65537 expiryearly é aceitável., Ao rodar as chaves, você deve verificar as recomendações de anauthority (como NIST) sobre o que é aceitável.o terceiro caso de SSLHandshakeException ocorre devido a uma CA intermédia em falta. A maioria das publicCAs não assinam certificados de servidor directamente. Em vez disso, eles usam o seu certificado AC principal, referido como o root CA, para assinar CAs intermediário. Eles fazem isso para que a root CA possa ser armazenada para reduzir o risco de compromisso., No entanto, sistemas operacionais como Android typicalytrust só root CAs diretamente,o que deixa um curto intervalo de confiança entre o servertificato—assinado pela AC intermediária—e o verificador de certificado, que conhece a AC raiz. Para a solvethis, o servidor não envia o cliente apenas o seu certificado durante o aperto de mão SSL, mas uma cadeia de certificados da AC do servidor através de quaisquer intermediários necessários para alcançar a AC raiz confiável.

para ver como isto se parece na prática, aqui está o correio.o.,com certificatechain como visto pelo openssls_client comando:

Isso mostra que o servidor envia um certificado para o e-mail.o.comissued by the Thawte SGC CA, which is an intermediate CA, and a second certificatefor the Thawte SGC CA issued by a Verisign CA, which is the primary CA that ‘ structused by Android.

no entanto, não é incomum configurar um servidor para não incluir a necessária inter-mediata CA., Por exemplo, aqui está um servidor que pode causar um erro em navegadores Android e exceções em aplicativos Android:

O que é interessante notar aqui é que visitar este servidor na maioria dos navegadores desktop não causa um erro como uma AC completamente desconhecida ou certificado de servidor auto-assinado wouldcause. Isto é porque a maioria dos navegadores de desktop cache confiável CAs intermediário ao longo do tempo. Oncea browser visitou e aprendeu sobre uma AC intermediária de um site, não precisará ter a AC intermediária incluída na cadeia de certificados da próxima vez.,

alguns sites fazem isso intencionalmente para servidores web secundários usados para Servir Recursos. Por exemplo, eles podem ter sua página HTML principal servida por um servidor com um certificado completo, mas têm servidores para recursos como imagens, CSS, ou JavaScript não incluem theCA, presumivelmente para economizar largura de banda. Infelizmente, às vezes estes servidores podem estar providenciando um serviço web que você está tentando ligar de seu aplicativo Android, que não é tão indulgente.

Existem duas abordagens para resolver este problema:

• Configure o servidor para incluir a AC intermediária na cadeia do servidor., A maioria dos CAs fornecem documentação sobre como fazer isso para todos os servidores web comuns. Esta é a única abordagem se você precisar do site para trabalhar com navegadores Android padrão, pelo menos através do Android 4.2.
• ou, tratar a AC intermediária como qualquer outra AC desconhecida, e criar um TrustManager para confiar nela diretamente, como feito nas duas seções anteriores.

problemas comuns com a verificação do nome da máquina

como mencionado no início deste artigo,existem duas partes-chave para verificar uma ligação SSL., A primeira é verificar o certificado é de uma fonte confiável, que foi o foco da seção anterior. O foco desta seção é a segunda parte: certificar-se de que o servidor que você está chamando apresenta o certificado certo. Quando isso não acontecer, você tipicamente verá um erro como este:

uma razão pela qual isso pode acontecer é devido a um erro de configuração do servidor. O servidor está configurado com um certificado que não tem um assunto ou um nome alternativo de assunto fields que correspondem ao servidor que você está tentando alcançar. É possível usar um certificado com muitos servidores diferentes., Por exemplo, olhando para o google.com certificado comopenssl s_client -connect google.com:443 | openssl x509 -text você pode ver que um subjectthat suporta *.google.com mas também nomes de alternativo de assunto para *.youtube.com,*.android.com e outros. O erro só ocorre quando o nome do servidor ao qual você está conectando não está listado pelo certificado como aceitável.

infelizmente isso pode acontecer por outra razão também: hospedagem virtual. Ao compartilhar aserver por mais de um nome de máquina com HTTP, o servidor web pode dizer a partir do requisitode HTTP/1.1 qual o nome de destino que o cliente está procurando., Infelizmente isso é complicado com https, porque o servidor tem que saber qual certificado retornar antes que ele veja o HTTPrequest. Para resolver este problema, versões mais recentes de SSL, especificamente TLSv.1.0 e mais tarde, a indicação de nome do servidor de suporte (SNI), que permite ao cliente SSL especificar o nome intendedhostname para o servidor para que o certificado adequado possa ser devolvido.

felizmente, HttpsURLConnection supportsSNI desde Android 2.3. Um workaroundif que você precisa para suportar Android 2.,2 (e mais antigo) é a criação de um host alternativevirtual em um porto único para que seja inequívoco que Certificado de servidor para retornar.

A alternativa mais drástica é substituir HostnameVerifierpor uma que não use o nome da sua máquina virtual, mas a que é devolvida pelo servidor por omissão.

Atenção: Substituir HostnameVerifierpode ser muito perigosa se o virtual host esteja sob o seu controle, porque anon-pathattacker pode direcionar o tráfego para anotherserver sem o seu conhecimento.,

Se você ainda certeza de que deseja substituir hostname verificação, aqui é um examplethat substitui o verificador para um único URLConnectioncom o que ainda se verifica que o nome do host é pelo menos o esperado pelo aplicativo:

Mas lembre-se: se você encontrar-se a substituição de nome de host de verificação, especiallydue para hospedagem virtual, ainda é muito perigoso se o virtual host esteja sob o seu controle e você deve encontrar uma alternativa de hospedagem arrangementthat evita esse problema.,

avisos sobre o uso do SSLSocket diretamente

até agora, os exemplos têm focado em HTTPS usando HttpsURLConnection.Às vezes, os aplicativos precisam usar SSL separados de HTTP. Por exemplo, um aplicativo de E-mail pode usar as variantes SSL de SMTP, POP3 ou IMAP. Nesses casos, o aplicativo iria querer usar SSLSocketdiretamente, da mesma forma que HttpsURLConnection faz internamente.

As técnicas descritas para lidar com questões de verificação de certificados também se aplicam a SSLSocket.,Na verdade, ao usar um personalizado TrustManager, que é passado paraHttpsURLConnection é um SSLSocketFactory.Então, se você precisa usar um personalizado TrustManager com umSSLSocket, followthe mesmos passos e utilizar-se de que SSLSocketFactory para criar o seuSSLSocket.

cuidado:SSLSocket não efectua a verificação do nome da máquina. Cabe ao seu aplicativo fazer a sua própria verificação do hostname, preferencialmente chamando getDefaultHostnameVerifier() com o hostname esperado., Alémdisso, existe que HostnameVerifier.verify()não abre uma excepção ao erro, mas em vez disso devolve um resultado booleano que deverá verificar explicitamente.

aqui está um exemplo mostrando como você pode fazer isso. Mostra que ao ligar togmail.com Porto 443 sem suporte SNI, receberá um certificado formail.google.com. isto é esperado neste caso, por isso verifique se o certificado é realmente para mail.google.com:

Denilisting

SSL depende fortemente de CAs para emitir certificados para apenas os servidores e domínios devidamente verificados., Em casos raros, CAs são ou enganados ou, no caso do Comodo ou DigiNotar,violados, resultando nos certificados para um nome de máquina a ser emitido para alguém que não o proprietário do servidor ou domínio.

A fim de mitigar este risco, o Android tem a capacidade de adicionar certos certificados ou até mesmo CAs para um denilista. Esta lista pode ser remotamente atualizada para lidar com futuros compromissos.,um app pode proteger-se ainda mais dos certificados emitidos de forma fraudulenta pela atechnique conhecida como pinning. Isto é basicamente usando o exemplo fornecido no caseabove CA desconhecido para restringir o CAs confiável de um aplicativo para um pequeno conjunto conhecido por ser usado pelos servidores do aplicativo. Este facto impede que um dos outros 100 CAs do sistema comprometa uma violação do canal de segurança do apps.

certificados do cliente

este artigo centrou-se no utilizador de SSL para garantir a segurança das comunicações com os servidores., O SSL também apoia a noção de certificados de clientes que permitem ao servidor validar a identidade do aclient. Embora para além do âmbito deste artigo, as técnicas envolvidas são semelhantes a uma personalização TrustManager.

nogotofail: uma ferramenta de teste de segurança de tráfego de rede

nogotofail é uma ferramenta que lhe dá uma forma fácil de confirmar que os seus aplicativos são seguros contra vulnerabilidades TLS/SSL conhecidas e erros de configuração. É uma ferramenta automatizada, poderosa e escalável para testar problemAs de segurança de rede em qualquer dispositivo cujo tráfego de rede pode ser feito para passar por ela.,

nogotofail é útil para três casos principais de uso:

• encontrando bugs e vulnerabilidades. a verificar as correcções e a observar as regressões.
• compreender que aplicações e dispositivos estão gerando que Tráfego.

nogotofail trabalha para Android, iOS, Linux, Windows, Chrome OS, OSX, de facto, qualquer dispositivo que use para se ligar à Internet. Há um cliente fácil de usar para configurar as configurações e obter notificações no Android e Linux, bem como o próprio motor de ataque que pode ser implantado como um roteador, servidor VPN, ou proxy.