Proteção em trânsito (TLS, VPN) e em repouso (criptografia, KMS/HSM)

A ideia que organiza o assunto

A nota de Criptografia responde a uma pergunta: qual chave foi usada e de quem ela é? Este tópico responde a outra, e as duas não se substituem. Aqui os algoritmos já estão escolhidos; o que se cobra é onde a proteção é aplicada, até onde ela alcança e o que fica de fora dela.

O modelo mental é o túnel. Proteger dado em trânsito é montar um túnel entre dois pontos: tudo que passa entre eles é cifrado e autenticado, e tudo que está antes de um ponto ou depois do outro continua em claro. Daí saem três perguntas que resolvem quase todo item do tópico:

1. Onde o túnel começa e onde termina? No HTTPS, entre o navegador e o servidor web — e não dentro da aplicação, nem no banco de dados, nem no log. Na VPN site a site com IPsec, entre os dois gateways — e não dentro das LANs que eles ligam. Na SSL VPN, entre o navegador e o concentrador, sessão a sessão.
2. O que o túnel não cobre? É por isso que HTTPS não impede injeção de SQL: o ataque chega por dentro do túnel, perfeitamente válido para o TLS, e só encontra resistência na aplicação.
3. Quem faz o quê nas pontas? Cliente propõe, servidor dispõe. ESP cifra, AH apenas autentica. GRE encapsula, IPsec cifra. Quase metade dos itens errados do tópico troca exatamente um desses papéis de lugar.

E vale dizer de saída o que a prova, medida, não cobra. Dos 35 itens do tópico, um único menciona dado em repouso, e em oração subordinada de um item genérico; nenhum menciona criptografia de disco, tokenização, KMS ou HSM. O peso está inteiro no trânsito: VPN em 13 itens, TLS ou SSL em 17, HTTPS em 6, IPsec em 6. E, dos 14 itens errados, nenhum é decidido por um número — nem de versão, nem de porta, nem de tamanho de chave. Quando o item cita TLS 1.1 ou TLS 1.3, o número é isca: o erro está sempre no predicado.

Por que se usa (e o que custa)

Cifrar o canal é barato e transparente, e é por isso que virou padrão. O preço aparece em três lugares, e os três caem.

Sobrecarga de pacote. O modo túnel do IPsec encapsula o pacote IP inteiro dentro de outro pacote, com novo cabeçalho IP, o que engorda o tráfego e reduz a MTU útil. O modo transporte não faz isso — preserva o cabeçalho original e protege só o que está acima dele —, mas em compensação só serve para dois hosts que se falam diretamente, não para ligar redes.

Custo de estabelecimento. Toda conexão TLS começa com um handshake: negociar versão e suíte, validar certificado, derivar chaves. Por isso o protocolo tem retomada de sessão, e por isso um navegador abre várias conexões TLS em paralelo sem que nada no protocolo o impeça.

Escolha entre duas VPNs, e ela é de camada. O IPsec protege embaixo, na camada de rede: é transparente para as aplicações, cobre tudo que a máquina manda, e cobra por isso a instalação e a configuração de cliente. A SSL VPN protege em cima, junto à aplicação: roda no navegador, dispensa cliente instalado, atravessa firewall pela porta 443 — e cobre apenas as sessões que passam por ela. Cobertura ampla com atrito, ou atrito baixo com cobertura seletiva.

Como funciona

TLS e HTTPS. HTTPS não é protocolo novo: é HTTP transportado sobre TLS. O TLS trabalha em duas fases. Na negociação, o cliente abre com o ClientHello, anunciando a maior versão que suporta e a lista de suítes que oferece; o servidor responde com o ServerHello, escolhendo dentro dessa lista, e apresenta o certificado que prova sua identidade. Só então começa a fase de registro, em que os dados de aplicação trafegam cifrados com a chave de sessão. Cliente propõe, servidor dispõe é a frase que resolve todo item de handshake.

Sigilo perfeito adiante (forward secrecy) é propriedade da chave de sessão, não do certificado: as chaves são efêmeras, descartadas ao fim da conexão e nunca reaproveitadas. O efeito é proteger o passado: quem gravar o tráfego hoje e obtiver a chave privada do servidor amanhã continua sem conseguir decifrar o que gravou.

SSL e TLS não convivem: sucedem-se. O TLS nasceu do SSL 3.0 e o substituiu; todas as versões de SSL estão formalmente descontinuadas. Chamar o SSL de obsoleto e, na mesma frase, dizer que ele estabelecia enlaces autenticados e cifrados é coerente — ser obsoleto não apaga o que a tecnologia fazia. E as duas especificações não são idênticas: a mudança mais cobrada é a do código de autenticação de mensagem, que no TLS passou a ser o HMAC padronizado.

Compressão e cifragem não se misturam. Comprimir antes de cifrar faz o tamanho do texto cifrado depender do conteúdo, e é disso que vivem ataques como o CRIME. Por isso a compressão do TLS é desabilitada sob HTTP/2.

VPN é um conceito, não um protocolo. É uma rede lógica construída sobre uma infraestrutura física pública — a Internet —, com tráfego autenticado e cifrado entre as pontas. Implementam-na IPsec, L2TP (quase sempre sobre IPsec, que lhe dá a criptografia que ele não tem), PPTP, SSTP (que corre dentro de SSL/TLS, na porta 443, e autentica o usuário) e o próprio SSL/TLS.

IPsec vive na camada IP e, apesar de o IP ser não orientado à conexão, é orientado à conexão: nada trafega antes de estabelecida a associação de segurança, o acordo unidirecional que fixa algoritmos e chaves. Tem dois cabeçalhos — AH, que autentica e não cifra, e ESP, que cifra e também autentica — e dois modos, túnel e transporte.

Encapsular não é cifrar. O GRE — generic routing encapsulation — transporta protocolos diversos dentro de um túnel IP e não oferece criptografia nem autenticação. Um túnel GRE puro trafega em claro; quem o torna seguro é o IPsec por cima.

Em repouso — bloco não medido, porque o corpus deste tópico ainda não o cobra. A lógica é outra: não há túnel, há dado parado. Cifra-se o disco ou o volume inteiro (protege contra furto do equipamento, não contra usuário logado), ou o campo e a coluna (protege contra quem lê o banco), guardando-se a chave fora do dado, em KMS ou HSM. Tokenização é diferente de cifra: substitui o dado sensível por um substituto sem valor, e o original fica num cofre à parte — não há chave que reverta o token, há uma tabela de correspondência.

O que decide os itens

Onde cada coisa atua, e o que cada uma entrega:

	camada	entrega
IPsec (AH)	rede	autenticação e integridade, sem confidencialidade
IPsec (ESP)	rede	confidencialidade + autenticação e integridade
GRE	rede (encapsulamento)	nada de segurança: só transporte de protocolos
L2TP / PPTP	enlace (tunelamento)	tunelamento; segurança vem do IPsec ou do MPPE
SSL / TLS	acima do transporte, junto à aplicação	autenticação do servidor, sigilo e integridade da sessão
SSTP	dentro de SSL/TLS, porta 443	VPN que atravessa firewall, com autenticação de usuário

IPsec: os dois pares que a banca embaralha

	faz	não faz
AH × ESP	AH autentica	AH não cifra; quem cifra é o ESP
túnel × transporte	túnel acrescenta novo cabeçalho IP e liga redes por gateways	transporte preserva o cabeçalho original e protege só a carga, entre dois hosts

VPN IPsec × VPN SSL — o eixo é sempre a altura na pilha:

	IPsec	SSL/TLS
camada	rede (baixo)	aplicação (alto)
cliente na estação	exigido	dispensado: o navegador já tem
cobertura	todo o tráfego da máquina	as sessões que passam pelo portal
firewall	costuma exigir liberação	passa pela 443

SSL × TLS — relação de sucessão, não de complementaridade. SSL está descontinuado; TLS é o vigente; as regras de autenticação são semelhantes, não idênticas (o TLS adotou HMAC).

Quem faz o quê no handshake — cliente envia ClientHello, anuncia versão e oferece suítes; servidor envia ServerHello, escolhe a suíte e apresenta o certificado.

Canal × aplicação — o TLS protege o transporte. Injeção de SQL, XSS, CSRF, falha de autorização e erro de lógica chegam por dentro do túnel e são imunes a ele.

Negar uma prática × negar uma função — a distinção que separa dois itens de aparência idêntica. “A compressão não é recomendada sobre TLS” nega uma prática, e é Certo. “A VPN não oferece criptografia” nega uma função, e é Errado.

Como a CEBRASPE derruba você aqui

Medido sobre os 14 itens errados do tópico. Um formato responde por mais da metade deles, e a distribuição é diferente da dos tópicos vizinhos: em Criptografia e em Redes quem domina é a troca de termo; aqui, não.

Inversão — 57% (8 de 14), e em três formas. A maior delas, quatro itens, é negar a uma tecnologia aquilo que ela existe para entregar. A VPN que “tem como desvantagem a falta de autenticação e criptografia”. A VPN IPsec site a site que “é capaz de oferecer autenticação, porém não oferece criptografia” — o ESP faz parte do IPsec, e cifra. O TLS que “impede a abertura de múltiplas conexões HTTP paralelas”, restrição que o protocolo não impõe e que a retomada de sessão existe justamente para baratear. E a criptografia em trânsito que “não é parte integrante das políticas de sistemas de proteção de dados”. Defesa: antes de qualquer detalhe técnico, pergunte para que a tecnologia foi criada. Se o item nega isso, já se entregou.

A segunda forma, dois itens, troca os papéis das pontas: “o início da sessão se dá quando o servidor envia uma mensagem Server Hello” e “quem determina os parâmetros apropriados criptográficos para a conexão é o cliente”. São o mesmo par visto dos dois lados. Cliente propõe, servidor dispõe resolve ambos — e note que o segundo planta a inversão depois de um entretanto, com a primeira metade impecável.

A terceira, dois itens, aponta uma seta para o lado errado: a VPN que “cria uma rede física sobre fluxos de dados lógicos” — é o contrário, e o virtual do nome basta para resolver — e o sigilo perfeito adiante que garantiria que “as chaves utilizadas no passado podem ser novamente utilizadas no futuro”, quando ele garante exatamente que não podem.

Troca de termo — 21% (3 de 14), e o vizinho trocado é sempre de um par fechado. “O modo de transporte acrescenta um cabeçalho IP extra” — a descrição é do modo túnel. “SSL e TLS são tecnologias complementares” — são sucessivas. “As regras de autenticação [do TLS] são idênticas às do SSL” — são semelhantes. Defesa: identifique o par (túnel/transporte, AH/ESP, SSL/TLS, IPsec/SSL) e confira as duas metades, nunca uma de cada vez.

Generalização — 14% (2 de 14), sempre uma promessa absoluta de segurança. HTTPS “é suficiente para protegê-la contra todos os tipos de ataques cibernéticos” e TLS 1.1 “é imune a ataques do tipo man-in-the-middle”. Nenhum protocolo promete imunidade nem suficiência, e o número da versão ao lado é decoração. Suficiente, imune, todos os tipos, impossível: achado o absoluto, o item está resolvido.

Atribuição errada — 7% (1 de 14). A VPN “sob o protocolo GRE” com o objetivo de “interligar redes remotas de forma segura”: a ação é real, o protocolo é outro. GRE encapsula; quem protege é o IPsec. No mesmo item a sigla vem expandida como generic capsulating rotation, que não existe — vale conferir a expansão sempre que a banca a oferece.

Quatro categorias não ocorrem nenhuma vez: número errado, escopo ampliado, relação causal e exceção omitida. O zero mais útil é o do número. Este é um tópico cheio de versões — TLS 1.1, 1.2, 1.3 — e em nenhum item errado a versão é o erro. Não perca tempo verificando se o número confere: leia o predicado.

Do outro lado, os 21 itens certos têm uma forma só: afirmam, sem absoluto, que uma dessas tecnologias faz aquilo que ela faz — a VPN liga redes com sigilo, o HTTPS usa TLS, o TLS exige certificado, o IPsec admite túnel e transporte, o SSL pode montar VPN. Descrição afirmativa e sóbria de uma capacidade é o formato Certo dominante do tópico. A única exceção mede bem a diferença: o item que diz que a compressão não é recomendada também é Certo — porque nega uma prática, não uma função.

Erros clássicos

Achar que HTTPS protege a aplicação. Protege o canal. SQLi, XSS, CSRF e falha de autorização entram pelo túnel cifrado, e o TLS os entrega intactos ao servidor.

Confundir túnel com túnel seguro. GRE, L2TP e PPP encapsulam sem cifrar. Encapsulamento é transporte; confidencialidade é outra função e exige IPsec ou TLS por cima.

Achar que IPsec não cifra. Quem só autentica é o AH. O ESP, que também é IPsec, cifra — e é o que se usa na prática.

Trocar os modos do IPsec. Novo cabeçalho IP, gateway, ligar duas redes: túnel. Cabeçalho original preservado, só a carga protegida, host a host: transporte.

Tratar SSL e TLS como parceiros. São etapas de uma mesma linhagem. O TLS substituiu o SSL, e as regras dos dois são semelhantes, não idênticas.

Estranhar que o IPsec seja orientado à conexão. É, e o IP não é. A associação de segurança é estabelecida antes de qualquer tráfego; essa estranheza é isca, não erro.

Achar que uma versão nova dá imunidade. Usar a versão mais recente do TLS é recomendação correta e cai como Certo; dizer que qualquer versão é imune a man-in-the-middle é sempre Errado.

Supor que VPN é sinônimo de IPsec. IPsec, L2TP, PPTP, SSTP e SSL/TLS são todos bases válidas de VPN, e itens que os listam como exemplos são Certo.

Recusar a expressão “certificado SSL”. É o mesmo certificado X.509 que o TLS usa; a nomenclatura comercial não torna o item errado.