Instalador de VPN de um espelho? Verifique o editor primeiro

O túnel funcionou, a interface apareceu e a sessão permaneceu estável durante uma semana. Nada disso diz quem construiu o instalador. Um cliente VPN é executado com privilégios suficientes para reescrever rotas e ler credenciais, portanto o editor faz parte do modelo de ameaças, não é uma nota de rodapé.

Faça as verificações na ordem e pare na primeira que falhar. Elas são baratas, e cada uma fecha uma lacuna diferente.

Primeiro passo: Baixe do canal que o projeto nomeia

Cada projeto documenta onde ficam as suas versões, e essa página é a referência. Builds da comunidade, fichas de lojas e portais de fornecedores são todos canais legítimos. Cada um é legítimo apenas quando o próprio projeto aponta para ele. Esse é o teste, e não é o mesmo que parecer oficial.

Um ficheiro com o nome do projeto não prova nada. Renomear um instalador é uma operação de um segundo, e o nome é o que um resultado de pesquisa mostra primeiro.

Segundo passo: Verifique a assinatura contra uma identidade conhecida

A verificação de assinatura responde bem a uma pergunta estreita. Diz-lhe que uma identidade específica assinou este binário e que o binário não mudou desde então. Responde a uma pergunta e recusa outra. Não pode dizer se essa identidade é aquela em que queria confiar.

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

Leia a identidade, não a palavra de estado. Um programador não relacionado com um certificado válido produz uma assinatura válida. Um sistema operativo que reporta um editor reconhecido apenas lhe disse que alguém pagou por um certificado.

Terceiro passo: Compare o hash com uma fonte independente

Uma soma de verificação prova a concordância com um valor de referência. Se a referência chegou ao lado da transferência, ambas podem estar erradas em conjunto e a comparação ainda passa. Esse é o modo de falha na maioria dos tutoriais. O hash fica na mesma página que o ficheiro que descreve.

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

Quando um projeto publica somas de verificação assinadas ou um manifesto de versão assinado, verifique a assinatura sobre a lista em vez de cada ficheiro isoladamente. Assim uma referência de confiança cobre toda a versão.

Depois da instalação: Mantenha o caminho de atualização

Um canal suportado continua a importar depois de a instalação terminar. Builds reempacotados podem trazer o seu próprio atualizador, e esse atualizador decide o que corre no mês seguinte. Um build que nunca é atualizado não é mais seguro. É simplesmente mais antigo.

Registe como o cliente deve ser atualizado e se um sistema de gestão detém esse passo. Se a resposta for um download manual de um fórum, a questão da cadeia de fornecimento nunca foi realmente encerrada.

Duas origens, não uma

O programador do cliente e o emissor do perfil são partes separadas. Um cliente oficial que importa um perfil de um operador não relacionado é um arranjo normal, e o perfil merece a sua própria análise: quem o emitiu, como foi entregue e se o certificado do servidor corresponde ao nome que espera.

Mantenha ambas as origens identificáveis nas suas notas. No momento em que um cliente é substituído ou um dispositivo é restaurado a partir de uma cópia de segurança, são essas duas linhas que impedem que um build desconhecido ou um perfil desconhecido regressem com o resto dos dados.