Quem nunca leu um guia de segurança recomendando atenção ao famoso “cadeado” no navegador web? O que dá a essa dica seu valor é uma cadeia de confiança. Mas, por mais que tenha sido repetida, poucos sabem como funciona a segurança SSL, cuja única representação ao usuário se dá por meio do cadeado de segurança em páginas ‘https’. Os internautas não sabem que seus navegadores estão confiando em uma AC — Autoridade Certificadora — nem por que essa AC merece confiança.
Informações divulgadas nas últimas semanas mostraram que algumas ACs não estão cumprindo com sua parte do “acordo”, deixando brechas para que toda a cadeia de confiança seja quebrada. Mesmo assim, os desenvolvedores de navegadores — responsáveis por escolher quais ACs merecem confiança — viram-se desprovidos de qualquer força, dado a quantidade de sites que apresentariam problemas se decidissem deixar de confiar nas ACs afetadas.
O que é e como funciona o SSL
O SSL (“Secure Sockets Layer”) tem dois objetivos. O primeiro deles é garantir que o site que você está visitando é realmente quem diz ser. Ou seja, ele busca impedir os criminosos de redirecionar os usuários a websites falsos, não controlados pelos verdadeiros donos do domínio. Para realizar um ataque desse tipo, o invasor teria que comprometer algum sistema do provedor do internauta. A brecha do DNS possibilitava isso, por exemplo.
O outro objetivo é criptografar, ou “embaralhar” a transmissão. Dessa maneira, se o criminoso tiver o controle sobre qualquer sistema pelo qual a conexão passar, ele não conseguirá ler o conteúdo. As senhas e dados estarão protegidos contra “grampos”.
A parte da criptografia é fácil. Qualquer certificado[1. Certificados possuem no mínimo dois arquivos, conhecidos como a “chave pública” e a “chave privada”. A chave pública é enviada ao navegador web, que utiliza-a para “embaralhar” a transmissão. Somente o site possuidor da chave privada é capaz de “desembaralhar” o que foi transmitido.], mesmo os certificados expirados, inválidos ou criados pelo próprio dono do site teriam esse efeito. O problema é a garantia de que o site é mesmo aquele que você está visitando. Como qualquer um pode emitir um certificado garantindo a autenticidade do site, foi preciso elaborar um sistema que validasse os certificados.
Criou-se então as chamadas “Certificate Authorities” (CA) ou Autoridades Certificadoras (AC). O dono de um site, após criar o certificado, envia-o para uma CA, que o assina e garante sua validade. É claro que, antes da assinar o certificado, a AC deveria verificar que quem gerou aquele certificado é realmente o dono do site.
O navegador web, por sua vez, inclui o certificado (chave pública) das ACs. Toda vez que um certificado legítimo, assinado e garantido por uma AC for enviado por um site, o navegador pode atestar sua veracidade com base na chave pública instalada. Isso também garante que a checagem dos certificados não dependa da internet, tornando-a mais segura. Se o certificado não for assinado por um AC confiada, uma mensagem de erro será exibida.
Em outras palavras, o navegador confia na segurança da AC e por isso considera o certificado válido. Se a chave usada por um site for assinado por uma AC desconhecida, o navegador irá exibir um erro. Isso pode ser facilmente percebido hoje no site da ICP-Brasil: enquanto o Firefox exibe um aviso de “certificado não confiado”, o Internet Explorer 7 o abre sem problemas. Isso porque o certificado AC da ICP-Brasil, que assinou a chave usada pelo site, já está instalado no IE por padrão, mas não no Firefox.
Erros de segurança básicos em ACs
No final de 2008, dois eventos abalaram a credibilidade de algumas ACs. Primeiro, um especialista em segurança ligado à StartSSL, uma AC, descobriu que um revendedor de outra AC, a Comodo, não estava verificando as credenciais do solicitante do certificado. Por isso, ele conseguiu obter um certificado para o site “mozilla.com” sem ter qualquer ligação com a Mozilla.
A verificação de titularidade de domínio é uma das tarefas mais básicas que uma AC deve realizar, porém não há incentivo econômico direto para isso. Sempre que a emissão de um certificado é negada, a empresa deixa de ganhar dinheiro. O que incentiva as empresas a emitir apenas certificados seguros é a ameaça de serem retiradas da lista de empresas confiadas pelos navegadores: sem estarem nessa lista, nenhum certificado tem valor e elas ficam impedidas de continuar seu negócio.
Uma semana depois dessa revelação, vários pesquisadores de segurança divulgaram um experimento técnico e complicado que provou a vulnerabilidade das assinaturas feitas com a tecnologia MD5. Eles descobriram que várias ACs ainda utilizavam MD5 para assinar certificados, dentre elas a RapidSSL, associada à VeriSign, a maior empresa do ramo.
A VeriSign “reclamou” que os pesquisadores não entraram em contato para avisá-los do problema. A questão, no entanto, é que ataques de “colisão” no MD5 — como o usado no experimento — são considerados possíveis desde 2004. As empresas tiveram praticamente quatro anos para migrar para uma tecnologia mais segura, como o SHA-1 e suas variações, mas não o fizeram.
O que se percebe é uma inércia perigosa e inaceitável para empresas que lidam com uma parte tão importante da infraestrutura da internet.
Quão ruim uma AC pode ser?
Apesar de terem errado em aspectos básicos da segurança de sua operação, as duas ACs não foram retiradas da lista de entidades confiadas pelos navegadores. Por quê? Porque muitos sites legítimos iriam parar de funcionar.
Nesse momento, vê-se que as relações de incentivos foram desestabilizadas. As ACs não podem emitir qualquer certificado que quiserem porque precisam da confiança dos navegadores. Mas, por serem grandes e responsáveis por muitos sites, os navegadores temem causar problemas demais caso venham a tirar as empresas afetadas pelos problemas da lista de ACs confiadas.
Ficam no ar as perguntas: quão ruim uma AC pode ser? Quantos erros elas podem cometer até que uma modificação na lista de ACs confiadas seja considerada? Será que as empresas envolvidas fossem menores a reação teria sido a mesma?
O mais triste, talvez, é que poucos saibam disso tudo, mas mesmo assim confiam nos cadeados de segurança — pelo menos quando não clicam direto em qualquer mensagem que aparece na tela.
Veja também
- Pesquisa Mostra Viabilidade de Ataques de “Colisão” com MD5 — Negócio de Risco / Microsoft
Linha Defensiva 
Altieres, acho que você está errado aqui. Os fabricantes de browsers jamais deixariam de remover uma Autoridade Certificadora porque muitos sites legítimos deixariam de funcionar. Pelo contrário – se muitos sites legítimos (e os seus usuários) estivessem em risco devido a uma AC insegura aí é que os fabricantes de browsers iriam agir ainda com mais prioridade para fazer esta remoção. Eles estariam fazendo a estes sites e aos seus usuários um favor e não causando um problema.
Se você quiser analisar do ponto de vista de incentivos, de um lado os browsers dependem totalmente da confiança dos seus usuários (ainda mais por serem gratuitos). Se um browser é visto como não confiável ele perde market share e faturamento. Do outro lado eles não dependem em nada das ACs: as ACs não são fonte de receita para eles, e as empresas que fabricam browsers (Microsoft, Apple, Google) por acaso são muitíssimo maiores que as empresas certificadoras. Qual seria o incentivo para manter uma AC insegura na sua lista de ACs confiáveis? Não faz o menor sentido.
CurtirCurtir
@Cima
Vamos supor que a AC do certificado de um banco Z foi removido da lista de confiáveis por um certo navegador, mas não por outro, que o usuário já usa.
O usuário então troca de navegador, e vê que a página do seu banco exibe um erro. Ele não tem a mínima noção do que é uma AC, nem por que a AC do banco dele devia ter sido removida.
E agora imagine se a AC for realmente grande e vários outros sites começarem a ter o mesmo problema. E imagine se o navegador for um com pouco market share, tipo o Opera ou Konqueror — ninguém vai ligar pra isso para chegar a alterar seu certificado.
Nesse caso temos as seguintes possibilidades:
1. O usuário vai achar que esse segundo navegador que removeu a AC é ruim e voltar para o anterior. Isso provaria que não foi um “bom negócio” para o navegador ter removido a AC. É verdade que os navegadores são gratuitos, mas eles têm motivo sim para querer market share.
2. Se não ,isso, o internauta vai adicionar uma exceção para o certificado do site sem nem saber o que exatamente está acontecendo. Nesse caso, poderia-se dizer que o sistema inteiro do SSL está quebrado sem muito exagero.
Na minha humilde opinião, os erros que foram detectados nestas ACs foram crassos demais. Eu só gostaria de saber qual o tamanho do erro que seria necessário para que uma AC fosse removida, porque todos os navegadores terão de concordar para fazer isso.
CurtirCurtir
Altieres, este seu exemplo não existe. Se um usuário tenta acessar o site de um banco e não consegue porque o certificado está inválido, ele simplesmente não acessa o site. E liga reclamando para o banco. Que sai correndo para mudar o certificado para uma outra AC que seja aceita por todos os browsers.
São as ACs que dependem dos browsers, e não o contrário. Se uma AC deixar de ser aceita pelo Internet Explorer por exemplo ela está fora do mercado.
Se um dia a Microsoft entender que os usuários estão em risco se confiarem nos certificados de uma determinada AC ela vai remover prontamente esta AC do Windows. E posso te garantir que não pedir a concordância de nenhum navegador para fazer isso.
CurtirCurtir
@Cima
É justamente isso que eu pergunto no artigo. Que tipo de erro ou problema fará com que a Microsoft (ou qualquer outro fabricante) chegue nesse entendimento?
CurtirCurtir
E fazendo um adendo:
Eu não creio que alguns usuários vão pensar que o problema é no banco se acontecer em apenas um navegador, pelo menos se esse navegador não for o Internet Explorer.
CurtirCurtir
“Que tipo de erro ou problema fará com que a Microsoft (ou qualquer outro fabricante) chegue nesse entendimento?”
Por exemplo, se a chave privada da AC for comprometida. Ou se a AC não passar pelas auditorias anuais que são exigidas pelo programa da Microsoft.
CurtirCurtir
@Cima
Sabendo isso, então, quais seriam os incentivos — fora talvez ficar bem na mídia — para as ACs serem pró-ativas com problemas como o do MD5, já que este não é/foi suficientes pra fazer uma AC ser reprovada nas auditorias e retirada da lista de confiáveis — que é a única coisa que elas precisam evitar?
CurtirCurtir