Questão de Segurança da Informação — TLS, SSL e HTTPS — INSTITUTO AOCP 2026
Segurança da Informação›TLS, SSL e HTTPS
Código
qa430611
Banca
INSTITUTO AOCP
Órgão
IF CE
Ano
2026
Cargo
Ana ( )
O protocolo TLS (Transport Layer Security) é o padrão atual para comunicações seguras na internet. A respeito dos protocolos SSL e TLS, assinale a alternativa INCORRETA.
AO TLS utiliza um processo de handshake para negociar algoritmos de criptografia, autenticar o servidor por meio de certificado digital e estabelecer chaves de sessão simétricas para cifrar os dados transmitidos.
BO SSL 3.0 e o TLS 1.0 são considerados vulneráveis – afetados por ataques como POODLE e BEAST, respectivamente – e foram formalmente depreciados pelas RFCs 7568 e 8996 do IETF.
CO TLS 1.3 eliminou algoritmos criptográficos considerados inseguros – como RC4, DES e 3DES – e simplificou o handshake em relação ao TLS 1.2, reduzindo a latência de estabelecimento de conexão de 2-RTT para 1-RTT.
DO SNI (Server Name Indication) é uma extensão do TLS que permite ao cliente informar o nome do host solicitado durante o handshake, possibilitando que um único endereço IP hospede múltiplos certificados TLS.
EO certificado digital utilizado no protocolo TLS garante autenticação bidirecional (mútua) mandatória entre cliente e servidor em implementações padronizadas do protocolo, sendo o certificado do cliente verificado pelo servidor antes do estabelecimento de qualquer conexão TLS.
Revelar gabarito e comentário▾
GabaritoE — O certificado digital utilizado no protocolo TLS garante autenticação bidirecional (mútua) mandatória entre cliente e servidor em implementações padronizadas do protocolo, sendo o certificado do cliente verificado pelo servidor antes do estabelecimento de qualquer conexão TLS.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
TLS e SSL: autenticação e handshake
Gabarito: letra E. A alternativa incorreta é a que afirma que o certificado digital garante autenticação bidirecional (mútua) mandatória entre cliente e servidor em implementações padronizadas do TLS. Na prática, a autenticação do cliente é opcional — o padrão exige apenas a autenticação do servidor; a autenticação mútua (mTLS) é um modo de operação específico, não o comportamento padrão. Essa distinção é o coração da questão.
O TLS (Transport Layer Security) é o sucessor do SSL (Secure Sockets Layer), ambos protocolos de segurança que operam na camada de transporte, garantindo confidencialidade, integridade e autenticação nas comunicações. O SSL foi criado pela Netscape em 1994, e o TLS 1.0, padronizado pela IETF no RFC 2246, evoluiu a partir do SSL 3.0. O funcionamento básico envolve um handshake (aperto de mão) em que cliente e servidor negociam a versão do protocolo, escolhem algoritmos de criptografia, trocam certificados digitais e estabelecem chaves de sessão simétricas para cifrar os dados. Esse processo é descrito no RFC 5246 (TLS 1.2), que detalha as etapas do handshake: troca de mensagens hello, troca de parâmetros criptográficos, autenticação por certificados e geração do segredo mestre.
A autenticação no TLS é assimétrica: o servidor sempre apresenta um certificado digital assinado por uma Autoridade Certificadora (CA), que o cliente valida. Já a autenticação do cliente é opcional — o servidor pode solicitar um certificado do cliente, mas isso não é obrigatório no padrão. Quando ambos os lados se autenticam, temos o mutual TLS (mTLS), usado em cenários como service mesh (ex.: Istio, Linkerd) e APIs internas, mas não é o comportamento padrão de navegadores web, por exemplo. A alternativa E erra ao tornar essa autenticação mútua mandatória em "implementações padronizadas".
A banca explora a confusão entre o que é padrão (autenticação do servidor obrigatória, do cliente opcional) e o que é modo específico (mTLS). Guarde essa fronteira: no TLS padrão, o cliente autentica o servidor; o servidor só autentica o cliente se configurado para isso. É exatamente nesse ponto que as alternativas se dividem.
A alternativa descreve corretamente o handshake do TLS: negociação de algoritmos, autenticação do servidor por certificado digital e estabelecimento de chaves de sessão simétricas. O RFC 5246 confirma que o handshake permite que cliente e servidor "concordem em uma versão de protocolo, selecionem algoritmos criptográficos, opcionalmente autentiquem um ao outro e usem técnicas de criptografia de chave pública para gerar segredos compartilhados". A autenticação do servidor é obrigatória, e as chaves simétricas são usadas para cifrar os dados após o handshake.
Alternativa B — ✅ Correta
A alternativa afirma que SSL 3.0 e TLS 1.0 são vulneráveis a POODLE e BEAST, respectivamente, e foram depreciados pelas RFCs 7568 e 8996. Isso está correto: o POODLE (Padding Oracle On Downgraded Legacy Encryption) afeta o SSL 3.0, e o BEAST (Browser Exploit Against SSL/TLS) afeta o TLS 1.0. A RFC 7568 (2015) proíbe o uso de SSL 3.0, e a RFC 8996 (2021) deprecia TLS 1.0 e 1.1. A alternativa não erra em nenhum detalhe.
Alternativa C — ✅ Correta
A alternativa descreve corretamente o TLS 1.3: removeu algoritmos inseguros como RC4, DES e 3DES, e simplificou o handshake, reduzindo a latência de 2-RTT (TLS 1.2) para 1-RTT (TLS 1.3). O TLS 1.3, publicado em 2018, eliminou suítes de cifras obsoletas e tornou o handshake mais eficiente, com menos idas e vindas entre cliente e servidor. A alternativa está tecnicamente precisa.
Alternativa D — ✅ Correta
A alternativa descreve corretamente o SNI (Server Name Indication): uma extensão do TLS que permite ao cliente informar o nome do host durante o handshake, possibilitando que um único endereço IP hospede múltiplos certificados TLS. Isso é essencial para servidores virtuais (virtual hosting) em HTTPS. A descrição está correta.
Alternativa E — ❌ Incorreta ⟵ GABARITO
A alternativa erra ao afirmar que a autenticação bidirecional (mútua) é mandatória em implementações padronizadas do TLS. No padrão, apenas a autenticação do servidor é obrigatória; a do cliente é opcional. O RFC 5246 afirma que a autenticação "pode ser tornada opcional, mas geralmente é exigida para pelo menos um dos pares" — ou seja, o servidor é autenticado, mas o cliente não necessariamente. A autenticação mútua (mTLS) é um modo específico, usado em cenários como service mesh, mas não é o padrão. A alternativa também erra ao dizer que o certificado do cliente é verificado "antes do estabelecimento de qualquer conexão TLS" — na verdade, a verificação ocorre durante o handshake, e apenas se o servidor solicitar.
NÃO CAIA NESSA!
A banca troca o padrão (autenticação do servidor obrigatória, do cliente opcional) pelo modo específico (mTLS, onde ambos se autenticam). O candidato que conhece o mTLS pode achar que a alternativa E está correta, mas ela generaliza indevidamente um recurso opcional como mandatório. Lembre-se: no TLS padrão, o cliente autentica o servidor; o servidor só autentica o cliente se configurado para isso.
PEGA ESSA DICA!
Para questões sobre TLS/SSL, foque nos conceitos de handshake, autenticação e versões. Memorize as principais diferenças entre TLS 1.2 e 1.3 (handshake 2-RTT vs 1-RTT, remoção de algoritmos inseguros) e os ataques clássicos (POODLE, BEAST, Heartbleed). E lembre-se: autenticação mútua é opcional no padrão — só é obrigatória em implementações específicas como mTLS.
Gabarito: letra E — a única alternativa incorreta, pois torna mandatória a autenticação mútua, que é opcional no padrão TLS.