¿Los datos siempre se cifran en las comunicaciones IPv6?


30

Parece que no puedo obtener una respuesta directa a esta pregunta. Wikipedia dice que "IPsec es una parte integral del conjunto de protocolos base en IPv6", pero eso significa que TODAS las comunicaciones siempre están encriptadas, o significa que el encriptado es opcional, pero los dispositivos deben poder entenderlo (si se usa )?

Si el cifrado es opcional, ¿es el sistema operativo el que decide si usarlo o es la aplicación? ¿Los sistemas operativos y software populares generalmente permiten el cifrado?

Lo investigaría yo mismo, pero me falta conectividad IPv6.

Actualización: Ok, entonces es opcional. Mi pregunta de seguimiento: por lo general, ¿es la aplicación la que define si usar cifrado o es el sistema operativo?

Un ejemplo específico: imagine que tengo una versión reciente de Windows con soporte nativo para ipv6, y busco algo en ipv6.google.com usando Mozilla Firefox. ¿Estaría encriptado?


16
IPSec es como una cerradura en una puerta; puede ser parte de la puerta, pero no significa que la puerta esté necesariamente cerrada.
Chris S

@ Chris S: comentario impresionante, tienes mi voto positivo por eso.
SplinterReality

Respuestas:


31

No.

IPv6 tiene IPsec integrado como parte del protocolo, y no es un atornillado como lo es con IPv4. Sin embargo, esto no significa que esté habilitado de forma predeterminada, solo significa que es (en teoría) una sobrecarga más baja en la pila de red.

En general, el uso de IPsec se determina en el nivel de IP de la pila de red y, por lo tanto, está determinado por las propias políticas del sistema. por ejemplo, el Sistema A podría tener una política que requiera que AH y ESP tengan comunicación con la subred 4.0.0.0/8.

Actualización: para ser claros, a la aplicación no le importa, solo sabe que tiene que abrir una conexión de red en algún lugar y enviar / recibir datos. Luego, el sistema tiene que determinar si negociar IPsec para la conexión solicitada dada. IPsec está muy diseñado para ser un mecanismo de autenticación / encriptación de bajo nivel y está construido a propósito para que los protocolos y aplicaciones de alto nivel no tengan que preocuparse por ello.

Dicho esto, es solo otro control de seguridad a nivel de red, y no necesariamente debe usarse de manera aislada o confiable para garantizar la 'seguridad': si está tratando de resolver un problema de autenticación, es muy posible que desee aplicación para aplicar algún tipo de autenticación a nivel de usuario y dejar la autenticación a nivel de máquina en IPsec.


1
Gracias por descartar claramente un mito horriblemente popular.
Marcin

3
Oh, las cosas que pudieron haber sido. Quizás tengamos esto en IPv8 en unos pocos cientos de años.
Michael Hampton

1
No estoy de acuerdo: el cifrado siempre debe ser posible y, en el mejor de los casos, muy fácil. Obligar a un determinado tipo de control de seguridad, independientemente de la existencia de otros controles, es un poco miope con respecto a los casos de uso en los que activamente no desea el cifrado de nivel IP.
Growse

20

Respuesta corta: no.

Respuesta larga: IPsec se consideró al diseñar IPv6, en el sentido de que, a diferencia de IPv4, IPsec (cuando se usa) es parte del encabezado de IPv6.

Más explicación: en IPv4, IPsec se ejecuta sobre la propia IP. En realidad, es un protocolo de Capa 4 que se disfraza como un protocolo de Capa 3 (de modo que los protocolos L4 habituales de TCP y UDP aún podrán funcionar). El ESP (Carga de seguridad de encapsulación) no puede abarcar entre paquetes IP. Como resultado, los paquetes IPsec generalmente tendrán una capacidad de carga útil severamente reducida si se evita la fragmentación. Además, debido a que está encima de IP, el encabezado de IP no está protegido.

En IPv6, IPsec es parte de la propia IP. Puede abarcar paquetes, ya que el encabezado ESP ahora es parte del encabezado IP. Y debido a que está integrado con IP, se pueden proteger más partes del encabezado de IP.

Espero que mi explicación 'en pocas palabras' sea lo suficientemente clara.


1
En realidad, AH firma todo el paquete, lo que significa que nada se puede cambiar (es decir, NAT lo rompe). Es por eso que muy pocos túneles IPSec realmente usan AH. Y es uno de los muchos encabezados de extensión , no literalmente "parte del encabezado de IP".
Ricky Beam

2

A usted Pregunta de seguimiento:

El sistema operativo define cuándo usar el cifrado. Estas opciones de "política" se encuentran dentro de los paneles de control / políticas de configuración. Dice cosas como "si desea conectarse a cualquier dirección en la subred ab12 :: debe tener el secreto Blah1234". Hay opciones para usar PKI.

Por el momento, una aplicación no puede agregar a esta política o exigir que esta se configure. Hay una mención en la sección de ipv6 del socket de Linux "Falta el soporte de IPSec para los encabezados EH y AH", por lo que la gente ha pensado en esto, pero actualmente no hay implementaciones de trabajo conocidas.


1

A su pregunta de seguimiento sí y no.

Las aplicaciones pueden especificar el cifrado, pero el cifrado se realiza a nivel de aplicación. Hay una amplia variedad de pares de protocolos encriptados / no encriptados que utilizan diferentes puertos como HTTP / HTTPS, LDAP / LDAPS, IMAP / IMAPS y SMTP / SSMTP. Todos ellos usan encriptación SSL o TLS. Algunos servicios ofrecerán una opción startTLS que permite iniciar una conexión cifrada en el puerto normalmente no cifrado. SSH es una aplicación que siempre usa una conexión encriptada. El cifrado es de extremo a extremo para estos casos. (Existe un algoritmo de cifrado NULL que se puede usar, y el contenido cifrado se transportará sin cifrar).

IPSEC está configurado por el administrador y la aplicación no sabrá si la conexión está encriptada o no. He visto principalmente que IPSEC se utiliza para unir el tráfico entre las LAN a través de conexiones no seguras (conexiones VPN). Creo que IPSEC puede aplicarse solo a una parte de la ruta, por lo que en algunos segmentos de red los datos se transmiten de forma clara (sin cifrar).

Si tengo la opción, usaré el cifrado de aplicaciones ya que el cifrado de red no se usa mucho.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.