Quatro passos para um bom resultado em criptografia de SSL

Por anos, os métodos de criptografia Secure Sockets Layer (SSL) foram fundamentais para a segurança web. Ataques recentes colocaram em dúvida se o SSL e o protocolo subsequente, Transport Layer Security, são as melhores opções para autenticar websites. Críticos dizem que esses métodos são vulneráveis e difíceis de implantar, mas a maioria dos especialistas da indústria insiste que não estão fundamentalmente quebrados – apenas precisam de melhor implantação.

SSL e TLS, ambos geralmente tratados por SSL, são utilizados por todos os cantos da web para autenticar que um website realmente é o que diz ser e que não se trata de um website falso, lançado por phishers e outros ataques para obter dados sigilosos. O SSL também oferece a infraestrutura de criptografia para compartilhar dados com segurança. Está tão bem estabelecida, e a ideia de retirar e substituir por outra tecnologia é tão onerosa, que uma mudança em massa para um novo método não vai acontecer. Devido à sua presença dominante, melhorar o modo como websites programam e implantam SSL parece ser a melhor opção no curto prazo.

“Mesmo que fosse decidido que é uma tecnologia completamente comprometida e quebrada, levaria, pelo menos, dez anos antes que tivéssemos alguma outra tecnologia significativa para substituí-la, se começássemos hoje”, disse Brian Trzupek, vice-presidente de autenticação e identidades gerenciadas da Trustware, autoridade certificada e fornecedor de serviços de segurança. A versão mais recente da tecnologia baseada em SSL – TLS 1.2 – consertou os problemas conhecidos. As vulnerabilidades que sobraram estão “na forma de como SSL é implantada”, disse Trzupek.

O ecossistema monopolizado pelo SSL não é perfeito, mas aqui estão alguns passos que operadores de website podem seguir para otimizar a implantação de SSL, evitando erros que possam colocar em risco dados e clientes de empresas. Estes são os quatro passos iniciais.

Com SSL sob ataque, IPsec vira alternativa de segurança para rede

Certificação SSL: verificação de ID ainda é falha

1. Use protocolos atualizados, suítes Cipher

O SSL é um protocolo elegantemente criado para suportar muitos tipos de ataque. Mas essa afirmação vem com uma importante advertência: para ficar completamente protegido, um website precisa utilizar a última atualização do protocolo SSL e suítes cipher, e os servidores devem estar configurados apropriadamente.  Mas muitas áreas de TI não fazem um bom trabalho nesse aspecto. “A maioria dos servidores SSL são mal configurados”, alega Ivan Ristic, diretor de engenharia da Qualys, empresa fornecedora de segurança de TI, que rastreou 1.2 milhão de servidores de website para estudar as tendências das implantações SSL. “Apenas cerca de 1/3 dos servidores que vimos usar SSL estavam configurados corretamente. É o melhor que pode ser feito no momento.”

A grande maioria dos servidores ainda usa uma versão SSL atrasada em duas atualizações, de acordo com a Qualys. Da mesma forma que é fundamental configurar endpoints com as mais recentes atualizações dos softwares mais seguros, é importante que as empresas utilizem versões SSL atualizadas para minimizar vulnerabilidades que podem ser exploradas em diferentes e sofisticados tipos de ataques. Assim, os negócios precisam pensar com calma sobre as tecnologias Cipher que estão usando com o protocolo SSL, responsáveis pela criptografia em si.

“Tente escolher as maiores e mais complexas chaves que irão funcionar, razoavelmente, em todos os dispositivos que precisar”, disse Tzrupek. Idealmente, empresas devem usar cipher com força 256-bit ou mais fortes.

É um fator muito importante na hora de configurar SSL em um servidor web, disse Ristic, mas existem diversas outras áreas que merecem atenção, especialmente na camada de aplicativos.

Dentre os sites examinados pela Qualys, SSL geralmente não era bem implantando na camada de aplicativo, disse ele. Mesmo sites com SSL configurado corretamente no nível do protocolo, frequentemente se constroem os sites e aplicativos Web de formas que “comprometem completamente SSL e facilitam que ataques explorem esse problema”, disse ele.

Por exemplo, muitos aplicativos web falham ao criptografar o formulário de autenticação que permitem que os usuários comecem a utilizar o aplicativo. “Até nós nos surpreendemos”, disse Ristic. “As pessoas inserem nome de usuário e senha em texto simples, o que facilita a ação de ataques”.

Outra falha comum de configuração é não assegurar, adequadamente, cookies de sessão quando são implantadas, mais uma vez facilitando o acesso de meliantes. Cookies devem ter a palavra “secure” em seu código para estarem a salvo de olhares intrometidos. “Mesmo que seja um servidor com SSL bem configurado, se os cookies de sessão não forem seguros, um ataque pode conseguir esse cookie e apoderar-se da sessão”, explica Ristic. Desenvolvedores precisam prestar atenção nesses erros ao criar novos aplicativos. Com os aplicativos existentes, é muito mais difícil reajustar as falhas cada vez que uma vulnerabilidade é identificada.

2. Gerencie chaves de criptografia apropriadamente

Criptografia traz consigo muita bagagem administrativa. Uma das principais dificuldades é gerenciar as chaves públicas e privadas usadas para criptografar e descriptografar informações conforme elas se movem entre websites e usuários. O usuário final ativa uma chave pública para criptografar os dados transmitidos para o servidor de um website, e o website usa uma chave privada para descriptografar essa informação e exibir o que quer que seja que o usuário espera ver em seu navegador.

As chaves privadas, em particular, devem estar seguras contra ataques e maliciosos internos. Qualquer pessoa com acesso a uma chave privada tem acesso ao certificado que a acompanha; os certificados são confirmações de uma autoridade certificada (CA) que verifica que um website é legítimo. Um meliante pode utilizar uma chave privada roubada e o certificado que a acompanha para autenticar um website falso, que imita o original e engana os visitantes, fazendo-os ceder dados valiosos.

Mas a segurança das chaves privadas dificulta o gerenciamento de um website, levantando os clássicos conflitos entre segurança e conveniência. Servidores web SSL devem ser capazes de acessar chaves privadas sem que administradores de TI tenham de ser envolvidos. Operadores de sites tendem a utilizar atalhos, armazenando chaves com pouca ou nenhuma segurança para não interromper a entrega do conteúdo web para o usuário final.

“Você precisa dessas chaves disponíveis sempre que precisar”, disse Jeff Schmidt, fundador e CEO da JAS Global Advisors, uma empresa de consultoria especializada em TI, governança de risco e risco de tecnologia estratégica. “Ao mesmo tempo, é preciso garantir que apenas as pessoas certas tenham acesso a elas”. Na maioria das empresas, a chave privada permanece sem criptografia no servidor web para que possa ser utilizada sem que seja necessário que alguém utilize uma senha, um cartão ou qualquer outro dispositivo que exija login e senha, conta Schmidt.

O que isso significa é que quando um servidor web é comprometido – o que inevitavelmente acontece devido às ameaças cotidianas no ambiente – o meliante obtém acesso a essas chaves e pode usá-las para configurar um servidor falso. E, enquanto muitos operadores de website sabem que quando um servidor web é comprometido uma nova máquina virtual deve ser iniciada com novos certificados e novas chaves privadas, eles não se preocupam em fazer tais mudanças.

“Vimos casos em que um servidor web foi comprometido, um novo servidor foi criado, mas o certificado não foi alterado e o a chave privada estava em mãos erradas”, conta Schmidt. E com essa chave, o meliante pode continuar criando certificados falsos tranquilamente e imitando o site.

Uma forma óbvia de proteger chaves públicas ou privadas é nunca armazená-las no servidor web. A chave privada, em especial, deve ser sempre armazenada em outro lugar. Da mesma forma, não armazene chaves privadas em servidores FTP ou as envie por e-mail por algum motivo. Usar esses canais inseguros para compartilhar ou armazenar chaves, deixam-nas disponíveis para hackers, assim como para qualquer pessoa dentro da empresa que tenha conhecimento mínimo sobre sistemas protegidos por SSL. “De repente, você acaba com seu esquema de segurança, com sua credibilidade e todo o resto”, disse Jeff Hudson, CEO da Venafi, empresa fornecedora de gerenciamento de criptografia.

A solução é usar uma ferramenta de gerenciamento de chave para segregar chaves públicas e privadas e garantir que as pessoas que gerenciam sistemas SSL não tenham acesso às chaves privadas. Administradores de sites também não devem ser os responsáveis pelas chaves, mantenha as funções separadas.

3. Cuide dos Certificados

Além de gerenciar mal as chaves de criptografia, operadores de websites baseados em SSL tendem a fazer um péssimo trabalho gerenciando os certificados em si. Os certificados estão presentes em milhares de negócios que rodam intranets seguras, grandes sites de e-commerce e outros websites que lidam com dados sigilosos. Ao lidar com um grande número de certificados, as empresas tendem a espalhar a responsabilidade por diversos servidores e operadores de sites, o que pode, rapidamente, levar ao caos.

Grandes varejistas e outras empresas geralmente sequer sabem quantos certificados têm, de acordo com Hudson. Uma grande varejista recentemente contou a ele que tinha 15 mil certificados. Quando sua equipe verificou a infraestrutura da empresa, encontrou o dobro. Segundo uma recente pesquisa realizada pela Osterman Research e pela Venafi, 54% das empresas não têm inventário exato de certificados digitais.

Um problema crítico com o gerenciamento distribuído de certificados é que não existe uma pessoa ou um grupo rastreando a data de expiração desses certificados. Eles geralmente expiram sem que ninguém perceba e os clientes e outros usuários que tentam acessar informações são avisados que tal certificado é questionável, e podem até serem impedidos de acessar informações que precisam.

“O que sempre acaba acontecendo é o certificado expira, clientes são bloqueados, o telefone não para de tocar, cabeças rolam, eles renovam o certificado e tudo volta como antes”, disse Trzupek. Enquanto isso, a empresa se queima cada vez que um cliente recebe um aviso de segurança sobre um certificado expirado.

Você também não quer o cenário em que seus clientes e outros usuários recebam tantos avisos de certificado expirado que passem a esperá-los e automaticamente cliquem em “OK”. Isso prejudica o processo de verificação do certificado e deixa o site completamente vulnerável em caso de ataque.

Além de não rastrear os certificados, muitas empresas não têm políticas ou não reforçam as políticas existentes sobre como os certificados são comprados e de quem. Programadores, na pressa de lançar um website, vão a qualquer CA (autoridade certificada) que ofereça um certificado rápido, sem se preocupar se está ou não na lista de CAs aprovados pela empresa. Mas um certificado aleatório, oferecido por uma CA de fraca reputação pode não ser tão seguro quanto um oferecido por uma CA de boa reputação com melhor padrão de segurança.

Muitas empresas enfrentam esse tipo de problema com políticas internas, contou Hudson. Por exemplo, um gerente de uma grande empresa de e-commerce alega ter políticas sólidas que ditam quem podem instalar certificados e de onde eles devem vir. Mas a equipe de Hudson descobriu em seus sites diversos certificados que não estavam de acordo com aquela política, usando um fornecedor que não estava na lista de aprovados.

“Nós dissemos: “Desculpe, mas fizemos esses mapeamentos ontem e encontramos esses três certificados Go Daddy”, e o cara se levantou, bateu com o punho na mesa e disse: “Eu disse pra eles não fazerem isso””, contou Hudson.

Quando o gerenciamento de certificados é feito manualmente e as políticas sobre a proveniência de um certificado não são reforçadas, as empresas se abrem para o risco de não saber se estão ou não expostas quando uma CA sofre uma brecha, como nos casos da DigiNotar e Comodo, no ano passado. A pesquisa da Osterman, em parceria com a Venafi, mostrou que 72% das empresas não têm processos automatizados para substituição de certificados se uma das CAs tiver brecha.

Para obter controle do processo de gerenciamento de certificados, considere ferramentas que automatizem o processo de descoberta de certificados. Essas ferramentas rastreiam certificados e ativam um sistema automático que cuida da renovação conforme eles expiram. Uma vez feito isso, centralize o processo todo, de preferência usando uma plataforma de gerenciamento de certificados que permita que um administrador central cuide de todos os certificados, enviando-os às unidades de negócio e servidores quando requisitados e reforçando as políticas da empresa por toda a organização.

“Você quer uma plataforma que possa acomodar um administrador que supervisiona todos os diferentes certificados, mas que também possa ser distribuída, para que indivíduos responsáveis por servidores individuais possam acessar um sistema central e fazer pedidos”, disse Deena Thomchick, diretora de marketing de produtos da Symantec. Entrust, RSA, Symantec, Trustwave e Venafi estão entre as empresas que oferecem sistemas de gerenciamento de ciclo de vida de certificados.

4. Evite conteúdo misto

Conteúdo misto é quando empresas usam SSL em uma página dentro de um website, mas oferece conteúdo, naquela página, que não é protegido por SSL. Isso abre uma lacuna que pode ser explorada. Meliantes podem interceptar conteúdo não criptografado e alterar seus objetivos. Se a porção descriptografada do site puder rodar scripts, hackers podem executar ataques perigosos, como tentativas de ataque a DNS, quando o tráfego do website é redirecionado para o site do hacker.

Sempre que tiver uma conexão HTTPS segura por SSL, você deve não trazer, para seu domínio, conteúdo de outros locais que sejam enviados por HTTP desprotegido, disse Nicholas Percoco, VP sênior da divisão de pesquisa SpiderLabs, da Trustwave. “Você deve garantir que todas as páginas estejam protegidas por SSL e que foram testadas”, disse ele.

Da mesma forma, garanta que todos os formulários que clientes e outros usuários enviam usem SSL, para que, caso um cliente clique no link “Contato”, no meio de uma transação de e-commerce, ele não receberá um aviso dizendo  que “Parte da página em que você navega não é criptografada”.

O problema do conteúdo misto é, particularmente, um problema com certificados Extended Validation SSL, disse Trzupek. Certificados EV SSL estão um nível acima do certificado normal, e mais comumente usado, Domain Validation SSL, que exige a validação mínima de que você é a pessoa que detém os direitos sobre o domínio a ser assegurado pelo certificado SSL. Os certificados EV SSL custam mais e exigem um extenso processo para donos de sites provarem que são quem dizem ser. Sites usando certificados EV SSL apresentam uma barra verde na barra de endereço no navegador para indicar que estão protegidos por EV SSL. Os sites protegidos por Domains Validation SSL são indicados por um cadeado.

Se você puser um certificado EV em um site e depois incluir recursos JavaScript apenas SSL, a navegação será rebaixada para SSL normal, segundo Trzupek. “Muitas empresas compram um maravilhoso certificado EV, ativam seu novo website e a barra não fica verde. E eles não compreendem por que”.

Muitas autoridades certificadas reduziram o preço dos certificados EV adicionais depois que uma empresa inicialmente compra EV SSL para reduzir o custo com a implantação de certificados EV pelo site, disse Trzupek. Mas ainda é um problema porque muitos operadores de website não sabem que devem ficar atentos a conteúdo misto.

Vigilância é a única forma de evitar conteúdo misto. Empresas devem realizar extensos testes e processos de garantia de qualidade para que conteúdo misto não seja permitido no desenvolvimento de sites ou aplicativos.

Tim Moses, diretor de segurança avançada da Entrust, vê dois tipos de clientes comprando certificados hoje: o que querem o impulso do marketing que vem com um indicador de confiabilidade – seja a barra verde ou o cadeado – “E eles farão o que for preciso para ter esse indicador”, disse ele. “E tem, também, o operador de website que realmente leva a sério o usuário final e faz o que pode para protegê-los contra ataques”.

Então, qual o caso da sua empresa? Se for apenas caso de marketing, saiba que somente comprar certificados EV não é garantia de segurança para seu site. É preciso considerar, também, como os servidores SSL estão configurados, como as chaves são gerenciadas, como os certificados são comprados e se o site tem ou não conteúdo misto. Esses passos são essenciais para manter o controle da criptografia web em sua empresa.

Tradução: Rheni Victório, especial para o IT Web | Revisão: Adriele Marchesini