Protocolos de seguridad

[5.1] ¿Cómo estudiar este tema?

[5.2] Introducción

[5.3] IPsec

[5.4] SSL/TLS

[5.5] Redes privadas virtuales (VPN)

TEMA
 Esquema

Protocolos de seguridad

TEMA 5 – Esquema
IPSec SSL/TLS Redes virtuales privadas

Cabecera AH Arquitectura Datagrama

SSL TLS

2
Cabe cera ESP
SSL Record Protocol
ISAKMP e IKE
SSL Handshake
Modos: transporte y túnel Protocol

SSL Change Cipher

Spe c Protocol

SSL Alert Protocol

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Redes
 Seguridad en Redes

Ideas clave

5.1. ¿Cómo estudiar este tema?

Para estudiar este tema lee el capítulo 16«Protocolos de conexión segura» (páginas
223-229) del libro Criptografía y seguridad de computadores de Manuel Lucena,
disponible en:
https://openlibra.com/es/book/criptografia-y-seguridad-en-computadores

También será necesaria la lectura del capítulo 7.2 «SSL (Secure Socket Layer) y TLS
(Transport Layer Security)» (páginas 227-246) del libro Fundamentos de Seguridad en
Redes. Aplicaciones y Estándares de William Stallings, disponible en el aula virtual,
además de las Ideas clave que encontrarás a continuación.

Esta unidad pretende mostrarte los distintos protocolos que hacen posible realizar un
intercambio de información seguro a través de Internet. Todos los protocolos tienen
una fuerte base criptográfica.

Estos protocolos proporcionan uno o varios de los servicios de seguridad vistos en el

tema anterior. Por ejemplo, la confidencialidad de la información que la hace
inteligible para posibles atacantes, la autenticación del emisor/receptor del mensaje
para verificar su identidad. La autenticación de los extremos de la comunicación cobró
una especial importancia con el incremento del comercio electrónico. De esta
manera, se asegura que el emisor/receptor del mensaje es quién dice ser (es importante
para evitar casos, por ejemplo, de phising o fraudes bancarios).

Existen múltiples protocolos que, haciendo uso de algoritmos criptográficos, permiten

establecer un canal de comunicación seguro para el intercambio de información, entre
los que están el protocolo IPSec y el protocolo SSL que serán estudiados en
este tema. Para finalizar se realizará una introducción a las redes privadas
virtuales (VPN), las cuales permiten establecer un canal de comunicación seguro a
través de Internet.

TEMA 5 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

5.2. Introducción

Criptografía
Proviene del griego krypto, «oculto», y graphos, «escribir», y se define como la
parte de la criptología que se ocupa del estudio de algoritmos, protocolos y
sistemas que se emplean con el fin de proteger la información, el canal de
comunicación por el que circula y a las entidades implicadas.

El uso de la criptografía como medio de protección de información confidencial

es casi tan antiguo como la propia escritura y, siempre estaba ligado a los círculos
militares. No obstante, en la actualidad el escenario ha cambiado y el desarrollo de las
comunicaciones a través de dispositivos electrónicos viabiliza la transmisión y
almacenamiento de información sensible que necesita protección.

Un mensaje que circula a través de la red se expone esencialmente a dos amenazas:

Acceso a la información por entidades no

Modificaciones del mensaje
autorizadas

Debido a las amenazas a las que se expone un mensaje por la red, los principales
objetivos de la criptografía son preservar la confidencialidad de la información
transmitida y garantizar tanto la integridad de la información (no ha sido modificada)
como la autenticidad de los emisores/receptores de la misma.

TEMA 5 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

5.3. IPsec

IPsec [RFC4301] es un estándar que incorpora los servicios de seguridad apropiados a

nivel de red. Dichos servicios tienen por objetivo proporcionar confidencialidad,
integridad y autenticación de las comunicaciones en dicho nivel. El uso de IPsec es
opcional en IPv4 y aunque fue obligatorio en las primeras versiones del estándar
IPv6, recientemente, y para casos muy concretos, se ha permitido que sea opcional.

Asociación de seguridad

Una Asociación de Seguridad (SA - Security Association) es una relación entre dos o
más entidades que describe cómo estas utilizarán los servicios de seguridad para
comunicarse de forma segura. Se trata de un acuerdo entre las partes, y en el que se
establecen aspectos como los algoritmos de cifrado, la duración de la asociación, el
método de autenticación, etc.

Los protocolos de seguridad requieren la negociación de una serie de parámetros que

permitan el empleo de los mismos de manera adecuada. La asociación de seguridad es
la unidad básica de negociación que permite la especificación de las particularidades de
los servicios de seguridad.

La arquitectura de seguridad IP considera dos nuevos protocolos:

Cabecera de Autenticación Protocolo de Encapsulación Segura del Campo de

(AH - Authentication Header) Carga (ESP - Encapsulating Security Payload)

La cabecera de autenticación El protocolo de encapsulación segura del

[RFC4302] proporciona integridad y campo de carga [RFC4303] dota, además de
autenticación a los datagramas IP, de integridad y autenticación, de
forma que el receptor de un mensaje confidencialidad a los datagramas IP de forma
pueda detectar si este fue manipulado y que la información cifrada que contienen solamente
si el autor es quien dice ser. sea accesible para entidades autorizadas.

Cabecera de Autenticación: Protocolo AH

La cabecera de autenticación AH es un protocolo que proporciona mecanismos de

autenticación e integridad a los datagramas IP. Los datos de autenticación son
colocados tras la cabecera original del datagrama IP (Ilustración 1), así, los sistemas
que no estén participando en la autenticación pueden ignorar tales datos y encaminar
convenientemente dichos paquetes.

TEMA 5 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Cabecera IPv6 AH TCP Datos

Ilustración 1: Localización de la cabecera AH en una trama.

El rendimiento de la comunicación se verá mermado tanto en el lado del remitente

como en el del destinatario, que debe verificar cada datagrama IP que contenga una
cabecera AH.

Los datos de autenticación se calculan sobre el paquete entero, salvo aquellos campos
de la Cabecera IP que son modificados durante el camino como el TTL. Es necesario
que ambos extremos de la comunicación acuerden las características que van a regir
dicha comunicación de forma segura estableciendo para ello una asociación de
seguridad. En este caso y en el de ESP las asociaciones de seguridad son
unidireccionales, es decir, se establece al menos una asociación de seguridad para cada
sentido de la comunicación entre los extremos de la misma. Estas pueden ser
renovadas a los largo de la conexión.

La cabecera de autenticación tiene el siguiente formato (Ilustración 2):

Next Header Payload Length Reserved

Security Parameter Index

Sequence Number Field

Authentication Data

Ilustración 2: Cabecera de Autenticación.

» Next Header: Tipo de cabecera a continuación de esta.

» Payload Length: Tamaño de la cabecera en palabras de 32 bits.

» Reserved: Espacio reservado para usos futuros.

» Security Parameter Index (SPI): Representa a un número pseudoaleatorio de

32 bits que identifica a una determinada asociación de seguridad (SA). El índice SPI,
con la dirección destino IP y el protocolo de seguridad (AH), identifican
unívocamente a la asociación de seguridad para este datagrama.

TEMA 5 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

» Sequence Number: Previene frente a posibles ataques de reenvío.

» Authentication Data: Porta el código de autenticación del contenido siguiente. El

mecanismo generalmente utilizado es la autenticación mediante un algoritmo de
función resumen con clave.

El remitente deberá identificar la asociación de seguridad apropiada que indique el

algoritmo, la clave y cualquier otro parámetro de seguridad necesario. El remitente
calcula la información de autenticación, y la coloca en el campo de carga de la cabecera
AH y envía el paquete a su destino. El destinatario recibe el paquete, localiza la
asociación de seguridad correcta y comprueba la consistencia del campo de datos de
autenticación, si el proceso indica que el datagrama es válido, este es aceptado.

Encapsulación segura del campo de carga: Protocolo ESP

La cabecera ESP permite establecer un mecanismo para dotar del servicio de

confidencialidad en la capa de red (nivel IP), además de los de integridad y
autenticación que aportaba la cabecera AH. Esto es posible gracias al cifrado de los
datos. El protocolo soporta encryption-only y authentication-only en caso de que
solamente se quiera hacer uso de un servicio de seguridad particular. La localización de
un ESP en una trama puede verse en la siguiente ilustración:

Datos de
Cabecera IPv6 Cabecera ESP ESP Payload ESP Trailer
autentificación

Ilustración 3: Localización ESP en una trama.

Es necesario, al igual que en AH, que ambos extremos de la comunicación acuerden las
características que van a regir dicha comunicación de forma segura: deben establecer al
menos una asociación de seguridad para cada sentido de la comunicación. Al igual que
en AH, éstas pueden ser renovada a lo largo de la conexión.

El coste computacional del cifrado y descifrado de cada paquete IP es mayor que en el

caso de la cabecera AH, y en determinados sistemas esto puede acarrear problemas de
rendimiento.

TEMA 5 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

La cabecera ESP tiene el siguiente formato (Ilustración 4):

Security Parameter Index

Sequence Number Field

Encrypted Data and Parameters

Authentication Data

Ilustración 4: Cabecera ESP.

» Security Parameter Index (SPI): Representa a un número pseudoaleatorio de

32 bits que identifica a una determinada asociación de seguridad. El índice SPI, con
la dirección destino IP y el protocolo de seguridad (ESP), identifican unívocamente a
la asociación de seguridad para este datagrama.
» Sequence Number: Previene frente a posibles ataques de reenvío.

» Encrypted Data and Parameters: Contiene un campo vector de inicialización,

y la información cifrada de los protocolos superiores.

» Authentication Data: Valor que permite la comprobación de la autneticación y la

integridad del paquete ESP. Este control incluye el ESP tráiler, ESP payload y la
cabecera ESP, pero no tiene en cuenta la cabecera IP ni el propio campo
Authentication Data.

En la estructura del paquete mostrada en la Ilustración 3, el SPI y el sequence number

van en la cabecera ESP, el ESP tráiler contiene el padding, la longitud del mismo y el
siguiente protocolo del paquete y, por último, van colocados los datos de autenticación
de ESP. El ESP payload y el ESP tráiler van cifrados y la autenticación, a parte de estas
dos partes, también incluye la Cabecera ESP.

Por ser el más completo y al mismo tiempo el más seguro, la implementación del
protocolo ESP se ha desplegado de forma masiva, al punto de que ha desbancado en su
uso al protocolo AH.

TEMA 5 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Protocolos ISAKMP e IKE

El protocolo ISAKMP (Internet Security Association and Key Management Protocol)

fue propuesto por el IETF y describe un marco seguro de negociación para el
desarrollo de protocolos de seguridad. Una de sus motivaciones es la de afianzar la
utilización de las asociaciones de seguridad en el contexto de la arquitectura IPSec,
permitiendo la gestión y el establecimiento de las asociaciones de seguridad. Por así
decir, el protocolo ISAKMP define procedimientos y formatos de los paquetes para
establecer, negociar, modificar y eliminar estas asociaciones de seguridad. Proporciona
una alternativa al intercambio manual de claves.

Una implementación concreta de ISAKMP es el protocolo IKE (Internet Key

Exchange) y tiene como objetivo la negociación y gestión de los parámetros
específicos de seguridad. En la actualidad, IKE ha tenido tales dimensiones de
implantación que ha relevado en el nombre al protocolo original (ISAKMP). La IETF
recientemente ha presentado una versión mejorada, IKEv2, descrita en los RFC4306 y
RFC4307.

Para la creación de un canal seguro IPSec, el protocolo IKE debe tener lugar en primer
término como elemento de acuerdo y negociación previo entre extremos del canal
seguro IPSec. Tras esto, ambos extremos dispondrán de todos los elementos de
seguridad necesarios para el establecimiento del canal seguro. Cuando se establece el
canal seguro, el flujo de información a través de Internet queda debidamente protegido.

IKE es un protocolo en dos fases:

IKE Fase 1:

En esta fase los dos extremos establecen una clave de sesión (clave de sesión IKE, SA
ISAKMP), a partir del acuerdo de un secreto maestro y, se autentican mutuamente. Los
detalles de esta comunicación pueden verse en la Ilustración 5 y se describen a
continuación:

TEMA 5 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Ilustración 5: IKE Fase 1.

» Negociación de parámetros IKE propuesta-selección. En este paso,

correspondiente a los dos primeros mensajes de la figura anterior, queda acordada
una asociación de seguridad (SA ISAKMP) que regirá en esta fase.

» Intercambio de material clave (o criptográfico) mediante algoritmos de acuerdo

de clave Diffie-Hellman. Se corresponde con los mensajes tres y cuatro de la figura
anterior.

» Derivación de claves de sesión IKE a partir del secreto maestro obtenido del
material criptográfico anterior. Paso llevado a cabo tras la recepción de los mensajes
tres y cuatro en cada extremo respectivamente y antes de empezar la autenticación
del mensaje quinto y sexto.

» Mutua autenticación de los extremos. Este proceso de autenticación queda

protegido mediante el cifrado con la Clave de Sesión IKE. Mensajes quinto y sexto de
la figura anterior.

En esta fase 1 de IKE pueden darse dos modos de funcionamiento, el modo principal
(Main), representado en la figura anterior, que exige la identificación protegida de
ambas partes y por tanto resulta más seguro, o puede configurarse en modo agresivo
(Aggressive) que obvia este paso, no siendo su uso recomendado en escenarios críticos.
En el modo agresivo se intercambian solamente tres mensajes, los dos primeros que
van en claro (el segundo contiene, entre otros datos, el HASH_R que sirve para
autenticar al destinatario) y el tercero que ya va protegido y que sirve para autenticar al
remitente. Debido a que el HAS_R va en claro, dicho hash puede ser analizado y por
ello este modo es considerado menos seguro que el modo principal.

TEMA 5 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

IKE Fase 2:

En esta fase se establece una nueva negociación de asociaciones de seguridad

mediante propuesta-selección (asociación de seguridad IPSec), que se realiza con
plenas garantías una vez que la fase 1 ha culminado y, por tanto, una clave de sesión
protege esta comunicación. Los detalles de esta comunicación pueden verse en la
Ilustración 6 y se describen a continuación:

Ilustración 6: IKE Fase 2.

» Propuesta-selección de los parámetros de seguridad.

» Intercambio de material criptográfico para la derivación de la nueva clave.

» Periódicamente, se produce la renegociación de las asociaciones de seguridad IPSec.

En la fase 2 no se produce la autenticación de las partes, ya que fueron autenticadas en

la fase anterior, por lo que se suele decir que esta segunda fase se desarrolla en modo
rápido (Quick).

Una vez concluida esta fase, el canal seguro IPSec queda establecido y todo el tráfico de
datos entre los dos extremos de la comunicación se transmitirán de forma segura a
través de Internet.

Modos IPSec

IPsec puede ser usado para establecer un canal de comunicación seguro entre dos
gateways o entre dos hosts. En función de esto existen dos modos en IPSec: modo
túnel y modo transporte.

TEMA 5 – Ideas clave 11 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Modo túnel:

El termino túnel no es exclusivo de la tecnología IPSec, sino que además puede darse
en distintos niveles de la pila de protocolos e implementarse sobre mecanismos de
diversa naturaleza. Los túneles IPSec son túneles de capa red.

El modo túnel se utiliza cuando se quiere asegurar una zona de una red, y por tanto los
dispositivos que aseguran la comunicación no son los dispositivos finales que
envían/reciben datos.

Es el modo más extendido en la implementación de VPN. El modo túnel

consiste generalmente en encapsular el paquete IP con cabeceras IPSec. Un paquete
protegido con IPSec en modo túnel posee dos cabeceras IP, la cabecera interna, y la
cabecera externa. La interna es generada por la pila TCP/IP, mientras que la externa la
provee el dispositivo que implementa IPSec.

El modo túnel puede ser usado perfectamente por dispositivos finales (hosts)
pero no posee ninguna ventaja con respecto al modo transporte puesto que añade una
cabecera IP extra que sobrecarga el protocolo.

Modo transporte:

El modo transporte consiste en proteger la cabecera del nivel de transporte. Los

protocolos IPSec AH y ESP interceptan los paquetes que fluyen desde el nivel de
transporte al nivel de red para proveer las propiedades de seguridad.

El flujo original de un paquete IP cuando IPSec no está funcionando es que el paquete

TCP o UDP pase de la capa de transporte a la capa de red, donde se le añade la cabecera
IP, para posteriormente ser enviado a la capa de enlace. Cuando se utiliza IPSec, se
produce una fase intermedia en el que se le añaden las cabeceras AH y/o ESP.

El modo transporte es utilizado cuando se quieren asegurar las comunicaciones

extremo a extremo.

TEMA 5 – Ideas clave 12 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

En la Ilustración 7 podemos ver algunos ejemplos de diferentes combinaciones posibles

de modos y protocolos.

Original IP TCP Datos

IP IP
Modo Túnel con AH AH TCP Datos
pública privada

IP IP
Modo Túnel con ESP ESP TCP Datos ESP
pública privada

IP
Modo Transporte con AH AH TCP Datos
pública

IP
Modo Transporte con ESP ESP TCP Datos ESP
pública

Ilustración 7: Diferentes combinaciones de modos y protocolos.

5.4. SSL/TLS

Secure Socket Layer (SSL) fue desarrollado por Netscape. La versión 1.0 no llegó a
ser publicada y la versión 2.0 que fue publicada en 1995 contenía demasiados agujeros
de seguridad lo que la llevó a ser rápidamente sustituida en 1996 por la versión 3.0.
Más tarde, la Internet Engineering Task Force (IETF) formó un grupo de trabajo con el
fin de estandarizar el protocolo.

En 1999, el grupo de trabajo del IETF introdujo algunas mejoras en SSLv3 dando lugar
a la primera versión del protocolo Transport Layer Security (TLS) que podría
considerarse la versión 3.1 de SSL.

Arquitectura SSL

SSL proporciona autenticación, integridad y confidencialidad de la información

entre los extremos de una comunicación a través de mecanismos criptográficos.

TEMA 5 – Ideas clave 13 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Habitualmente solo el servidor es autenticado, y mediante esta autenticación se

establece un canal confidencial, mientras que el cliente se mantiene sin autenticar. SSL
también proporciona autenticaciones mutuas, pero estas opciones de autenticación
suelen darse en ambientes más pequeños o aplicaciones con pocos usuarios, porque a
gran escala se requeriría del funcionamiento de una PKI en ambientes tan amplios
como Internet. Aunque menos común, también se pueden usar algoritmos
criptográficos anónimos, permitiendo que el servidor no sea autenticado. Sin embargo,
estos algoritmos suelen estar deshabilitados y en muchas implementaciones del
protocolo no están ni incluidos.

Se detallan, a continuación, las principales fases de SSL.

» Autenticación del servidor: Se lleva a cabo al inicio del protocolo por medio del
envío de la clave pública del servidor, en el certificado X.509 que se envía al
establecer la conexión, junto con su firma digital. El certificado del servidor debe ser
validado por los usuarios. Generalmente los sitios web que utilizan SSL tienen sus
certificados firmados por autoridades certificadoras válidas.

» Confidencialidad e integridad de los datos: Una vez que el usuario ha recibido

la clave pública del servidor la usará para enviar de forma segura el material
criptográfico necesario para poder generar la clave de sesión.

» La autenticación del usuario: Consiste en una firma digital generada por el

usuario haciendo uso de la clave privada y del envío de su clave pública por medio de
un certificado X.509. Esto es opcional, y requiere que el servidor web pueda validar
este certificado. Esta opción es útil en sistemas donde la cantidad de usuarios a
autenticar por sitio es pequeña. No se utiliza en aplicaciones como correo seguro,
comercio electrónico, etc. ya que su dominio de usuarios es muy amplio.

TEMA 5 – Ideas clave 14 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Existen también en SSL un par de conceptos importantes descritos en la especificación

del protocolo: sesión y conexión.

» Sesión: Creadas por el protocolo handshake entre cliente y servidor. Definen los
parámetros criptográficos de seguridad para múltiples conexiones, lo que permite
evitar la renegociación de los parámetros en cada conexión. Cada sesión tiene
asociado un identificador de sesión, un certificado de la entidad par
(certificado X.509, opcional), un método de compresión, una especificación
del cifrado (cifrador simétrico, algoritmo de hash para el cálculo del MAC
(Message Authenticaction Code) y tamaño de la clave), clave maestra (48 bits
compartidos por cliente y servidor) y si la sesión es reanudable (se puede usar para
futuras conexiones).

» Conexión: Transporte que ofrece algún servicio y que está asociado a una sesión.
Una conexión tiene asociado valores aleatorios compartidos por cliente y
servidor, clave secreta para MAC de escritura del servidor, clave secreta para MAC
de escritura del cliente, clave de escritura del servidor, clave de escritura del cliente,
un vector de inicialización y los números de secuencia de los mensajes
enviados/recibidos.

SSL es un protocolo de dos niveles (Ilustración 8) que se sustenta en el protocolo TCP.

SSL está ubicado entre la capa de transporte y la capa de aplicación, de esta
forma, protocolos de servicio como HTTP, FTP, POP3, IMAP, entre otros, puedan hacer
uso de SSL para proporcionar seguridad a sus transacciones.

La primera capa de SSL, SSL Record Protocol, se usa para encapsular los protocolos
de nivel superior, tanto los propios de SSL como los de la capa de aplicación superior.
La segunda capa está compuesta por los protocolos de SSL. El protocolo Handshake
consta de los mensajes necesarios para establecer una comunicación SSL, la
autenticación del servidor, del cliente, y la negociación de las herramientas
criptográficas, algoritmos y claves de cifrado, etc. El protocolo Change Cipher Spec
sirve para indicar al otro extremo de la conexión que se está listo para empezar a
utilizar el material generado durando la ejecución del protocolo handshake. El
protocolo Alert nos permite enviar mensajes de alerta al otro extremo.

TEMA 5 – Ideas clave 15 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

SSL Handshake SSL Change Clipher

SSL Alert Protocol
Protocol Spec Protocol

SSL Record Protocol

Ilustración 8: Capas de SSL.

SSL Record Protocol

Este protocolo proporciona dos servicios a la conexión SSL: confidencialidad, a

partir del protocolo Handshake que genera una clave secreta compartida, la cual es
usada para cifrar los datos; e integridad y autenticación del mensaje, a partir
también de una clave generada en el Handshake para generar un MAC.

Este protocolo toma un mensaje de la aplicación que se va a transmitir, lo fragmenta en

bloques manejables, opcionalmente los comprime, les añade un MAC y realiza el
cifrado, al que añade una cabecera, y transmite la unidad resultante en un segmento
TCP; tal como se describe en la Ilustración 9.

Ilustración 9: SSL Record Protocol.

TEMA 5 – Ideas clave 16 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

SSL Handshake Protocol

Este es el protocolo que permite la autenticación de servidor y cliente, negocia el

algoritmo de cifrado, calcula las claves para MAC y las claves simétricas que se
utilizarán para proteger los datos que envía luego el SSL Record.

Consiste en una serie de mensajes intercambiados entre servidor y cliente. Cada

mensaje tiene tres campos: tipo, longitud y contenido; que se describen a continuación:

» Tipos: Indica uno de los 10 tipos de mensajes posibles:

o Hello-request.
o Client-hello.
o Server-hello.
o Certificate.
o Server_key_exchange.
o Certificate_request.
o Server_done.
o Certificate_verify.
o Client_key_exchange.
o Finished.
» Longitud: Especifica la longitud del mensaje en bytes.
» Contenido: Contiene los parámetros asociados con el mensaje.

El intercambio de mensajes está dividido en cuatro fases (Ilustración 10) y sus

correspondientes mensajes (los mensajes marcados con * son opcionales):

TEMA 5 – Ideas clave 17 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Ilustración 10: SSL Handshake Protocol.

Primera fase:

Inicio de la conexión y establecimiento de las capacidades de cada extremo

(combinaciones de algoritmos permitidos por cada uno). Los mensajes empleados son
los siguientes:

» ClientHello
o Versión del protocolo.
o Número aleatorio: Número generado por el cliente que consiste en un sello de
tiempo. Se utiliza en el intercambio de claves para prevenir ataques de repetición.
o Identificador de sesión.
o Lista de algoritmos de cifrado: Contiene esta lista contiene los algoritmos de
cifrado que soporta el cliente.
o Lista de algoritmos de compresión: Contiene esta lista contiene los algoritmos de
compresión que soporta el cliente.

TEMA 5 – Ideas clave 18 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

» ServerHello
o Versión del protocolo.
o Número aleatorio: Elegido por el servidor para el intercambio de mensajes
(distinto al del cliente).
o Identificador de sesión.
o Conjunto de algoritmos de cifrado: Elegidos por el servidor de la lista que soporta
el cliente.
o Algoritmos de compresión: Los elegidos por el servidor de la lista que soporta el
cliente.

Segunda fase:

En esta fase se lleva a cabo la autenticación del servidor y el intercambio de

clave. Los mensajes empleados son los siguientes:

» Certificate: Certificado x.509 del servidor junto con la cadena de certificados al

cliente. No se usa si se trabaja en SSL en forma anónima.

» ServerKeyExchange: Solo si es necesario para el intercambio de claves.

» CertificateRequest: Se envía si el servidor requiere autenticación del cliente.

» ServerHelloDone: Indica el final del mensajes ServerHello y los mensajes

relacionados.

TEMA 5 – Ideas clave 19 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Tercera fase:

En esta fase se lleva a cabo la autenticación del cliente y el intercambio de

clave. Los mensajes empleados son los siguientes:

Certificate: Si el servidor solicitó el certificado debe enviar un certificado en caso

de poseerlo, de lo contrario el servidor negará la conexión o establecerá las políticas
que tenga asociadas a este caso.

ClientKeyExchange: El cliente envía cifrado el secreto premaestro con la clave

pública del servidor. Es la semilla utilizada para generar el secreto maestro que a su
vez será usado para generar el material de claves de la sesión.

La generación del secreto maestro a partir del secreto premaestro y, posteriormente la

generación del material de claves de la sesión a partir del secreto maestro tienen un
esquema similar. En la Ilustración 11 se muestra la generación del material de claves a
partir del secreto maestro.

Ilustración 11: Generación de claves.

TEMA 5 – Ideas clave 20 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Para la generación del secreto maestro a partir del secreto premaestro, simplemente se
realizan los pasos ‘A’, ‘BB’ y ‘CCC’. Sin embargo, para generar el material de claves a
partir del secreto maestro generado, se van a realizar las iteraciones necesarias en
función de los algoritmos criptográficos que van a ser utilizados para la autenticación y
el cifrado.

El cliente y el servidor generan todo el material de clave, pero cada uno utiliza una
parte específica del mismo; tal y como puede verse en la Ilustración 12.

Ilustración 12: Material de clave.

» CertificateVerify: Enviado por el cliente si el servidor ha solicitado su

autenticación.

Cuarta fase:

En esta fase finaliza la negociación de parámetros entre cliente y servidor. Los

mensajes empleados son los siguientes:

» ChangeCipherSpec: El cliente pasa a utilizar los algoritmos y claves negociados:

los algoritmos aceptados por el servidor en el mensaje ServerHello y las claves
calculadas a partir del secreto premaestro.

» Finished: El cliente ha terminado la fase de negociación. Es el primer mensaje

cifrado e incluye, entre otros, un resumen del secreto maestro, los mensajes
anteriores y una constante. El servidor puede verificar que descifra los mensajes
correctamente.

» ChangeCipherSpec: El servidor pasa a utilizar los algoritmos y claves

negociados.

» Finished: El servidor ha terminado la fase de negociación. Envía un mensaje

cifrado.

TEMA 5 – Ideas clave 21 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

SSL Change Cipher Spec Protocol

Indica que el cliente pasa a utilizar los algoritmos y claves negociados.

Algoritmos aceptados por el servidor en el mensaje ServerHello, y claves calculadas a
partir del secreto premaestro.

Alert Protocol

Este protocolo gestiona la sesión SSL y los mensajes de error y advertencias

(warning, critical y fatal). Algunos ejemplos de este tipo de mensajes son:

» Unexpected message.
» Bad record MAC.
» Decompression failure.
» Bad certifícate.
» Certificate revoked.
» Certificate expired.
» Etc…

Cambios introducidos en TLS

Transport Layer Security (TLS) fue el nombre dado por el IETF cuando estandarizo el
protocolo SSL. Actualmente se han sacado tres versiones del mismo: 1.0 (RFC2246), 1.1
(RFC4346) y 1.2 (RFC5246). Además, desde julio de 2016 se está trabajando en el draft
de la versión 1.3.

TEMA 5 – Ideas clave 22 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Las principales diferencias entre la última versión de SSL (la 3.0) y la primera versión
de TLS (la 1.0) son:

» No existe compatibilidad entre ambas versiones.

» El número de versión intercambiada se continúa, es decir, la versión TLS 1.0 se
corresponde con la versión 3,1.
» Se han actualizado los mensajes de alerta a las nuevas características del protocolo.
Por ejemplo, se añade un mensaje para informar que el proceso de descifrado ha
fallado. Una lista completa de todos los mensajes de alerta de cada versión puede ser
encontrada en la RFC de cada una de ellas.
» Para la autenticación se pasa a usar el algoritmo H-MAC definido en la RFC 2014.
En este caso, no están predefinidos los algoritmos hash que vamos a usar, sino que
será negociado entre cliente y servidor.
» La forma en la que se genera el material de clave cambia, se introduce el concepto de
pseudorandom function (PRF). En TLS 1.0 y TLS 1.1 la PRF se basa en el uso de
SHA-1 y MD5 para construir el master secret y posteriormente el material de clave.
Sin embargo, debido a las debilidades encontradas en ambos algoritmos, en la
versión 1.2 pasa a ser uno de los parámetros negociados.

Aunque el esquema cambia con el visto para SSL, la idea se mantiene. Para la
generación del master secret se usan los valores aleatorios de cliente y servidor, el
pre master secret y un texto estático. Con ese master secret se genera el material de
clave. Concretamente se puede expresar como:

master_secret = PRF(pre_master_secret, "master secret",

ClientHello.random || ServerHello.random)
key_material = PRF(master_secret, "key expansion",
SecurityParameters.server_random || SecurityParameters.client_random)
(repetido hasta obtener material de clave necesario).

» Los datos utilizados en el mensaje CertificateVerify y en el mensaje Finished se han

modificado para simplificar su cálculo.

TEMA 5 – Ideas clave 23 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Datagrama TLS (DTLS)

DTLS es una extensión del protocolo TLS que provee los mismos servicios de seguridad
(integridad, autentificación y confidencialidad) pero sobre UDP. El éxito de aplicación
que tuvo TLS llevó a generar DTLS para su uso en comunicaciones no orientadas a
conexión. DTLS se caracteriza por:

» Negociación de claves sin conexión:

o Realizado sobre la misma conexión UDP.

o Se necesita implementar los controles que ofrece TCP.

» Establecimiento de una sesión fiable, control de retransmisiones.

» Confidencialidad y control de integridad.
» Contempla las limitaciones del tamaño de los mensajes.

Por otro lado, las principales diferencias de DTLS con TLS son:

» Los registros no se fragmentan.

» Control de retransmisiones, tiempo (16 bits) y secuencia (48bits), además DTLS
contiene una ventana de anti repetición.
» Modos de cifrado, no es viable la utilización de RC4 y propone el empleo de CBC
con vector de iniciación explícito.
» Timeout y retransmisiones, cada nodo mantiene un reloj desde la última
retransmisión, depende del RTT que está establecido por defecto entre 500 y 1000
ms.
» Empleo de cookies para evitar ataques de denegación de servicio (DoS).

TEMA 5 – Ideas clave 24 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

5.5. Redes privadas virtuales (VPN)

Las Redes Privadas Virtuales (VPN) son una extensión de la red local sobre una
red pública o no controlada como es el caso de Internet.

Uno de los ejemplos más conocidos de VPN es el de conectar dos o más sucursales
de una empresa, utilizando Internet como vínculo de unión, y permitir a los
trabajadores o miembros, la conexión desde su casa al centro de trabajo y el acceso a
recursos de la empresa como si estuviera dentro de la red local de la organización.

Para que el establecimiento de una VPN sea seguro es necesario proporcionar los
siguientes servicios de seguridad: autenticación y control de acceso del usuario,
es decir, saber quién es el usuario que accede a los recursos y qué nivel de acceso debe
tener; integridad y autenticación de los datos, es decir, garantizar que los datos
enviados/recibidos provienen de una fuente confiable y no han sido modificados;
confidencialidad de la información, ya que se realizara una conexión a través de
un medio poco seguro, los datos son susceptibles de ser interceptados por terceros, por
lo que el cifrado de datos es muy recomendable; y no repudio, es decir, que los
mensajes deben de ir firmados digitalmente, para que no se pueda negar la autoría de
dichos mensajes.

Una descripción de los principales tipos de VPNs puede encontrarse en la siguiente

imagen.

Los principales tipos de VPNs son:

VPN host-to-gateway VPN Gateway to Gateway VPN interna o VLAN

Consiste en que el usuario

Esta variante emplea la
se conecta a una red Se utiliza para conectar
propia red de área local, se
privada remota y accede a oficinas remotas con la
utiliza para aislar zonas y
sus recursos como un sede central.
servicios de la red interna.
usuario de la red local.

Normalmente las VPNs se crean haciendo uso del protocolo IPsec pero también pueden
usarse otros protocolos como PPTP, L2F, L2TP, SSL/TLS, SSH… para establecer
el túnel.

TEMA 5 – Ideas clave 25 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Lo + recomendado

Lecciones magistrales

Protocolos de seguridad

En esta lección veremos los protocolos de seguridad en Internet, unos protocolos cada
vez más habituales dada la constante necesidad de seguridad.

La clase magistral está disponible en el aula virtual.

TEMA 5 – Lo + recomendado 26 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

No dejes de ver…

Understanding IPSec

Se trata de una presentación en la

que se realiza una introducción al
protocolo IPSec y se explica la
arquitectura de los paquetes, así
como el funcionamiento del mismo
tanto en modo transporte como en
modo túnel.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

http://www.youtube.com/watch?v=NZAQKjLnPqE

What is HTTPS?

Este vídeo describe el funcionamiento

del protocolo SSL y explica el
intercambio de mensajes que se
produce entre el navegador y el
servidor para establecer un canal de
comunicación seguro.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

http://www.youtube.com/watch?v=JCvPnwpWVUQ

TEMA 5 – Lo + recomendado 27 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

VPN –Virtual Private Networking

Este vídeo realiza una introducción a

la motivación del uso de las redes
privadas virtuales y explica cómo
funcionan, así como sus principales
características.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

http://www.youtube.com/watch?v=q4P4BjjXghQ

TEMA 5 – Lo + recomendado 28 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

+ Información

A fondo

Anatomy and Performance of SSL Processing

En este artículo se realiza un análisis sobre el rendimiento de SSL en las transacciones

web seguras.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://www.cs.ucr.edu/~bhuyan/papers/ssl.pdf

IPSec: Performance Analysis and Enhancements

En este artículo se realiza un análisis sobre el rendimiento de IPSec en servidores VPN

en un entorno con varios clientes.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

https://web.cs.wpi.edu/~cshue/research/icc07.pdf

TEMA 5 – + Información 29 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Webgrafía

IPSec Maintenance and Extensions Charters

Web que contiene los últimos RFCs y borradores de internet sobre IPSec.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://datatracker.ietf.org/wg/ipsecme/charter/

OpenSSL

Web del proyecto OpenSSL que desarrolla software de SSL y TLS de código abierto.
Contiene documentación del proyecto y enlaces a páginas relacionadas con SSL.

Accede a la página desde el aula virtual o a través de la siguiente dirección web:

http://www.openssl.org/

TEMA 5 – + Información 30 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Actividades

Trabajo: Protocolos IPSEC y SSL/TLS

Desarrollo y pautas de la actividad

La empresa Example te contacta de nuevo. Están llevando a cabo pruebas con un

proveedor de comunicaciones para mejorar su seguridad a través del uso de protocolos
de comunicaciones seguras. Sin embargo, antes de implantarlo quieren saber tu
opinión al respecto. Te piden que analices las soluciones que le ha propuesto el
proveedor para ver si satisfacen sus necesidades de seguridad.

Por un lado, están llevando a cabo pruebas con IPSEC. Barajan la posibilidad de
interconectar dos de sus sedes de forma segura utilizando este protocolo y te facilitan
una captura de la propuesta del proveedor para su estudio.

Por otro lado, están llevando a cabo pruebas con SSL/TLS. Barajan la posibilidad de
mejorar la seguridad de su servidor WEB utilizando este protocolo y también te
facilitan una captura de la propuesta del proveedor para su estudio.

En ambos casos, debes analizar los paquetes contenidos en los ficheros pcap e
identificar los datos solicitados en las tablas que te facilitan.

Recuerda que el responsable de seguridad de Example es muy quisquilloso y solo

aceptará la información si se la entregas en un único fichero PDF que incluya las tablas
con la información solicitada, enviado a través de la plataforma autorizada y dentro del
plazo establecido.

Notas:

» Para visualizar los ficheros pcap puedes usar el software wireshark

(https://www.wireshark.org/) al que puedes acceder a través del escritorio virtual o
que puedes instalar en tu máquina.

TEMA 5 – Actividades 31 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Acción Regla

1. Puerto usado por el protocolo IKE

2. Modo de funcionamiento empleado

en la fase 1 de IKE
3. Algoritmo de cifrado propuesto en
la fase 1 de IKE por quien inicia la
comunicación
4. Algoritmo de Hash propuesto en la
fase 1 de IKE por quien inicia la
comunicación
5. Método de autenticación propuesto
en la fase 1 de IKE por quien inicia la
comunicación
6. Longitud de la clave propuesta en
la fase 1 de IKE por quien inicia la
comunicación
7. Valor del hash que ha sido
calculado haciendo uso de la clave
precompartida por ambos extremos
(En hexadecimal)
8. Protocolo de IPSEC que ha sido
acordado por los extremos en la fase
2 de IKE para ser usado
9. ESP SPI de quien inicia la
comunicación
10. ESP SPI del destino de la
comunicación
Tabla 1. IPSEC

TEMA 5 – Actividades 32 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Acción Regla

1. Dirección IP del cliente

2. Dirección IP del servidor

3. Versión de SSL-TLS usada

4. Puerto usado por el cliente en la

comunicación
5. Puerto usado por el servidor en la
comunicación
6. Opción de cifrado seleccionada
por el servidor
7. Fecha de caducidad del
certificado del servidor
(dd/mm/yyyy)
8. Longitud de la clave pública
usada por el servidor en Diffie-
Hellman
9. Longitud de la clave pública
usada por el cliente en Diffie-
Hellman
10. Longitud del primer mensaje
TLS, con datos de la capa de
aplicación, enviado por el cliente
11. Longitud del primer mensaje TLS,
con datos de la capa de aplicación,
enviado por el servidor
Tabla 2. SSL-TLS.

TEMA 5 – Actividades 33 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en Redes

Test

1. El uso de la arquitectura IPSEC:

A. Siempre asegura la confidencialidad de los datos.
B. Asegura la disponibilidad de los datos.
C. Las respuestas A y B son correctas.
D. Ninguna de las anteriores.

2. La cabecera de autenticación (AH):

A. Solo puede ser empleada cuando los equipos que intervienen en la
comunicación implementan IPv6.
B. Proporciona los tres principales servicios de seguridad (confidencialidad,
integridad y disponibilidad).
C. Proporciona los tres principales servicios de seguridad (autenticación,
disponibilidad e integridad).
D. Ninguna de las anteriores.

3. El protocolo ESP:
A. Puede proporcionar autenticación e integridad.
B. Proporciona solo confidencialidad extremo a extremo.
C. Las respuestas A y B son correctas.
D. Ninguna de las anteriores.

4. El protocolo IKE:
A. Posee dos fases que están completamente cifradas para la negociación de
parámetros de seguridad.
B. Todos los mensajes de la segunda fase están cifrados.
C. Las respuestas A y B son correctas.
D. Ninguna de las anteriores.

TEMA 5 – Test © Universidad Internacional de La Rioja (UNIR)

34
 Seguridad en Redes

5. El protocolo IKE:
A. Durante la fase 1 se establecen los parámetros de protección del protocolo
ESP.
B. Durante la fase 1 se establecen los parámetros de protección del protocolo AH.
C. Durante la fase 1 se establecen los parámetros de protección de la siguiente
fase IKE.
D. Ninguna de las anteriores.

6. La negociación de claves de la fase 2 del protocolo IKE:

A. Puede ser realizada sin necesidad de la fase 1.
B. Puede no ser necesaria una vez completada la fase 1.
C. Las respuestas A y B son correctas.
D. Ninguna de las anteriores.

7. El protocolo SSL:
A. Proporciona autenticación e integridad.
B. Proporciona solo confidencialidad punto a punto.
C. Proporciona solo confidencialidad extremo a extremo.
D. Ninguna de las anteriores.

8. El protocolo SSL:
A. El secreto premaestro se compone de información que ha sido generada parte
en el cliente y parte en el servidor.
B. El secreto premaestro es generado por el cliente.
C. El secreto premaestro es generado por el servidor.
D. Ninguna de las anteriores.

9. En el protocolo handshake de SSL:

A. Puede llevarse a cabo sin completar la fase de autenticación y el intercambio
de claves.
B. Puede llevarse a cabo sin que el servidor posea un certificado de clave pública
que pueda ser verificado.
C. Cada uno de los extremos genera las claves que le permitirán alcanzar el
servicio de no repudio.
D. Ninguna de las anteriores.

TEMA 5 – Test © Universidad Internacional de La Rioja (UNIR)

35
 Seguridad en Redes

10. Los mensajes de Change cipher Spec de SSL:

A. Se emplean para enviar la clave de sesión generada en el protocolo handshake
al otro extremo.
B. Son mensajes opcionales.
C. Las respuestas A y B son correctas.
D. Ninguna de las anteriores.

TEMA 5 – Test © Universidad Internacional de La Rioja (UNIR)

36