Questão de Segurança da Informação — TLS, SSL e HTTPS — FCC 2026

Hardening de transporte: TLS, HSTS e boas práticas

Gabarito: letra B. O hardening correto de transporte em um servidor web HTTPS envolve habilitar o cabeçalho Strict-Transport-Security (HSTS) com includeSubDomains e configurar o ssl_protocols para aceitar apenas TLSv1.2 e TLSv1.3, versões modernas e seguras do protocolo. As demais alternativas contêm erros técnicos graves, como usar cifras obsoletas (RC4), versões vulneráveis (TLSv1.1), formatos de certificado inadequados (PKCS#7) ou desabilitar o firewall.

O objetivo do hardening de transporte é proteger a comunicação contra ataques de interceptação (man-in-the-middle), garantindo confidencialidade, integridade e autenticidade dos dados trafegados. Para isso, as melhores práticas recomendam:

1. Usar apenas versões seguras do TLS: TLS 1.2 e TLS 1.3 são as versões atuais e seguras. Versões anteriores (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) possuem vulnerabilidades conhecidas e devem ser desabilitadas.

2. Habilitar HSTS: O cabeçalho Strict-Transport-Security instrui o navegador a sempre usar HTTPS para o domínio, prevenindo ataques de rebaixamento (downgrade) e interceptação na primeira conexão. O parâmetro includeSubDomains estende essa política a todos os subdomínios.

3. Desabilitar compressão no nível HTTP: A compressão combinada com TLS pode permitir ataques de side-channel como o CRIME e o BREACH, que exploram a variação no tamanho do conteúdo criptografado para recuperar informações sensíveis.

4. Usar cifras fortes: Preferir cifras com sigilo de encaminhamento perfeito (forward secrecy), como as baseadas em ECDHE, e evitar algoritmos obsoletos como RC4.

5. Manter o firewall ativo: O firewall é uma camada essencial de defesa e não deve ser desabilitado para reduzir latência.

A alternativa B é a única que combina corretamente duas práticas fundamentais: habilitar HSTS com includeSubDomains e configurar ssl_protocols para TLS 1.2 e 1.3. As demais alternativas contêm erros que comprometem a segurança.

Alternativa A — ❌ Incorreta

A alternativa A sugere instalar o mod_ssl e definir SSLHonorCipherOrder como off, permitindo que o navegador escolha a cifra. Isso está errado por dois motivos: (1) SSLHonorCipherOrder deve ser on para que o servidor imponha a ordem de cifras seguras, evitando que o cliente negocie uma cifra fraca; (2) permitir que o navegador escolha a cifra independentemente da configuração do servidor é uma prática insegura, pois o cliente pode selecionar uma cifra vulnerável. A configuração correta é o servidor definir a ordem de preferência das cifras.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa B está correta porque combina duas práticas essenciais de hardening de transporte: habilitar o cabeçalho HSTS com includeSubDomains (forçando o navegador a usar HTTPS em todos os subdomínios) e configurar ssl_protocols para aceitar apenas TLSv1.2 e TLSv1.3 (versões seguras e modernas). Essas ações protegem contra ataques de interceptação e rebaixamento de protocolo.

Alternativa C — ❌ Incorreta

A alternativa C contém dois erros graves: (1) aceitar TLSv1.1 é inseguro, pois essa versão possui vulnerabilidades conhecidas e deve ser desabilitada; (2) forçar o uso de cifras baseadas em RC4 é uma prática obsoleta e insegura, pois o RC4 possui falhas criptográficas que permitem ataques de recuperação de chave. Embora desabilitar a compressão GZIP seja uma medida correta contra o ataque CRIME, os outros pontos tornam a alternativa incorreta.

Alternativa D — ❌ Incorreta

A alternativa D sugere migrar para o formato PKCS#7 (P7B), o que é inadequado para servidores web, pois esse formato não contém a chave privada e é usado principalmente para distribuição de certificados. Além disso, desabilitar a renovação automática de certificados é uma prática ruim, pois certificados expirados causam indisponibilidade e vulnerabilidades. Configurar keepalive_timeout para 0 também é incorreto, pois isso fecha conexões imediatamente, aumentando a latência e a carga no servidor, sem benefício de segurança.

Alternativa E — ❌ Incorreta

A alternativa E está errada porque desabilitar o firewall UFW para evitar latência no handshake TLS é uma prática insegura que remove uma camada essencial de proteção. Além disso, configurar o servidor para operar na porta 80 e redirecionar para a 443 não é uma medida de hardening, mas sim uma configuração básica de redirecionamento. O tráfego inicial na porta 80 é inseguro e pode ser interceptado antes do redirecionamento.

Gabarito: letra B