SSTP e SSL 3.0: o rótulo contra a versão negociada

Duas pessoas podem olhar para a mesma implantação de SSTP e chegar a conclusões opostas. Uma lê a documentação do produto, vê as letras SSL e presume que o túnel está a executar um protocolo retirado há anos. A outra aponta para um handshake moderno e conclui que a questão está encerrada. Ambas argumentam a partir de rótulos em vez da versão negociada, e apenas uma dessas coisas é prova. A comparação que vale a pena fazer é entre o que o nome promete e o que o serviço realmente seleciona.

Duas respostas para a mesma pergunta

O argumento do rótulo é fácil de enunciar: o SSTP é descrito como um protocolo de túnel de sockets seguro, o nome histórico diz SSL, portanto a ligação tem de ser SSL 3.0. Sobrevive porque o nome vem mesmo dessa linhagem e porque a maioria de quem o repete nunca olhou para um handshake. Sobrevive também porque a conclusão soa prudente, como se presumir o pior fosse a escolha segura. Presumir o pior e medir a versão real são atividades diferentes, e só uma delas muda alguma coisa.

O argumento da prova faz uma pergunta mais estreita. Em que versão de protocolo este cliente e este servidor concordaram, neste endpoint, neste momento? A resposta vem do serviço que termina o TLS, não de uma página de marketing nem de um navegador que chegou a um site com nome semelhante.

Os dois argumentos diferem naquilo que conseguem provar. O rótulo não distingue uma implementação antiga de uma corrigida, e o handshake não consegue dizer o que faz um serviço alheio no mesmo host. Use o segundo e deixe de usar o primeiro.

Leia a versão que o serviço realmente seleciona

Comece por nomear os componentes: a implementação cliente, a implementação servidor, o endpoint TLS e tudo o que estiver no meio e termine e restabeleça TLS. Um balanceador de carga que termina TLS e fala HTTP simples com o backend muda de que dispositivo deve ler a política.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Registe o endpoint e a hora ao lado do resultado, porque uma alteração posterior da política torna inútil uma observação sem data. Repita a sonda a partir de um cliente no mesmo caminho de rede dos utilizadores que lhe importam, já que um dispositivo de interceção pode terminar TLS com as suas próprias definições. Se as duas posições discordarem, encontrou o componente que importa. Se concordarem, tem prova em vez de um slogan.

Separe o campo de registo da negociação

Um número de versão com aspeto antigo num campo não é o mesmo facto que uma sessão SSL 3.0. RFC 7568 trata a versão da camada de registo e o protocolo negociado como questões distintas, e é exatamente dessa distinção que vêm as respostas erradas e confiantes. Leia o protocolo negociado, depois a cifra, e só então tire uma conclusão sobre a sessão.

O mesmo documento é inequívoco quanto ao protocolo em si: o SSL 3.0 não deve ser usado, e a negociação ou o recuo para ele está proibida. A razão é a construção CBC quebrada que o ataque POODLE explorou, e isso é uma propriedade do protocolo e não a configuração de uma aplicação.

É por isso que «esta carga de trabalho é provavelmente difícil de explorar» não é argumento para manter o SSL 3.0 ativado. A exigência é remover o protocolo, não ganhar um debate sobre uma demonstração.

Retire o SSL 3.0 com uma política que consiga sustentar

No Windows, as definições de protocolo do Schannel ficam sob a chave Protocols e são lidas por função de cliente e por função de servidor, e é por isso que uma alteração que corrige um sentido pode deixar o outro intacto. As definições atuais e os seus requisitos de reinício estão documentados pela Microsoft, e uma biblioteca TLS de terceiros no mesmo host ignora-as por completo.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Altere a política pelo caminho de administração suportado, confirme que o serviço proprietário readquire a configuração e mantenha uma forma aprovada de reverter. Colar um script de registo amplo de outro ambiente é como a correção de um serviço se transforma numa paragem para todos os clientes TLS da máquina. O alcance do reinício importa aqui: uma definição que parece aplicada pode ainda estar em memória num serviço que não a recarregou.

Um par que ainda exige uma versão obsoleta precisa de uma atualização ou de um plano de migração. Uma exceção não documentada que restaura silenciosamente o protocolo antigo não é uma estratégia de compatibilidade e não sobreviverá à próxima auditoria.

Aceite a alteração com ligações novas

Teste com sessões novas depois da alteração de política, porque uma ligação estabelecida antes da alteração não prova nada sobre a configuração agora em vigor. Confirme que o protocolo aprovado tem sucesso e que o proibido falha através do processo de validação autorizado, e depois deixe a identidade do certificado e as verificações de confiança exatamente como estavam.

Lembre-se do que o handshake não cobre. O SSTP transporta autenticação PPP depois da camada TLS, portanto uma versão de protocolo moderna não diz nada sobre que utilizador foi autorizado nem a que recursos a sessão pode chegar. São controlos separados com provas separadas.

Escreva o resultado como serviço, backend, política permitida e versão observada. Esse registo responde com precisão à pergunta de segurança, o que nem o argumento do rótulo nem um argumento de inconveniência alguma vez fazem.