95% dos servidores com HTTPS não são seguros
Nos dias que correm, é fundamental que todos os dados sensíveis, transaccionados entre um cliente (browser) e um servidor sejam cifrados de modo a que estes não possam ser entendidos por terceiros.
No caso dos servidores Web (entre outros serviços de uma rede), uma das formas de proceder à cifra dos dados é recorrendo ao protocolo SSL.
Mas sabia que 95% dos servidores HTTPS estão vulneráveis a ataques man-in-the-middle?
O que é o SSL?
O SSL é um protocolo criptográfico baseado em cifras assimétricas (chave privada + chave pública) que tem como principal objectivo providenciar segurança e integridade dos dados transmitidos em redes inseguras como é o caso da Internet.
Quando um utilizador acede a um site que recorre ao SSL, o servidor envia ao cliente a chave pública para que esta possa cifrar a informação que vai ser passada ao servidor. Quando o servidor recebe essa informação, usa a sua chave privada para decifrar a informação transmitida pelo cliente.
Existem várias aplicações para este protocolo, como por exemplo o comércio electrónico, servidores Web, servidores FTP, etc. Para identificar facilmente se estão a visualizar um site seguro basta verificar no URL que em vez de estar o normal http:// se encontra https://- Saber mais aqui.
Mas afinal o SSL não é seguro?
Na verdade a culpa é dos administradores que não fazem uma configuração apropriada das tecnologias. Segundo um estudo da Netcraft, 95% dos servidores com HTTPS podem ser atacados isto porque, como referido, existem configurações mal realizadas ou então o administrador não activa o protocolo de segurança HTTP Strict Transport Security (HSTS). Este protocolo ajuda a prevenir ataques man-in-the-middle, sequestro de cookies, etc.
Curiosamente os dados agora apresentados pela Netcraft são semelhantes aos apresentados há 3 anos. Isto quer dizer que os administradores de sistemas não demonstram muita preocupação na melhoria da segurança dos seus sistemas.
Como activar o HSTS?
Activar o protocolo de segurança HSTS é algo bastante simples. Para tal basta abrir a configuração do seu servidor web e inserir a seguinte linha:
Strict-Transport-Security: max-age=31536000;
Este linha força que as ligações sejam dos browsers ao servidor sejam sempre HTTPS mesmo que o utilizador tente aceder via http.
Se é responsável por um servidor Web verifique todas as configurações. Caso não tenha o HSTS é importante que o active, afinal é fácil e rápido.
Este artigo tem mais de um ano
Mas pelo que percebo o problema não está no SSL mas no facto de em algumas situações a ligação reverter para uma ligação http não encriptada. É isso?
Exacto, não tem problema nenhum no SSL.
E pq acontece isso?
Será pela velocidade da net, que se for baixa envia o site em HTTP para agilizar o processo?
A razão é porque alguém maligno pode interceptar a ligação e remover o httpS:// para ficar http:// e depois fazer o tráfego passar por si mesmo onde pode interceptar os dados trocados. Também podem bloquear a ligação segura bloqueando o porto 443 (se controlarem o caminho por onde percorre a ligação, exemplo falsa internet grátis nos aeroportos, cafés, bares…).
Mesmo com https:// não é garantidamente seguro! Se o atacante controlar o DNS pode redireccionar o utilizador para outro servidor por ele controlado, que até pode apresentar um certificado digital (se conseguir de alguma forma que emitam um… e com centenas de entidades a fazê-lo é credível que possam conseguir, pois já aconteceu várias vezes… até para domínios da google e tudo, e até já conseguiram ter certificados que emitiam certificados válidos, aceites pelos browsers, para todos os web sites)…. e nestes casos só verificando se os valores DNSSEC e TLSA estão correctos… mas mais uma vez, poucos web sites tem tal implementado e ainda obriga à implementação de um plugin grátis: https://www.dnssec-validator.cz/pages/download.html já que os browsers não trazem de raiz tal implementado… e convêm configurar para testar num servidor de DNS que suporte o DNSSEC correctamente como 8.8.8.8 (DNS publico da google).
Isto acontece porque para gerar uma página HTTPS o servidor web utiliza mais processamento, e a conexão também fica mais lenta, pois os recursos dependentes precisam ser carregador um a um… Por isso lojas virtuais e outros sites só ativam o HTTPS em situações de extrema importância… Eu ativo o HTTPS em todas as páginas de meus sites, mas com muitas otimizações o impacto fica quase imperceptível
O ataque man in the middle só ocorre se o servidor não tiver a certeza de quem vem a chave publica ! Para isso existem os certeficados !
Através do charlesproxy, ou outros programas parecidos é possível instalar um certificado e veres todo o tráfego https 😉
Por isso só com o DNSSEC e DANE (TLSA) devidamente configurados nos domínios e o utilizador utilizando um browser com um plugin ( https://www.dnssec-validator.cz ) é que é fácil de detectar visualmente que algo está errado.
Retirado do site do charles proxy:
Charles generates its own certificates for sites, which it signs using a Charles Root Certificate, which is uniquely generated for your installation of Charles (as of v3.10). You will see a warning in your browser, or other application, when it receives that certificate because the Charles Root Certificate is not in your list of trusted root certificates. See SSL Proxying.
Gostava de saber como é que tu, sendo o atacante,conseguirias ver o meu tráfego HTTPS decifrado.
O cliente teria que aceitar esse certificado gerado como sendo válido, se não o fizer, é muito improvável que se consiga decifrar o conteúdo em tempo útil (se estivermos a falar de SSLv3/TLS)
O pplware nem funciona com SSL!
Ora aqui uma boa resposta lol
+1
Lol, algo que já referi anteriormente. Mas aparentemente ter aqui gravatares e emails e users guardados é na boa, segurança pra quê?! Neh?
Pagas o certificado?
Hoje já compras certificados por menos de 5 euros ano, só não tem quem não quer. No caso da pplware até podiam ter um wildcard do sapo… não têm por opção certamente.
O pplware não precisa de SSL, até ver não existe troca de dados sensíveis.
Acho que deveríamos partir do principio que se há troca de dados (sensíveis ou não é relativo)…. Ao fim e ao cabo aparecem nomes (reais ou não depende da vossa fantasia) assim como algumas fotografias….
Abrir um túnel SSL entre cliente e servidor custa muitos ciclos de processamento, infelizmente nem todos os websites podem “custear” esse processamento… o ideal seria servirmos tudo em HTTPS no entanto, partindo dessa premissa, o importante é avaliar o risco e escolher se se deve servir sobre SSL ou não dependendo desse risco… acho que aqui o risco é muito resduzido, ou quase nulo…
Vitor Carvalho, partindo desse principio depende de quem analisa a situação, se for um individuo imbuído do nacional porreirismo então nunca há problemas, veja-se como funcionavam há algum tempo os servidores da nação… é o nacional porreirismo em ação. A Informação nunca é sensível até que alguém a considere sensível ou pertinente.
Calma, não stressem que tal como temos no usados.pplware.sapo.pt também estamos a implementar essa medida de segurança, assim como outras.
mesmo com o treco que estao colocando antes cloudflare ????
então é por isso que desde que actualizei para o Firefox 45.0.1, não consigo aceder ao Twitter, YouTube nem fazer compras na Amazon UK. A mensagem de erro é: “O proprietário do site configurou o website incorretamente. Para impedir que a sua informação fosse furtada, o Firefox não se ligou a este website.
Este site utiliza HTTP Strict Transport Security (HSTS) para indicar que o Firefox apenas se pode ligar em segurança. Como resultado, não é possível adicionar uma exceção para este certificado.”
está certo.obrigado.
Ainda tou para encontrar um site https em que não consiga efetuar um “ataque” mitm…
Sinceramente, sinto-me tão seguro a enviar os meus dados através de http, https ou TCP com TLS.
Eu também, é tão fácil xD
Tenho uma questão: Tenho o meu DNS a passar pelo Cloudflare, no qual tem um certificado SSL. O cloudflare apenas permite inserir metade do tempo na config do HSTS, isto é, Strict-Transport-Security: max-age=15768000; o que equivale a 6 meses.
As status do Cloudflare são estas:
Status: On
Max-Age: 6 months (recommended)
Include subdomains: On
Preload: On
No-sniff: On
A minha pergunta é: Será que o servidor está vulnerável a ataques man-in-the-middle? Já agora o site é: https://vigilo.ga/.
Se não estiver na listagem do próprio browser configurado desde o inicio para se recusar a ligar de forma insegura, então está vulnerável. Mas é fácil, basta submeter o web site em: https://hstspreload.appspot.com e passado algumas semanas é incluindo nos diversos browsers (chrome, firefox e IE) visto que todos parecem utilizar esta listagem actualmente.
Pode aumentar ainda mais a segurança colocando os parâmetros de DNSSEC e DANE (TLSA), pode ver mais informações acerca de ambos aqui:
DNSSEC:
http://www.internetsociety.org/deploy360/dnssec/
TLSA:
http://www.internetsociety.org/deploy360/resources/dane/
https://netfuture.ch/2013/06/how-to-create-dnssec-dane-tlsa-entries/
Plugin gratuito para os browsers, para verificar se está tudo ok:
https://www.dnssec-validator.cz
Nota, na Cloudflare, apenas pode obter os parâmetros DNSSEC a colocar na empresa de registo do domínio. O DANE (TLSA) ainda não é possível colocar na Cloudflare infelizmente… pode ser que um dia seja possível, mas para já não quiseram ainda pôr (desconheço os motivos).
Mas nesse serviço de domínios que regista o .ga não me parece que suporte o DNSSEC… mas procure no painel de controlo, ou tente contactá-los por e-mail para saber se tem tal possibilidade nem que seja manualmente.