
Um dos sites mais conhecidos da Alexa (círculo central), protegido por HTTPS, com subdomínios (cinza) e dependências (branco), entre os quais alguns são vulneráveis (preenchimento com hachuras)
Nos dias de hoje, o ícone de conexão segura HTTPS se tornou um padrão e até um atributo necessário de qualquer site sério. Se estiver ausente, quase todos os navegadores recentes mostram um aviso de que e não recomendam o envio de informações confidenciais para ele.
Mas parece que a presença de um "cadeado" na barra de endereço nem sempre garante proteção. no ranking da Alexa mostrou: muitos deles estão sujeitos a vulnerabilidades críticas nos protocolos SSL/TLS, geralmente por meio de subdomínios ou dependências. Segundo os autores do estudo, a complexidade das aplicações web modernas multiplica a superfície de ataque.
Resultados da Pesquisa
A pesquisa foi conduzida por especialistas da Universidade Ca' Foscari de Veneza (Itália) e da Universidade Técnica de Viena. Um relatório detalhado será apresentado no 40º simpósio da IEEE sobre Segurança e Privacidade, que ocorrerá de 20 a 22 de maio de 2019 em São Francisco.
Foram verificados 10.000 dos sites HTTPS mais populares da lista da Alexa e 90.816 hosts relacionados a eles. Configurações criptográficas vulneráveis foram identificadas em 5.574 hosts, ou seja, cerca de 5,5% do total:
- 4.818 vulneráveis a MITM
- 733 vulneráveis a decriptação total de TLS
- 912 vulneráveis a decriptação parcial de TLS
898 sites estão completamente abertos a invasões, ou seja, permitem a injeção de scripts de terceiros, e 977 sites carregam conteúdo de páginas mal protegidas, com as quais um atacante pode interagir.
Os pesquisadores destacam que entre os 898 recursos "completamente comprometidos" há lojas online, serviços financeiros e outros grandes sites. 660 dos 898 sites carregam scripts externos de hosts vulneráveis: essa é a principal fonte de perigo. Segundo os autores, a complexidade das aplicações web modernas multiplica a superfície de ataque.
Outros problemas foram detectados: 10% dos formulários de autenticação apresentam problemas na transmissão segura de informações, o que pode levar a vazamentos de senhas, 412 sites permitem a interceptação de cookies e "sequestro de sessão", e 543 sites estão sujeitos a ataques de integridade de cookies (por meio de subdomínios).
O problema é que, nos últimos anos, foram identificadas várias vulnerabilidades nos protocolos SSL/TLS e no software. : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) e Heartbleed (CVE-2014-0160). Para se proteger contra elas, é necessário realizar uma série de configurações do lado do servidor e do cliente, para evitar o uso de versões antigas vulneráveis. No entanto, esse processo é bastante complexo, pois as configurações envolvem a escolha entre um extenso conjunto de cifras e protocolos, que pode ser difícil de compreender. Nem sempre está claro quais conjuntos de cifras e protocolos devem ser considerados "suficientemente seguros".
Configurações recomendadas
Não existe uma lista oficialmente aprovada e consensual de configurações recomendadas para HTTPS. Por exemplo, oferece várias opções de configuração, dependendo do nível de proteção desejado. Por exemplo, aqui estão as configurações recomendadas para o servidor nginx 1.14.0:
Modo moderno
Os clientes mais antigos suportados são: Firefox 27, Chrome 30, IE 11 no Windows 7, Edge, Opera 17, Safari 9, Android 5.0 e Java 8
server {
listen 80 default_server;
listen [::]:80 default_server;
# Redirecionar todas as solicitações HTTP para HTTPS com uma resposta 301 Moved Permanently.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Certificados enviados ao cliente no SERVER HELLO são concatenados em ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# configuração moderna. ajuste conforme suas necessidades.
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module é necessário) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# buscar registros OCSP da URL no ssl_certificate e armazená-los
ssl_stapling on;
ssl_stapling_verify on;
## verificar a cadeia de confiança da resposta OCSP usando Root CA e certificados intermediários
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Suporte médio
Os clientes mais antigos suportados são: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7
servidor {
listen 80 default_server;
listen [::]:80 default_server;
# Redirecionar todas as solicitações HTTP para HTTPS com uma resposta 301 Moved Permanently.
return 301 https://$host$request_uri;
}
servidor {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certificados enviados ao cliente no SERVER HELLO são concatenados no ssl_certificate
ssl_certificate /caminho/para/certificado_assinado_plus_intermediates;
ssl_certificate_key /caminho/para/chave_privada;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# parâmetro Diffie-Hellman para ciphersuites DHE, recomendado 2048 bits
ssl_dhparam /caminho/para/dhparam.pem;
# configuração intermediária. ajuste conforme suas necessidades.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module é necessário) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# buscar registros OCSP da URL no ssl_certificate e armazená-los em cache
ssl_stapling on;
ssl_stapling_verify on;
## verificar a cadeia de confiança da resposta OCSP usando CA raiz e certificados intermediários
ssl_trusted_certificate /caminho/para/certificado_CA_raiz_plus_intermediates;
resolver ;
....
}Suporte descontinuado
Os clientes mais antigos suportados são: Windows XP IE6, Java 6
servidor {
listen 80 default_server;
listen [::]:80 default_server;
# Redirecionar todas as solicitações HTTP para HTTPS com uma resposta 301 Moved Permanently.
return 301 https://$host$request_uri;
}
servidor {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certificados enviados ao cliente no SERVER HELLO são concatenados no ssl_certificate
ssl_certificate /caminho/para/certificado_assinado_plus_intermediates;
ssl_certificate_key /caminho/para/chave_privada;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# parâmetro Diffie-Hellman para ciphersuites DHE, recomendado 2048 bits
ssl_dhparam /caminho/para/dhparam.pem;
# configuração antiga. ajuste conforme suas necessidades.
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module é necessário) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# buscar registros OCSP da URL no ssl_certificate e armazená-los em cache
ssl_stapling on;
ssl_stapling_verify on;
## verificar a cadeia de confiança da resposta OCSP usando CA raiz e certificados intermediários
ssl_trusted_certificate /caminho/para/certificado_CA_raiz_plus_intermediates;
resolver ;
....
}É recomendável sempre utilizar o conjunto completo de cifras e a versão mais recente do OpenSSL. O conjunto de cifras nas configurações do servidor indica a prioridade com a qual elas serão usadas, dependendo das configurações do cliente.
Pesquisas mostram que não é suficiente apenas instalar um certificado HTTPS. "Embora não tratemos cookies como em 2005, e o 'TLS decente' tenha se tornado uma norma, revela-se que essas questões básicas são insuficientes para garantir a segurança de um número surpreendentemente grande de sites muito populares", — autores do estudo. Para garantir uma proteção confiável do canal entre o servidor e o cliente, é necessário acompanhar de perto a infraestrutura de seus próprios subdomínios e de hosts externos de onde o conteúdo do site é fornecido. Talvez valha a pena solicitar uma auditoria de uma empresa externa especializada em segurança da informação.
Fonte: habr.com
