¿Instalador de VPN desde un espejo? Verifique primero al editor

El túnel funcionó, la interfaz apareció y la sesión se mantuvo estable durante una semana. Nada de eso le dice quién construyó el instalador. Un cliente VPN se ejecuta con privilegios suficientes para reescribir rutas y leer credenciales, así que el editor forma parte del modelo de amenazas, no es una nota al pie.

Haga las comprobaciones en orden y deténgase en la primera que falle. Son baratas y cada una cierra una brecha distinta.

Primer paso: Descargue del canal que el proyecto nombra

Cada proyecto documenta dónde viven sus versiones, y esa página es la referencia. Las compilaciones comunitarias, las fichas de las tiendas y los portales de proveedores son todos canales legítimos. Cada uno es legítimo solo cuando el propio proyecto apunta a él. Esa es la prueba, y no es lo mismo que parecer oficial.

Un archivo con el nombre del proyecto no demuestra nada. Cambiar el nombre de un instalador es una operación de un segundo, y el nombre es lo primero que muestra un resultado de búsqueda.

Segundo paso: Verifique la firma contra una identidad conocida

La verificación de firma responde bien a una pregunta estrecha. Le dice que una identidad concreta firmó este binario y que el binario no ha cambiado desde entonces. Responde una pregunta y rechaza otra. No puede decirle si esa identidad es la que usted quería 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

Lea la identidad, no la palabra de estado. Un desarrollador ajeno con un certificado válido produce una firma válida. Un sistema operativo que informa de un editor reconocido solo le ha dicho que alguien pagó por un certificado.

Tercer paso: Compare el hash con una fuente independiente

Una suma de comprobación demuestra la coincidencia con un valor de referencia. Si la referencia llegó junto a la descarga, ambas pueden estar mal a la vez y la comparación aún pasa. Ese es el modo de fallo en la mayoría de los tutoriales. El hash está en la misma página que el archivo que describe.

# 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

Cuando un proyecto publica sumas de comprobación firmadas o un manifiesto de versión firmado, verifique la firma sobre la lista en lugar de cada archivo por separado. Así una referencia de confianza cubre toda la versión.

Después de la instalación: Mantenga la ruta de actualización

Un canal con soporte sigue importando después de que termine la instalación. Las compilaciones reempaquetadas pueden traer su propio actualizador, y ese actualizador decide qué se ejecuta el mes que viene. Una compilación que nunca se actualiza no es más segura. Simplemente es más antigua.

Anote cómo se supone que debe actualizarse el cliente y si un sistema de gestión se encarga de ese paso. Si la respuesta es una descarga manual de un foro, la pregunta de la cadena de suministro nunca se cerró de verdad.

Dos orígenes, no uno

El desarrollador del cliente y el emisor del perfil son partes separadas. Un cliente oficial que importa un perfil de un operador ajeno es un arreglo normal, y el perfil merece su propia revisión: quién lo emitió, cómo se entregó y si el certificado del servidor coincide con el nombre que espera.

Mantenga ambos orígenes identificables en sus notas. En el momento en que se sustituye un cliente o se restaura un dispositivo desde una copia de seguridad, esas dos líneas son lo que impide que una compilación desconocida o un perfil desconocido vuelvan con el resto de los datos.