ERR_SSL_VERSION_OR_CIPHER_MISMATCH. É o erro que aparece quando abres o portal de gestão de uma firewall antiga — uma pfSense antiga, um switch gerível, uma ONT, a console web de um UPS — porque o equipamento só fala TLS 1.0 ou 1.1. Os browsers actuais recusam-nos por omissão: o Firefox exige TLS 1.2 como mínimo (o `security.tls.version.min` vale 3 por omissão), o Chrome e o Edge bloqueiam-nos por omissão desde a 84 (Julho de 2020) e fecharam as últimas válvulas entre a 91 e a 98; o Safari perdeu-o em Março de 2020 (Safari 13.1) (Safari 13.1). Este guia mostra o caminho de excepção — um perfil dedicado do Firefox com security.tls.version.min=1 — e o caminho certo a prazo, que é consertar o próprio equipamento.
O erro que abre o artigo (IP mascarado): o portal de gestão só negoceia protocolos antigos
⚠️ Antes de começar
TLS 1.0/1.1 são protocolos de 1999/2006 sem cifras modernas: o que servem é ponte temporária para consertar o equipamento, nunca o modo de gestão permanente. Usa uma conta de administração que não seja a do dia-a-dia (o artigo sobre tiering explica porquê) e desfaz a configuração quando o equipamento estiver actualizado.
Neste artigo
- 1. Porque os browsers bloqueiam
- 2. Firefox — o perfil de excepção
- 3. Chrome e Edge — não há forma
- 4. Safari — idem
- 5. Consertar o equipamento — o caminho certo
- 6. Para sysadmins: inventariar e CLI
- 7. Erros comuns
- 8. Checklist
- Veredicto
- Artigos Relacionados
- Fontes Oficiais
1. Porque os browsers bloqueiam
O TLS 1.0 (RFC 2246) e o 1.1 (RFC 4346) suportam apenas cifras que já não consideramos seguras (CBC sem as mitigações modernas, RC4, 3DES, ciphers de exportação) — o BEAST de 2011 demonstrou como explorar o CBC do TLS 1.0, e Bar Mitzvah/FREAK abriram as cifras fracas que os servidores antigos ainda aceitam. Por isso a indústria desligou-os por fases: o desligamento coordenado dos browsers anunciado em Outubro de 2018 — adiado pela pandemia — cumpriu-se em 2020, com o Chrome 84 e o Edge 84 (Julho de 2020) a bloqueá-los por omissão. A política SSLVersionMin deixou de aceitar tls1/tls1.1 no Chrome 91 e foi removida na 98 — o Edge removeu-a também, e nas 97/98 fechou-se a última forma de contornar o aviso. O Firefox mantém o TLS 1.2 como mínimo desde a 78 e retirou na 97 o botão da página de erro que voltava a ligar o TLS antigo. Os equipamentos antigos não foram actualizados — e o utilizador descobre-o no dia em que precisa de abrir o webConfigurator.
2. Firefox — o perfil de excepção
O Firefox é o único dos três que ainda permite reduzir o mínimo de TLS. Não o faças no teu perfil do dia-a-dia — cria um perfil separado só para equipamentos de gestão:
1. about:profiles → “Create a New Profile” com nome tipo “equipamentos-antigos” → “Launch profile in new browser”. Ou pela linha de comandos: firefox -ProfileManager.
2. No novo perfil, abre about:config (aceita o aviso) e pesquisa security.tls.version.min:
3. O valor por omissão é 3 (TLS 1.2). Para equipamentos antigos:
- 1 = TLS 1.0 (o mínimo para a maioria dos equipamentos antigos)
- 2 = TLS 1.1 (se o equipamento suportar 1.1, é o melhor compromisso)
- 3 = TLS 1.2 · 4 = TLS 1.3 (os valores normais — deixas aqui o teu perfil diário)
4. Escreve security.tls.version.enable-deprecated e muda para true — é esta preferência que activa o suporte às versões antigas (TLS 1.0/1.1): só reduzir o min não chega. O botão que a activava na página de erro saiu no Firefox 97, e por isso é via about:config que se volta a ligar. Sem ela, a ligação falha mesmo com o min=1.
5. Abre o endereço do equipamento: o certificado vais ter de o aceitar à parte (a página de erro dá a opção em “Avançado” → “Aceitar o risco”) — é o certificado auto-assinado do próprio equipamento, não o protocolo: são dois bloqueios diferentes.
O perfil fica memorizado com estas duas preferências — e só este perfil fala TLS antigo. O teu perfil normal navega com TLS 1.2+, que é o que queres. Quando o equipamento estiver actualizado, apaga o perfil (about:profiles → “Remove”).
3. Chrome e Edge — não há forma
Não percas tempo: o suporte em si saiu com o Chrome 84/Edge 84 (Julho de 2020); a política SSLVersionMin deixou de aceitar tls1/tls1.1 no Chrome 91 (no Edge os valores morreram na 90) e a política foi removida nas versões 98 — a Microsoft lista-a como obsoleta e ignorada mesmo que esteja na GPO ou no registo. As flags antigas (chrome://flags “Minimum TLS version enabled” e equivalente no Edge) foram retiradas em 2020/2021, e não existe about:config no Chromium. Quem escreveu instruções da era 2020 (“activar tls1 na política”) aconselha algo que já não funciona.
Há quem aponte o modo IE do Edge — que usa o motor do IE11 — como alternativa para páginas antigas. Não o verificámos para o caso do TLS 1.0/1.1 nem o recomendamos por omissão; se o testares, faze-lo num ambiente isolado. A via garantida continua a ser o perfil Firefox da secção 2.
O caminho no Chrome/Edge: o perfil Firefox de excepção (podes usar o Firefox Portable da Mozilla só para isto, sem se intrometer no PC), ou o terminal que aparece na secção 6.
4. Safari — idem
A Apple removeu o suporte de TLS 1.0/1.1 do Safari (e das apps do sistema) a partir de Março de 2020 — iOS 13.4, iPadOS 13.4 e macOS Catalina 10.15.4 (Safari 13.1) — e nunca houve preferência para voltar atrás. Idem: Firefox com perfil dedicado, ou consertar o equipamento.
5. Consertar o equipamento — o caminho certo
A ponte browser tem data de fim: a solução é elevar o equipamento a TLS 1.2+. Um exemplo concreto na pfSense:
📌 Não é só a firewall
A pfSense é o exemplo típico — e o mais fácil de actualizar. O mesmo TLS antigo esconde-se em switches geríveis, ONT do ISP, câmaras IP, NAS, cartões de gestão de UPS e RAID, BMC/iLO/iDRAC de servidores antigos e até impressoras com porta web. Cada um tem a sua consola e o seu caminho de actualização, e actualizá-la resolve uma peça, não o parque. Por isso o inventário (nmap na secção 6) vem antes: actualizas a pfSense e o mesmo erro continua a aparecer na ONT.
1. Actualiza o pfSense — a CE 2.3 (2016) está fora de suporte há anos e os instaladores actuais só existem para amd64 (32 bits i386 nunca passará da 2.3.x — aí não há caminho de upgrade). Nas instalações antigas o seguro é: backup da config (Diagnostics → Backup & Restore), instalação limpa da CE actual (2.8.x/2.9.0) e restauro; em 64 bits suportado, o System → Update faz o mesmo. As versões recentes já falam TLS 1.2/1.3 no webConfigurator por omissão.
2. Confirma o que o portal negocia — atenção: a GUI não tem selector de versões TLS; o Admin Access (System → Advanced) tem o protocolo HTTPS, o certificado (auto-assinado ou teu), a porta e o HSTS. A versão que o portal fala é definida pelo software da instalação — por isso o teste vem do nmap/openssl da secção 6: negociar só 1.2/1.3 após o upgrade é o sinal verde, e se numa instalação recente ainda chegar 1.0/1.1, é uma versão antiga ou uma configuração manual do lighttpd a reverter.
3. Verifica — o browser normal (TLS 1.2+) abre o webConfigurator sem o perfil de excepção — os relatórios do diagnóstico TLS mostram a versão negociada.
Para o resto do parque — switches geríveis, ONT, câmaras, cartões de gestão de UPS/RAID — o padrão é o mesmo: procurar firmware que active TLS 1.2 nos serviços de gestão, restringir a porta de gestão ao VLAN de administração e, nos que não têm actualização, isolar via VPN/firewall (o acesso fica só de uma sub-rede de gestão, e a ponte de TLS morre o mais cedo possível).
6. Para sysadmins: inventariar e CLI
Para saber exactamente o que o equipamento fala (e inventariar a rede),
# Que versões de TLS e cifras o destino aceita?
nmap --script ssl-enum-ciphers -p 443 192.168.1.1
# Confirmar o protocolo negociado na mão
openssl s_client -connect 192.168.1.1:443 -tls1_2 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'
# Aceder por CLI quando o browser não dá (OpenSSL 3.x exige SECLEVEL=0 para TLS antigo)
curl -k --tlsv1.0 --tls-max 1.0 --ciphers DEFAULT@SECLEVEL=0 https://192.168.1.1/
O ssl-enum-ciphers devolve a lista por versão (TLSv1.0/1.1/1.2/1.3) com as cifras de cada uma — é a prova de que o equipamento já tem 1.2 depois do upgrade, e a lista de tudo o que ainda fala só-o-antigo.
7. Erros comuns
- Reduzir o mínimo no perfil diário — o TLS 1.0/1.1 fica activo para TODOS os sites; se o perfil é o de navegação normal, o teu browser passa a aceitar ligações fracas onde um atacante tem interesse. Usa o perfil dedicado.
- Erro persiste com min=1 — quase sempre porque faltam as cifras: activa
security.tls.version.enable-deprecated=true. Se persistir, o equipamento ainda usa SSL3 (RFC 6101, sem TLS 1.0 real) e aí a resposta honesta é: consertar ou substituir. - Confundir certificado com protocolo — “A sua ligação não é privada” com o certificado auto-assinado não é o erro TLS version: aceita o certificado à parte; o erro de versão é o ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
- Política SSLVersionMin na GPO — quem a deixar no registo (Chrome/Edge) está a carregar um valor ignorado; a página Edge lista-a como obsoleta. Limpa a entrada para não enganar auditorias futuras.
- Manter a ponte para sempre — sem data de revisão, o perfil de excepção vive anos e o equipamento nunca é actualizado. Data marcada + inventário (nmap) = a ponte desativada antes de o próximo browser a fechar.
8. Checklist
- [ ] Perfil Firefox dedicado criado (“equipamentos-antigos”) — TLS 1.0/1.1 apenas aí
- [ ] security.tls.version.min=1 + enable-deprecated=true (só nesse perfil)
- [ ] Equipamento inventariado (nmap ssl-enum-ciphers): que versões fala hoje?
- [ ] pfSense actualizado + Admin Access em HTTPS com TLS 1.2/1.3
- [ ] Porta de gestão restrita (VLAN de administração + firewall)
- [ ] Data de revisão na ponte: perfil e preferências removidos quando o equipamento falar 1.2+
Veredicto
O Firefox com security.tls.version.min=1 (e enable-deprecated) num perfil dedicado é o caminho de excepção legítimo para abrir a web console de uma pfSense antiga — é o único browser que ainda permite, mas o valor real está no item 5: actualização do equipamento, TLS 1.2+ na porta de gestão, VLAN restrita e a ponte desativada com data marcada. O que não se deve fazer é reduzir o TLS no perfil de navegação do dia-a-dia — aí os 25 anos de histórico do protocolo pesam sempre para o atacante.
Artigos Relacionados
- pfSense: Configuração de Firewall, NAT e VPN em 2026
- OPNsense 2026: Firewall, NAT, VPN e IDS — Guia Prático para PME
- FortiGate em PME: Configuração Base e Troubleshooting
- Tiering de Administração e PAW: Separar Contas Admin das Diárias no AD