Seguridad de red: capa de transporte

La seguridad de la red implica proteger los datos contra ataques mientras se encuentran en tránsito en una red. Para lograr este objetivo, se han diseñado muchos protocolos de seguridad en tiempo real. Existen estándares populares para protocolos de seguridad de red en tiempo real, como S / MIME, SSL / TLS, SSH e IPsec. Como se mencionó anteriormente, estos protocolos funcionan en diferentes capas del modelo de red.

En el último capítulo, discutimos algunos protocolos populares que están diseñados para proporcionar seguridad en la capa de aplicación. En este capítulo, analizaremos el proceso para lograr la seguridad de la red en la capa de transporte y los protocolos de seguridad asociados.

Para la red basada en el protocolo TCP / IP, las capas físicas y de enlace de datos se implementan normalmente en el terminal de usuario y el hardware de la tarjeta de red. Las capas TCP e IP se implementan en el sistema operativo. Todo lo que esté por encima de TCP / IP se implementa como proceso de usuario.

Necesidad de seguridad en la capa de transporte

Analicemos una transacción comercial típica basada en Internet.

Bob visita el sitio web de Alice para vender productos. En un formulario en el sitio web, Bob ingresa el tipo de bien y la cantidad deseada, su dirección y los detalles de la tarjeta de pago. Bob hace clic en Enviar y espera la entrega de los productos con un débito del importe del precio de su cuenta. Todo esto suena bien, pero en ausencia de seguridad de red, Bob podría tener algunas sorpresas.

  • Si las transacciones no utilizaban la confidencialidad (cifrado), un atacante podría obtener la información de su tarjeta de pago. El atacante puede realizar compras a expensas de Bob.

  • Si no se utiliza una medida de integridad de los datos, un atacante podría modificar el pedido de Bob en términos de tipo o cantidad de productos.

  • Por último, si no se utiliza la autenticación del servidor, un servidor podría mostrar el famoso logotipo de Alice, pero el sitio podría ser un sitio malicioso mantenido por un atacante, que se hace pasar por Alice. Después de recibir la orden de Bob, podría tomar el dinero de Bob y huir. O podría llevar a cabo un robo de identidad recopilando el nombre de Bob y los datos de la tarjeta de crédito.

Los esquemas de seguridad de la capa de transporte pueden abordar estos problemas mejorando la comunicación de red basada en TCP / IP con confidencialidad, integridad de datos, autenticación de servidor y autenticación de cliente.

La seguridad en esta capa se usa principalmente para asegurar transacciones web basadas en HTTP en una red. Sin embargo, puede ser utilizado por cualquier aplicación que se ejecute sobre TCP.

Filosofía del diseño TLS

Los protocolos Transport Layer Security (TLS) operan por encima de la capa TCP. El diseño de estos protocolos utiliza interfaces de programa de aplicación (API) populares para TCP, llamadas "sockets" para interactuar con la capa TCP.

Las aplicaciones ahora están interconectadas a la capa de seguridad de transporte en lugar de a TCP directamente. La capa de seguridad de transporte proporciona una API simple con sockets, que es similar y análoga a la API de TCP.

En el diagrama anterior, aunque TLS reside técnicamente entre la aplicación y la capa de transporte, desde la perspectiva común es un protocolo de transporte que actúa como una capa TCP mejorada con servicios de seguridad.

TLS está diseñado para operar a través de TCP, el protocolo confiable de capa 4 (no en el protocolo UDP), para simplificar el diseño de TLS, porque no tiene que preocuparse por el 'tiempo de espera' y la 'retransmisión de datos perdidos'. La capa de TCP continúa haciendo eso como de costumbre, lo que satisface la necesidad de TLS.

¿Por qué TLS es popular?

La razón de la popularidad del uso de una seguridad en la capa de transporte es la simplicidad. El diseño e implementación de la seguridad en esta capa no requiere ningún cambio en los protocolos TCP / IP que se implementan en un sistema operativo. Solo los procesos y aplicaciones del usuario deben diseñarse / modificarse, lo que es menos complejo.

Capa de conexión segura (SSL)

En esta sección, discutimos la familia de protocolos diseñados para TLS. La familia incluye las versiones 2 y 3 de SSL y el protocolo TLS. SSLv2 ahora ha sido reemplazado por SSLv3, por lo que nos centraremos en SSL v3 y TLS.

Breve historia de SSL

En el año 1995, Netscape desarrolló SSLv2 y se usó en Netscape Navigator 1.1. La versión 1 de SSL nunca se publicó ni se utilizó. Más tarde, Microsoft mejoró SSLv2 e introdujo otro protocolo similar llamado Tecnología de comunicaciones privadas (PCT).

Netscape mejoró sustancialmente SSLv2 en varios problemas de seguridad e implementó SSLv3 en 1999. El Grupo de Trabajo de Ingeniería de Internet (IETF) posteriormente introdujo un protocolo TLS (Seguridad de la Capa de Transporte) similar como estándar abierto. El protocolo TLS no es interoperable con SSLv3.

TLS modificó los algoritmos criptográficos para la expansión y autenticación de claves. Además, TLS sugirió el uso de criptografía abierta Diffie-Hellman (DH) y Digital Signature Standard (DSS) en lugar de la criptografía RSA patentada utilizada en SSL. Pero debido a la expiración de la patente RSA en 2000, no existían razones sólidas para que los usuarios cambiaran de SSLv3 ampliamente implementado a TLS.

Características destacadas de SSL

Las características más destacadas del protocolo SSL son las siguientes:

  • SSL proporciona seguridad en la conexión de red a través de:

    • Confidentiality - La información se intercambia de forma cifrada.

    • Authentication- Las entidades de comunicación se identifican mediante el uso de certificados digitales. La autenticación del servidor web es obligatoria, mientras que la autenticación del cliente se mantiene opcional.

    • Reliability - Mantiene controles de integridad de mensajes.

  • SSL está disponible para todas las aplicaciones TCP.

  • Compatible con casi todos los navegadores web.

  • Proporciona facilidad para hacer negocios con nuevas entidades en línea.

  • Desarrollado principalmente para comercio electrónico web.

Arquitectura de SSL

SSL es específico de TCP y no funciona con UDP. SSL proporciona una interfaz de programación de aplicaciones (API) a las aplicaciones. Las bibliotecas / clases C y Java SSL están disponibles.

El protocolo SSL está diseñado para interactuar entre la aplicación y la capa de transporte, como se muestra en la siguiente imagen:

SSL en sí no es un protocolo de una sola capa como se muestra en la imagen; de hecho, está compuesto por dos subcapas.

  • La subcapa inferior se compone de un componente del protocolo SSL llamado Protocolo de registro SSL. Este componente proporciona servicios de integridad y confidencialidad.

  • La subcapa superior consta de tres componentes de protocolo relacionados con SSL y un protocolo de aplicación. El componente de la aplicación proporciona el servicio de transferencia de información entre las interacciones cliente / servidor. Técnicamente, también puede operar sobre la capa SSL. Tres componentes del protocolo relacionados con SSL son:

    • Protocolo de protocolo de enlace SSL
    • Cambiar el protocolo de especificación de cifrado
    • Protocolo de alerta.

  • Estos tres protocolos gestionan todos los intercambios de mensajes SSL y se describen más adelante en esta sección.

Funciones de los componentes del protocolo SSL

Los cuatro subcomponentes del protocolo SSL manejan varias tareas para una comunicación segura entre la máquina cliente y el servidor.

  • Protocolo de registro

    • La capa de registro formatea los mensajes de protocolo de la capa superior.

    • Fragmenta los datos en bloques manejables (longitud máxima de 16 KB). Opcionalmente, comprime los datos.

    • Cifra los datos.

    • Proporciona un encabezado para cada mensaje y un hash (código de autenticación de mensaje (MAC)) al final.

    • Entrega los bloques formateados a la capa TCP para su transmisión.

  • Protocolo de protocolo de enlace SSL

    • Es la parte más compleja de SSL. Se invoca antes de que se transmitan los datos de la aplicación. Crea sesiones SSL entre el cliente y el servidor.

    • El establecimiento de la sesión implica la autenticación del servidor, la negociación de claves y algoritmos, el establecimiento de claves y la autenticación del cliente (opcional).

    • Una sesión se identifica mediante un conjunto único de parámetros de seguridad criptográficos.

    • Varias conexiones TCP seguras entre un cliente y un servidor pueden compartir la misma sesión.

    • Acciones de protocolo de handshake a través de cuatro fases. Estos se discuten en la sección siguiente.

  • Protocolo ChangeCipherSpec

    • La parte más simple del protocolo SSL. Se compone de un único mensaje intercambiado entre dos entidades comunicantes, el cliente y el servidor.

    • A medida que cada entidad envía el mensaje ChangeCipherSpec, cambia su lado de la conexión al estado seguro según lo acordado.

    • El estado pendiente de los parámetros de cifrado se copia en el estado actual.

    • El intercambio de este mensaje indica que todos los intercambios de datos futuros están cifrados y la integridad está protegida.

  • Protocolo de alerta SSL

    • Este protocolo se utiliza para informar errores, como mensajes inesperados, MAC de registro incorrecto, negociación de parámetros de seguridad fallida, etc.

    • También se utiliza para otros fines, como notificar el cierre de la conexión TCP, notificar la recepción de un certificado incorrecto o desconocido, etc.

Establecimiento de sesión SSL

Como se mencionó anteriormente, hay cuatro fases para el establecimiento de una sesión SSL. Estos se manejan principalmente mediante el protocolo SSL Handshake.

Phase 1 - Establecimiento de capacidades de seguridad.

  • Esta fase comprende el intercambio de dos mensajes: Client_hello y Server_hello .

  • Client_hello contiene una lista de algoritmos criptográficos admitidos por el cliente, en orden decreciente de preferencia.

  • Server_hello contiene la especificación de cifrado seleccionada (CipherSpec) y un nuevo session_id .

  • El CipherSpec contiene campos como -

    • Algoritmo de cifrado (DES, 3DES, RC2 y RC4)

    • Algoritmo MAC (basado en MD5, SHA-1)

    • Algoritmo de clave pública (RSA)

    • Ambos mensajes tienen "nonce" para evitar el ataque de repetición.

Phase 2 - Autenticación e intercambio de claves del servidor.

  • El servidor envía el certificado. El software del cliente viene configurado con claves públicas de varias organizaciones "confiables" (CA) para verificar el certificado.

  • El servidor envía el conjunto de cifrado elegido.

  • El servidor puede solicitar un certificado de cliente. Normalmente no se hace.

  • El servidor indica el final de Server_hello .

Phase 3 - Autenticación de clientes e intercambio de claves.

  • El cliente envía el certificado, solo si lo solicita el servidor.

  • También envía el Pre-master Secret (PMS) cifrado con la clave pública del servidor.

  • El cliente también envía el mensaje Certificate_verify si él envía el certificado para demostrar que tiene la clave privada asociada con este certificado. Básicamente, el cliente firma un hash de los mensajes anteriores.

Phase 4 - Terminar.

  • El cliente y el servidor se envían mensajes Change_cipher_spec entre sí para hacer que el estado de cifrado pendiente se copie en el estado actual.

  • A partir de ahora, todos los datos están encriptados y protegidos por integridad.

  • El mensaje "Finalizado" de cada extremo verifica que el intercambio de claves y los procesos de autenticación se hayan realizado correctamente.

Las cuatro fases, discutidas anteriormente, ocurren dentro del establecimiento de la sesión TCP. El establecimiento de la sesión SSL comienza después de TCP SYN / SYNACK y finaliza antes de TCP Fin.

Reanudación de una sesión desconectada

  • Es posible reanudar una sesión desconectada (a través de un mensaje de alerta ), si el cliente envía un hello_request al servidor con la información de session_id cifrada .

  • Luego, el servidor determina si el session_id es válido. Si se valida, intercambia ChangeCipherSpec y los mensajes terminados con el cliente y reanuda las comunicaciones seguras.

  • Esto evita volver a calcular los parámetros de cifrado de la sesión y ahorra computación en el servidor y en el cliente.

Claves de sesión SSL

Hemos visto que durante la Fase 3 del establecimiento de la sesión SSL, el cliente envía un secreto pre-maestro al servidor encriptado usando la clave pública del servidor. El secreto maestro y varias claves de sesión se generan de la siguiente manera:

  • El secreto maestro se genera (a través del generador de números pseudoaleatorios) usando -

    • El secreto del pre-maestro.

    • Dos nonces (RA y RB) intercambiados en los mensajes client_hello y server_hello.

  • A continuación, se derivan seis valores secretos de este secreto maestro como:

    • Clave secreta utilizada con MAC (para datos enviados por servidor)

    • Clave secreta utilizada con MAC (para datos enviados por el cliente)

    • Clave secreta e IV utilizados para el cifrado (por servidor)

    • Clave secreta e IV utilizados para el cifrado (por cliente)

Protocolo TLS

Para proporcionar un estándar de Internet abierto de SSL, IETF lanzó el protocolo Transport Layer Security (TLS) en enero de 1999. TLS se define como un estándar de Internet propuesto en RFC 5246.

Características sobresalientes

  • El protocolo TLS tiene los mismos objetivos que SSL.

  • Permite que las aplicaciones cliente / servidor se comuniquen de manera segura mediante la autenticación, evitando escuchas y resistiendo la modificación de mensajes.

  • El protocolo TLS se encuentra por encima de la capa TCP de transporte orientada a la conexión confiable en la pila de capas de red.

  • La arquitectura del protocolo TLS es similar al protocolo SSLv3. Tiene dos subprotocolos: el protocolo TLS Record y el protocolo TLS Handshake.

  • Aunque los protocolos SSLv3 y TLS tienen una arquitectura similar, se realizaron varios cambios en la arquitectura y el funcionamiento, en particular para el protocolo de reconocimiento.

Comparación de protocolos TLS y SSL

Existen ocho diferencias principales entre los protocolos TLS y SSLv3. Estos son los siguientes:

  • Protocol Version - El encabezado del segmento del protocolo TLS lleva el número de versión 3.1 para diferenciar entre el número 3 transportado por el encabezado del segmento del protocolo SSL.

  • Message Authentication- TLS emplea un código de autenticación de mensajes hash con clave (H-MAC). El beneficio es que H-MAC opera con cualquier función hash, no solo MD5 o SHA, como lo establece explícitamente el protocolo SSL.

  • Session Key Generation - Existen dos diferencias entre el protocolo TLS y SSL para la generación de material de claves.

    • El método de cálculo de secretos maestros y pre-maestros es similar. Pero en el protocolo TLS, el cálculo del secreto maestro utiliza el estándar HMAC y la salida de función pseudoaleatoria (PRF) en lugar de MAC ad-hoc.

    • El algoritmo para calcular las claves de sesión y los valores de inicio (IV) es diferente en TLS que en el protocolo SSL.

  • Mensaje de protocolo de alerta -

    • El protocolo TLS admite todos los mensajes utilizados por el protocolo de alerta de SSL, excepto que ningún mensaje de alerta de certificado se vuelve redundante. El cliente envía un certificado vacío en caso de que no se requiera la autenticación del cliente.

    • Se incluyen muchos mensajes de alerta adicionales en el protocolo TLS para otras condiciones de error como record_overflow, decode_error, etc.

  • Supported Cipher Suites- SSL admite conjuntos de cifrado RSA, Diffie-Hellman y Fortezza. El protocolo TLS admite todos los trajes excepto Fortezza.

  • Client Certificate Types- TLS define los tipos de certificados que se solicitarán en un mensaje de solicitud de certificado . SSLv3 es compatible con todos estos. Además, SSL admite otros tipos de certificados como Fortezza.

  • CertificateVerify y mensajes terminados -

    • En SSL, se utiliza un procedimiento de mensaje complejo para el mensaje certificate_verify . Con TLS, la información verificada está contenida en los propios mensajes de protocolo de enlace, evitando así este complejo procedimiento.

    • El mensaje terminado se calcula de diferentes maneras en TLS y SSLv3.

  • Padding of Data- En el protocolo SSL, el relleno agregado a los datos del usuario antes del cifrado es la cantidad mínima requerida para que el tamaño total de los datos sea igual a un múltiplo de la longitud del bloque del cifrado. En TLS, el relleno puede ser cualquier cantidad que dé como resultado un tamaño de datos que sea un múltiplo de la longitud del bloque de cifrado, hasta un máximo de 255 bytes.

Las diferencias anteriores entre los protocolos TLS y SSLv3 se resumen en la siguiente tabla.

Navegación segura: HTTPS

En esta sección, analizaremos el uso del protocolo SSL / TLS para realizar una navegación web segura.

HTTPS definido

El protocolo Hyper Text Transfer Protocol (HTTP) se utiliza para la navegación web. La función de HTTPS es similar a HTTP. La única diferencia es que HTTPS proporciona una navegación web "segura". HTTPS significa HTTP sobre SSL. Este protocolo se utiliza para proporcionar la conexión encriptada y autenticada entre el navegador web del cliente y el servidor del sitio web.

La navegación segura a través de HTTPS garantiza que el siguiente contenido esté encriptado:

  • URL de la página web solicitada.
  • Contenidos de la página web proporcionados por el servidor al cliente usuario.
  • Contenido de los formularios cumplimentados por el usuario.
  • Cookies establecidas en ambas direcciones.

Trabajo de HTTPS

El protocolo de aplicación HTTPS normalmente utiliza uno de los dos protocolos de seguridad de la capa de transporte más populares: SSL o TLS. El proceso de navegación segura se describe en los siguientes puntos.

  • Solicita una conexión HTTPS a una página web ingresando https: // seguido de URL en la barra de direcciones del navegador.

  • El navegador web inicia una conexión con el servidor web. El uso de https invoca el uso del protocolo SSL.

  • Una aplicación, navegador en este caso, usa el puerto del sistema 443 en lugar del puerto 80 (usado en el caso de http).

  • El protocolo SSL pasa por un protocolo de reconocimiento para establecer una sesión segura como se discutió en secciones anteriores.

  • El sitio web envía inicialmente su certificado digital SSL a su navegador. Tras la verificación del certificado, el protocolo de enlace SSL avanza para intercambiar los secretos compartidos de la sesión.

  • Cuando el servidor utiliza un certificado digital SSL de confianza, los usuarios pueden ver un icono de candado en la barra de direcciones del navegador. Cuando se instala un certificado de validación extendida en un sitio web, la barra de direcciones se vuelve verde.

  • Una vez establecida, esta sesión consta de muchas conexiones seguras entre el servidor web y el navegador.

Uso de HTTPS

  • El uso de HTTPS proporciona al usuario confidencialidad, autenticación del servidor e integridad del mensaje. Permite la conducción segura del comercio electrónico en Internet.

  • Evita que los datos se escuchen a escondidas y niega el robo de identidad, que son ataques comunes en HTTP.

Los navegadores web y servidores web actuales están equipados con soporte HTTPS. Sin embargo, el uso de HTTPS sobre HTTP requiere más potencia de cálculo en el cliente y en el servidor para llevar a cabo el cifrado y el protocolo de enlace SSL.

Protocolo de shell seguro (SSH)

Las características más destacadas de SSH son las siguientes:

  • SSH es un protocolo de red que se ejecuta sobre la capa TCP / IP. Está diseñado para reemplazar TELNET, que proporcionaba medios no seguros para la instalación de inicio de sesión remoto.

  • SSH proporciona una comunicación cliente / servidor segura y se puede utilizar para tareas como la transferencia de archivos y el correo electrónico.

  • SSH2 es un protocolo predominante que proporciona una seguridad de comunicación de red mejorada sobre la versión anterior SSH1.

Definición de SSH

SSH está organizado en tres subprotocolos.

  • Transport Layer Protocol- Esta parte del protocolo SSH proporciona confidencialidad de los datos, autenticación del servidor (host) e integridad de los datos. Opcionalmente, también puede proporcionar compresión de datos.

    • Server Authentication- Las claves de host son asimétricas como las claves públicas / privadas. Un servidor utiliza una clave pública para demostrar su identidad a un cliente. El cliente verifica que el servidor contactado sea un host "conocido" de la base de datos que mantiene. Una vez que el servidor está autenticado, se generan las claves de sesión.

    • Session Key Establishment- Después de la autenticación, el servidor y el cliente acuerdan el cifrado que se utilizará. Las claves de sesión las generan tanto el cliente como el servidor. Las claves de sesión se generan antes de la autenticación del usuario para que los nombres de usuario y las contraseñas se puedan enviar cifrados. Estas teclas generalmente se reemplazan a intervalos regulares (digamos, cada hora) durante la sesión y se destruyen inmediatamente después de su uso.

    • Data Integrity- SSH utiliza algoritmos de código de autenticación de mensajes (MAC) para verificar la integridad de los datos. Es una mejora sobre el CRC de 32 bits utilizado por SSH1.

  • User Authentication Protocol- Esta parte de SSH autentica al usuario en el servidor. El servidor verifica que el acceso se otorgue solo a los usuarios previstos. Actualmente se utilizan muchos métodos de autenticación, como contraseñas escritas, Kerberos, autenticación de clave pública, etc.

  • Connection Protocol - Esto proporciona múltiples canales lógicos a través de una única conexión SSH subyacente.

Servicios SSH

SSH proporciona tres servicios principales que permiten la provisión de muchas soluciones seguras. Estos servicios se describen brevemente a continuación:

  • Secure Command-Shell (Remote Logon)- Permite al usuario editar archivos, ver el contenido de directorios y acceder a aplicaciones en el dispositivo conectado. Los administradores de sistemas pueden iniciar / ver / detener servicios y procesos de forma remota, crear cuentas de usuario y cambiar permisos de archivos / directorios, etc. Todas las tareas que son factibles en el símbolo del sistema de una máquina ahora se pueden realizar de forma segura desde la máquina remota mediante el inicio de sesión remoto seguro.

  • Secure File Transfer- El Protocolo de transferencia de archivos SSH (SFTP) está diseñado como una extensión de SSH-2 para la transferencia segura de archivos. En esencia, es un protocolo separado en capas sobre el protocolo Secure Shell para manejar transferencias de archivos. SFTP cifra tanto el nombre de usuario / contraseña como los datos del archivo que se transfieren. Utiliza el mismo puerto que el servidor Secure Shell, es decir, el puerto del sistema no 22.

  • Port Forwarding (Tunneling)- Permite proteger los datos de aplicaciones basadas en TCP / IP no seguras. Una vez que se ha configurado el reenvío de puertos, Secure Shell redirige el tráfico de un programa (generalmente un cliente) y lo envía a través del túnel encriptado al programa en el otro lado (generalmente un servidor). Varias aplicaciones pueden transmitir datos a través de un único canal seguro multiplexado, lo que elimina la necesidad de abrir muchos puertos en un firewall o enrutador.

Beneficios y limitaciones

Los beneficios y limitaciones de emplear la seguridad de las comunicaciones en la capa de transporte son los siguientes:

  • Beneficios

    • Transport Layer Security es transparente para las aplicaciones.

    • El servidor está autenticado.

    • Los encabezados de la capa de aplicación están ocultos.

    • Es más detallado que los mecanismos de seguridad en la capa 3 (IPsec), ya que funciona a nivel de conexión de transporte.

  • Limitaciones

    • Aplicable solo a aplicaciones basadas en TCP (no UDP).

    • Los encabezados TCP / IP están claros.

    • Adecuado para la comunicación directa entre el cliente y el servidor. No se ocupa de aplicaciones seguras que utilizan cadenas de servidores (por ejemplo, correo electrónico)

    • SSL no proporciona no repudio ya que la autenticación del cliente es opcional.

    • Si es necesario, la autenticación del cliente debe implementarse por encima de SSL.

Resumen

En la última década ha surgido un gran número de aplicaciones web en Internet. Muchos portales de gobierno electrónico y comercio electrónico se han conectado. Estas aplicaciones requieren que la sesión entre el servidor y el cliente sea segura, proporcionando confidencialidad, autenticación e integridad de las sesiones.

Una forma de mitigar un posible ataque durante la sesión de un usuario es utilizar un protocolo de comunicación seguro. En este capítulo se analizan dos de estos protocolos de comunicación, Secure Sockets Layer (SSL) y Transport Layer Security (TLS). Ambos protocolos funcionan en la capa de transporte.

Otro protocolo de capa de transporte, Secure Shell (SSH), diseñado para reemplazar TELNET, proporciona medios seguros para la instalación de inicio de sesión remoto. Es capaz de proporcionar varios servicios como Secure Command Shell y SFTP.

El empleo de la seguridad de la capa de transporte tiene muchos beneficios. Sin embargo, el protocolo de seguridad diseñado en estas capas solo se puede utilizar con TCP. No brindan seguridad para las comunicaciones implementadas mediante UDP.