37 Seguridad en Red
Siempre que Emacs establece cualquier conexión de red, pasa la conexión establecida al Gestor de Seguridad de Red (NSM, Network Security Manager). NSM es responsable de reforzar la seguridad de la red bajo su control. Actualmente, esto funciona utilizando las características de Seguridad de la Capa de Transporte (TLS).
La variable network-security-level determina el nivel de seguridad que aplica NSM. Si su valor es bajo, no se realiza ninguna comprobación de seguridad. Esto no es recomendable, y básicamente significará que no se puede confiar en tus conexiones de red. Sin embargo, esta configuración puede ser útil en circunstancias limitadas, como cuando se prueban problemas de red.
Si esta variable es media (que es el valor predeterminado), se realizarán una serie de comprobaciones. Si como resultado NSM determina que la conexión de red puede no ser de confianza, se lo hará saber, y le preguntará qué hacer con la conexión de red.
Puede decidir registrar una excepción de seguridad permanente para una conexión no verificada, una excepción temporal o rechazar la conexión por completo.
Además de las comprobaciones básicas de corrección de certificados, hay disponibles varias comprobaciones de algoritmos TLS. Algunas tecnologías de cifrado que antes se consideraban seguras han demostrado ser frágiles, por lo que Emacs (por defecto) le advierte de algunos de estos problemas.
El protocolo que comprueba la red se controla mediante la variable network-security-protocol-checks.
Es una lista donde el primer elemento de cada asociación es el nombre de la comprobación, y el segundo elemento es el nivel de seguridad donde la comprobación debería ser usada.
Un elemento como (rc4 medium) resultará en que la función nsm-protocol-check--rc4 sea llamada así: (nsm-protocol-check--rc4 host port status settings). La función debe devolver no nil si la conexión debe proceder y nil en caso contrario.
A continuación se muestra una lista de las comprobaciones realizadas en el nivel medio (medium) por defecto.
- No se puede verificar un certificado TLS (unable to verify a TLS certificate)
Si la conexión es TLS, SSL o STARTTLS, NSM comprobará si se puede verificar el certificado utilizado para establecer la identidad del servidor al que nos estamos conectando.
Aunque un certificado no válido suele ser motivo de preocupación (podría haber un Man-in-the-Middle (hombre en el medio) apropiándose de su conexión de red y robando su contraseña), puede haber razones válidas para seguir adelante con la conexión de todos modos. Por ejemplo, puede que el servidor utilice un certificado autofirmado o que el certificado haya caducado. Depende de Usted determinar si es aceptable continuar con la conexión.
- un certificado autofirmado ha cambiado (a self-signed certificate has changed)
Si previamente has aceptado un certificado autofirmado, pero ahora ha cambiado, eso podría significar que el servidor acaba de cambiar el certificado, pero también podría significar que la conexión de red ha sido secuestrada.
- conexión previamente encriptada ahora desencriptada (previously encrypted connection now unencrypted)
Si la conexión está sin cifrar, pero estaba cifrada en sesiones anteriores, esto podría significar que hay un proxy entre Usted y el servidor que elimina los anuncios STARTTLS, dejando la conexión sin cifrar. Esto suele ser muy sospechoso.
- Hablar con un servicio no encriptado al enviar una contraseña (talking to an unencrypted service when sending a password)
Cuando se conecta a un servidor IMAP o POP3, normalmente debería estar encriptado, porque es habitual enviar contraseñas a través de estas conexiones. Del mismo modo, si envía correo electrónico a través de SMTP que requiera una contraseña, normalmente querrá que esa conexión esté cifrada. Si la conexión no está cifrada, NSM le avisará.
- Diffie-Hellman con pocos bits de alta prioridad (Diffie-Hellman low prime bits)
Al realizar el intercambio de clave pública, el número de bits de primera prioridad debe ser lo suficientemente alto como para garantizar que el canal no pueda ser interceptado por terceros. Si este número es demasiado bajo, Emacs le avisará. (Esta es la comprobación diffie-hellman-prime-bits en network-security-protocol-checks).
- Cifrado de flujo RC4 (RC4 stream cipher)
Se cree que el cifrado de flujo RC4 es de baja calidad y puede permitir escuchas por parte de terceros. (Esta es la comprobación rc4 en network-security-protocol-checks).
- SHA1 en el certificado del host o en certificados intermedios (SHA1 in the host certificate or in intermediate certificates)
Se cree que si un certificado intermedio utiliza el algoritmo hash SHA1, terceros pueden emitir certificados haciéndose pasar por esa instancia emisora. Por tanto, estas conexiones son vulnerables a los ataques de hombre en el medio. (Se trata de las comprobaciones signature-sha1 e intermediate-sha1 en network-security-protocol-checks).
- SSL1, SSL2 y SSL3
Se cree que los protocolos anteriores a TLS1.0 son vulnerables a una variedad de ataques, y es posible que desee evitar el uso de estos si lo que está haciendo requiere una mayor seguridad. (Esta es la comprobación ssl en network-security-protocol-checks).
Si network-security-level es alto, se harán las siguientes comprobaciones, además de las anteriores:
- Cifrado 3DES
El cifrado de flujo 3DES proporciona como máximo 112 bits de seguridad efectiva, lo que se considera un nivel bajo. (Esta es la comprobación 3des en network-security-protocol-checks).
- un certificado validado cambia la clave pública (a validated certificate changes the public key)
Los servidores cambian sus claves de vez en cuando, y normalmente no hay de qué preocuparse. Sin embargo, si le preocupa que sus conexiones de red estén siendo secuestradas por agencias que tienen acceso a Autoridades de Certificación flexibles que emiten nuevos certificados para servicios de terceros, es posible que quiera estar al tanto de estos cambios.
Por último, si el nivel de seguridad de la red es paranoico, también se le notificará la primera vez que NSM vea cualquier certificado nuevo. Esto te permitirá inspeccionar todos los certificados de todas las conexiones que haga Emacs.
Las siguientes variables adicionales pueden utilizarse para controlar detalles del funcionamiento del NSM:
nsm-settings-file
Este es el archivo donde NSM almacena los detalles sobre las conexiones. Por defecto es
~/.emacs.d/network-security.data.
nsm-save-host-names
Por defecto, los nombres de host no se guardan para conexiones no STARTTLS. En su lugar se usa un hash host/puerto para identificar las conexiones. Esto significa que no se puede leer casualmente el archivo de configuración para ver a qué servidores se ha conectado el usuario. Si esta variable es
t, NSM también guardará los nombres de host en el archivonsm-settings.