En una red privada (como en el uso de un espacio de direcciones IP privadas) en un proveedor de la nube, otros clientes tienen acceso a la misma red privada. He asegurado la comunicación entre muchos hosts y servicios con TLS provisto por Stunnel.
Fondo: Configuración de Stunnel actual
Para simplificar la situación actual, concentrémonos en la comunicación entre dos nodos, A (dirección IP IP_A ) y B ( IP_B ). Un ejemplo del Stunnel, desde el host A:
; [ This config only shows the crypto-relevant parts ]
; Disable support for insecure SSLv2 protocol and low-strength ciphers
ciphers = TLSv1.2:TLSv1.1:TLSv1:SSLv3:!SSLv2:!SSLv1:!LOW:!eNULL:!aNULL:!ADH:!EXP:!MD5@STRENGTH
sslVersion = TLSv1
; The following options provide additional security at some performance penalty
; Default ECDH/DH parameters are strong/conservative, so it is quite safe to
; comment out these lines in order to get a performance boost
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE
verify = 2
[my-service-B]
client = yes
accept = 127.0.0.1:15674
connect = IP_B:15675
CApath = /etc/stunnel/ssl/my-service/certs
CRLfile = /etc/stunnel/ssl/my-service/ca-crl.pem
cert = /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
key = /etc/stunnel/ssl/my-service/private/my-service-key.pem
La configuración de Stunnel en el host B es idéntica, excepto que La sección de servicio ha sido reemplazada por:
[my-service-localhost]
client = no
accept = IP_B:15675
connect = localhost:15674
; [ … the key and certificates are the same … ]
Los certificados utilizan una clave RSA de 2048 bits. Cuando incluyo la salida de depuración en el registro, Stunnel informa
Could not load DH parameters from /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
Using hardcoded DH parameters
DH initialized with 2048-bit key
ECDH initialized with curve prime256v1
durante el inicio. Además, cuando el host A se conecta, el registro incluye las entradas
SSL accepted: new session negotiated
Negotiated TLSv1/SSLv3 ciphersuite: ECDHE-RSA-AES256-SHA (256-bit encryption)
IPSec
Ahora, me pregunto qué configuración de IPSec proporcionará el mismo nivel de seguridad de transporte que la configuración TLS / Stunnel anterior, tanto con respecto a los algoritmos de cifrado y las claves utilizadas para los encabezados de autenticación IPSec (AH), que encapsulan la carga útil de seguridad (ESP). y las políticas de seguridad? Sé que IPSec protege todo el tráfico de red entre los hosts afectados, mientras que TLS solo protege el tráfico para los puertos / aplicaciones configurados, por lo que no es lo que estoy preguntando.
De acuerdo con la página de manual setkey(8) , los algoritmos de autenticación disponibles para AH son:
algorithm keylen (bits)
hmac-md5 128 ah: rfc2403
128 ah-old: rfc2085
hmac-sha1 160 ah: rfc2404
160 ah-old: 128bit ICV (no document)
keyed-md5 128 ah: 96bit ICV (no document)
128 ah-old: rfc1828
keyed-sha1 160 ah: 96bit ICV (no document)
160 ah-old: 128bit ICV (no document)
null 0 to 2048 for debugging
hmac-sha256 256 ah: 96bit ICV
(draft-ietf-ipsec-ciph-sha-256-00)
256 ah-old: 128bit ICV (no document)
hmac-sha384 384 ah: 96bit ICV (no document)
384 ah-old: 128bit ICV (no document)
hmac-sha512 512 ah: 96bit ICV (no document)
512 ah-old: 128bit ICV (no document)
hmac-ripemd160 160 ah: 96bit ICV (RFC2857)
ah-old: 128bit ICV (no document)
aes-xcbc-mac 128 ah: 96bit ICV (RFC3566)
128 ah-old: 128bit ICV (no document)
tcp-md5 8 to 640 tcp: rfc2385 (tcp-md5 support only on BSD)
y los algoritmos de cifrado disponibles para ESP son:
algorithm keylen (bits)
des-cbc 64 esp-old: rfc1829, esp: rfc2405
3des-cbc 192 rfc2451
null 0 to 2048 rfc2410
blowfish-cbc 40 to 448 rfc2451
cast128-cbc 40 to 128 rfc2451
des-deriv 64 ipsec-ciph-des-derived-01
3des-deriv 192 no document
rijndael-cbc 128/192/256 rfc3602
twofish-cbc 0 to 256 draft-ietf-ipsec-ciph-aes-cbc-01
aes-ctr 160/224/288 draft-ietf-ipsec-ciph-aes-ctr-03
camellia-cbc 128/192/256 rfc4312
Note that the first 128 bits of a key for aes-ctr will be used as AES
key, and the remaining 32 bits will be used as nonce.
Por supuesto, en el caso de que varias combinaciones de algoritmos AH y ESP y longitudes de clave proporcionen un nivel de seguridad equivalente al de la configuración de STunnel anterior, me gustaría optimizar para un mayor ancho de banda y un menor uso de CPU.
Además, ¿hay una lista de (aproximadamente) pares de configuración de TLS e IPSec equivalentes (algoritmos y longitudes de clave)?
Actualizar
Cuando escribí el "nivel de seguridad" más arriba, probablemente debería haber sido más específico y referido a un concepto como "fortaleza de seguridad" o "bits de seguridad", según lo define el Instituto Nacional de Estándares y Tecnología de EE. UU. NIST) en Publicación especial NIST 800-57: Recomendación para la gestión de claves - Parte 1: General Revisión 3) :
Un número asociado con la cantidad de trabajo (es decir, el número de Operaciones) que se requiere para romper un algoritmo criptográfico o sistema. En esta Recomendación, la fuerza de seguridad se especifica en bits y es un valor específico del conjunto {80, 112, 128, 192, 256}
Sin embargo, tenga en cuenta que bits de seguridad no es (necesariamente) igual a la longitud de la clave utilizada para un cifrado en particular. Además, en la sección "5.6.1 Fortalezas de algoritmos comparables", anotan (énfasis agregado por mí):
[...] dos algoritmos se consideran de fuerza comparable para los tamaños de clave dados (X e Y) si la cantidad de trabajo necesario para "romper los algoritmos" o determinar las claves (con los tamaños de clave dados) es aproximadamente el mismo usando un recurso dado. La fuerza de seguridad de un algoritmo para un tamaño de clave dado se describe tradicionalmente en términos de la cantidad de trabajo necesario para probar todas las claves de un algoritmo simétrico con un tamaño de clave de "X" que no sea corto. ataques de corte (es decir, el ataque más eficiente es probar todas las claves posibles).
Por lo tanto, cuando pregunté qué configuración IPSec proporcionará el mismo nivel de seguridad de transporte que la configuración TLS / Stunnel anterior, la respuesta probablemente dependerá de la fuerza de cifrado del cifrado negociado por Stunnel, como se mencionó anteriormente, combinado con cualquier conocimiento de cómo el modelo de seguridad IPSec frente al modelo de seguridad TLS podría afectar la efectividad del cifrado y / o la seguridad general del transporte.