NAVEGACIN SEGURA EN INTERNET CON SSL/TLS Y HTTPS

Octubre 2012
Objetivo: Familiarizarse con la operacin de los protocolos SSL/TLS y HTTPS, utilizados para establecer una sesin segura entre
cliente y servidor, protegiendo la confidencialidad, integridad y autenticidad de los datos de los usuarios que navegan en redes pblicas
como Internet.
Requisitos: Conocimientos bsicos de TCP/IP, HTTP y criptografa.
Plataforma: Windows/Linux.

Seccin A: Introduccin a SSL/TLS

Es un hecho bien conocido que Internet constituye un medio de comunicacin poco seguro, debido a que la informacin que circula a
travs de esta vasta red de redes potencialmente puede ser interceptada en puntos intermedios, utilizando por ejemplo sniffers. De esta
forma un fisgn podra espiar los datos o incluso alterar su contenido, vulnerando entonces la confidencialidad, autenticidad o la
integridad de la informacin. Una analoga para ilustrar esta situacin es la tarjeta postal, que puede ser leida por los empleados de la
oficina de correos, por los vecinos o por la familia, por lo que no debera usarse para enviar informacin privada. Ahora bien, qu se
hace cuando se necesita comunicar algo privado? Pues se utiliza un sobre cerrado. En el caso de redes pblicas como Internet, la
solucin ms comnmente adoptada es el sobre digital, utilizando un protocolo de comunicacin seguro como SSL/TLS.
SSL (Secure Sockets Layer) fue diseado y propuesto en 1994 por Netscape Communications Corporation para su primera versin
del Navigator. Sin embargo, no fue hasta su tercera versin, conocida como SSL v3.0, que alcanz la madurez, superando los
problemas de seguridad y limitaciones de sus predecesores, proporcionando cifrado, integridad y autenticidad de los datos y,
opcionalmente, autenticacin del cliente y del servidor. Por su lado Microsoft en esa misma poca introdujo un protocolo similar
denominado PCT (Personal Communication Technology). Posteriormente, considerando que no era conveniente tener protocolos
similares con el mismo propsito, pero incompatibles, la IETF desarroll TLS (Transport Layer Security), cuya versin 1.0 fue
publicada en enero de 1999 en RFC2246. La principal diferencia es que TLS incluye ciertos algoritmos de cifrado y mejores
mecanismos de seguridad con respecto a TLS. Hoy da se habla indistintamente de SSL y TLS, aunque SSL se qued en la versin 3.0,
mientras que TLS sigui evolucionando y actualmente va por la versin 1.2, publicada en agosto de 2008 en RFC5246. La versin 1.1
fue publicada en abril de 2006 en RFC4346.
Lamentablemente muchos servidores Web y navegadores Web, por razones de compatibilidad, estn configurados para utilizar las
versiones antiguas, las cuales son vulnerables a ciertos de ataques, como BEAST (Browser Exploit Against SSL/TLS). Navegadores
como Safari, Chrome y Firefox todava no ofrecan soporte para TLS 1.1 o 1.2 a principios de 2012. En cambio, Internet Explorer 9
soporta todas las versiones, como se puede comprobar yendo a Herramientas | Opciones de Internet | Opciones avanzadas.

SSL/TLS opera estableciendo un tnel VPN, esto es un canal de comunicacin seguro a travs de una red insegura como Internet. Una
VPN (Virtual Private Network) es esencialmente una forma de comunicacin que usa recursos de transmisin y conmutacin
compartidos, es decir pblicos (lo que usualmente implica inseguros). Este video le puede orientar un poco ms sobre VPN.

-2-

Conceptualmente, un tnel de comunicaciones significa encapsular los paquetes que llevan un cierto protocolo (por ejemplo HTTP)
dentro de paquetes de otro protocolo (por ejemplo SSL/TLS, PPTP o IPSec). Mediante el encapsulamiento se aade un nuevo
encabezado al paquete original, y los datos adems se encriptan y se autentican. El encapsulamiento se efecta a la entrada de tnel y
el nuevo paquete viaja a travs de la red de trnsito hasta alcanzar el final del tnel, donde se remueve el encabezado, se desencriptan
los datos y reaparece el paquete original. El tnel es la ruta de informacin lgica a travs de la cual viajan los paquetes encapsulados.
Para los interlocutores de origen y de destino originales, el tnel suele ser transparente.
El rasgo que distingue a SSL de otros protocolos para tneles seguros como PPTP o IPSec es que se ubica en el modelo OSI entre
los niveles de transporte (TCP/IP) y de aplicacin, suministrando un canal seguro a nivel de socket (conector), de all su nombre. En
cambio, IPSec (IP Security) opera sobre la capa 3 de red y es usado en VPN por su escalabilidad y robustez, sobre todo para tneles
VPN permanentes entre sitios, ms que para usuarios remotos, ya que por lo general no funciona bien si el usuario est detrs de un
NAT.
La ubicacin precisa de SSL/TLS en el modelo OSI es un poco ms compleja, ya que se compone de 4 subprotocolos ( SSL
Handshake Protocol, SSL Change Cipher Spec Protocol, SSL Alert Protocol, SSL Record Layer), como se muestra en la figura. Los
detalles se pueden consultar en el anexo al final de esta gua. Si usted quiere profundizar, en Internet consigue bastante informacin,
por ejemplo en Wikipedia y en Technet de Microsoft. Tambin hay interesantes video-tutoriales.

Hoy da es bastante comn el uso de VPN basada en SSL/TLS en contraposicin a IPSec, ya que es ms fcil la configuracin y la
operacin; de hecho con SSL/TLS no hace falta instalar ningn cliente VPN (es clientless): basta con el navegador de Internet.
Adems, por funcionar sobre la capa de transporte, SSL/TLS no altera el sistema operativo, actuando como un proceso de usuario
(user process) y no como un proceso de sistema (system process). SSL fue creado por Netscape principalmente para permitir
transacciones comerciales seguras sobre la Web, por lo que el protocolo que ms lo usa es HTTP, sin embargo SSL/TLS est diseado
para ser independiente de la capa de aplicacin y ser muy flexible, por lo que tambin es usado para hacer seguros otros protocolos de
este nivel, como FTP para transferencia de archivos, SMTP para correo electrnico, Telnet para conexin a mquinas remotas, etc.
Normalmente se utilizan los siguientes puertos:

-3Protocolo
HTTP
SMTP
POP3
TELNET
FTP
NNTP
LDAP

Puerto TCP
80
25
110
23
20-21
119
389

Protocolo
HTTPS
SSMTP
SPOP3
TELNETS
FTPS
NNTPS
SSL-LDAP

Puerto TCP
443
465
995
992
989-990
563
646

Como ejemplo, Gmail permite utilizar un cliente de correo como Outlook o Mozilla Thunderbird para enviar y recibir emails
encriptados, configurando la cuenta tal como se muestran en la figura. Los detalles se explican en la prctica sobre Correo electrnico
seguro.

SSL/TLS proporciona sus servicios de seguridad utilizando criptografa asimtrica (de clave pblica) para autenticar los 2 extremos y
para establecer una clave de sesin, la cual luego es usada para cifrar y descifrar los datos utilizando criptografa simtrica con
algoritmos rpidos, eficientes y confiables como RC2, RC4, DES, 3DES, AES. Se genera una clave de sesin distinta para cada
transaccin, lo cual significa que aunque esa clave sea descubierta por un atacante en una transaccin dada, no servir para descifrar
futuras transacciones. Esa clave de sesin es generada por el cliente y enviada al servidor cifrndola con clave pblica del servidor, la
cual a su vez se extrae del certificado digital del servidor. Usualmente se utiliza para tal fin el sistema de clave pblica RSA (RivestShamir-Adleman). Otra forma de generar la clave de sesin es mediante el algoritmo DH (Diffie-Hellman) en vez de RSA. En la
prctica Criptografa de clave pblica se estudian los detalles de estas tcnicas.

Para proteger la integridad y la autenticidad de los datos en el paquete enviado, se genera un resumen de esos datos mediante una
funcin hash, utilizando MD5 (Message Digest 5) o SHA (Secure Hash Algorithm). Este resumen equivale a una huella digital de
los datos y al cifrarse con la clave privada RSA del remitente, se convierte en firma digital, la cual se enva junto a los datos. As
garantiza no solo su integridad y autenticidad, sino tambin el no repudio. Otro sistema de firma digital es DSS (Digital Signature
Standard), desarrollado por la Agencia de Seguridad Nacional norteamericana (NSA). En la prctica Firma digital se estudian los
detalles de estas tcnicas.

-4-

Con SSL/TLS tambin se puede utilizar el hash criptogrfico conocido como HMAC (Hashed Message Autenthication Code), donde
se usa un algoritmo el cual, a partir del mensaje y una clave secreta compartida, produce una huella digital que no puede ser alterada
sin que se detecte. Las funciones HMAC son similares a las funciones hash, con la diferencia que utilizan adicionalmente una clave
secreta. De esta manera se evita el ataque de un hombre en el medio (MITM) que intercepte el mensaje, lo modifique, recalcule el hash
y enve todo al destinatario. El receptor, que posee la clave compartida, puede recalcular el HMAC sobre el mensaje recibido y
verificar si el valor as obtenido coincide con el valor del HMAC recibido. En SSL/TLS el HMAC se calcula concatenando los datos
con un nmero de secuencia y un nmero secreto pre-establecido compartido por el cliente y el servidor. Sin embargo, a diferencia de
la firma digital, el HMAC no garantiza el no repudio (por qu?).

El uso ms comn de SSL/TLS es para asegurar el trfico HTTP y se le conoce como HTTPS (Hypertext Transfer Protocol Secure).
La conexin por lo general se hace al puerto 443 del servidor, en vez del puerto 80. Histricamente, HTTPS se empez a utilizar en la
banca en lnea y luego se extendi al comercio electrnico y las compras por Internet: Los nmeros de tarjeta de crdito y otros datos
de los usuarios pueden espiarse fcilmente en conexiones inseguras. Hoy da HTTPS se usa cada vez ms en multiplicidad de
aplicaciones Web como el correo electrnico (Gmail, Hotmail, Yahoo) y redes sociales (Facebook, Twitter). HTTPS tambin se utiliza
para la gestin remota de equipos tales como routers y firewalls, donde est instalado en el firmware del equipo un servidor Web
liviano y un certificado digital autofirmado.

Una de las desventajas de HTTPS es la velocidad, ya que la comunicacin se hace un poco ms lenta por el proceso de
encriptacin/desencriptacin y el chequeo de integridad/autenticidad de los datos. Para evitar este retardo, algunos sitios utilizan
normalmente HTTP y pasan a HTTPS slo cuando se envan datos privados. Tal es por ejemplo el caso de Facebook y Amazon.
Tngase que en cuenta que los datos transmitidos mediante HTTPS viajan encriptados en su trayecto, sin embargo, al llegar a
destino, los mismos puede ser visualizados en su formato habitual, por ejemplo HTML. En consecuencia, si el servidor pertenece a un
atacante, el mismo podr tener acceso a la informacin enviada y hacer uso de ella de acuerdo a sus fines. Con frecuencia, los usuarios
creen que el slo hecho de que un sitio Web cuente con HTTPS, determina que ste sea seguro, legtimo y, por ende, digno de
confianza, sin chequear la validez del certificado digital. Este descuido puede significar la entrega de datos confidenciales a
ciberdelincuentes. En este sentido, es fundamental desterrar el mito del carcter indiscutiblemente seguro de un sitio Web que opera
bajo HTTPS.

-5En el caso del comercio electrnico, si bien HTTPS ofrece un canal seguro para el envo de los datos de la tarjeta de crdito,
carece de capacidad para completar el proceso financiero completo: verificar la validez de la tarjeta, autorizar la transaccin con el
banco del cliente y procesar el resto de la operacin con el banco adquiriente y emisor. Todo esto lo hace SET (Secure Electronic
Transaction) el cual, debido a su complejidad, no ha tenido xito y no se usa. Adems es importante recalcar que HTTPS slo
garantiza la confidencialidad, autenticidad e integridad de los datos durante la transaccin, ni antes ni despus. Por lo tanto, si se
envan datos personales al servidor, por ejemplo el nmero de tarjeta de crdito, la cdula de identidad, etc., HTTPS solamente asegura
que mientras viajan desde el cliente hasta el servidor no podrn ser ni espiados ni modificados. Lo que el servidor haga con ellos, est
ya ms all de la competencia de este protocolo. Los datos podran ser manipulados irresponsablemente o caer en manos de un
atacante que asaltara el servidor con xito. As que lo que debera ser su fuente de preocupacin, cuando usted enva datos por la red,
no es slo el protocolo que est usando para enviar dichos datos al sitio remoto, sino lo que se hace con ellos una vez recibidos. Es
quizs ms probable que alguien le robe los datos de su tarjeta de crdito si la ha extraviado o si est mirando por encima de su
hombro cuando est conectado tecleando dicha informacin, que el que sea interceptada en Inter net, incluso si est utilizando una
conexin insegura. Sin embargo, una vez que los datos llegan a su destino, usualmente se almacenan en una base de datos, por lo que
la seguridad de sta es extremadamente importante. De hecho es muy posible que un ciberdelincuente vaya a por el pastel completo
(penetrar en una base de datos que contenga miles de nmeros de tarjetas de crdito) que a por un simple trozo.
En todo caso si bien SSL/TLS no es una solucin ideal desde el punto de vista del pago electrnico, esto no significa que no se
deba utilizar ni que no sea til en otras muchas facetas igualmente necesarias de las transacciones electrnicas. Al proporcionar un
canal seguro de comunicaciones, el comerciante puede ofrecer al cliente de manera confidencial una serie de servicios para estrechar
las relaciones de confianza: autenticacin del cliente frente al comercio, trato personalizado, evitar que terceras partes espen las
compras de los clientes, intercambio de informacin privada, etc.
SSL/TLS es un protocolo de seguridad en tiempo real, donde el cliente y el servidor negocian interactivamente la forma de
autenticarse y establecer los parmetros de seguridad de la sesin. En tal sentido y previamente al establecimiento de la sesin
encriptada, hay un intercambio de mensajes (handshake), descritos a continuacin de manera muy resumida. Los detalles se pueden
consultar en el anexo al final de esta gua y en Technet de Microsoft. El handshake dura una fraccin de segundos y es transparente
para el usuario.

La fase de saludo (Hello) sirve para ponerse de acuerdo sobre el conjunto de algoritmos a utilizar para la confidencialidad y la
autenticacin. El cliente inicia la conexin enviando un mensaje ClientHello al servidor en el cual proporciona una lista de los
algoritmos de cifrado, autenticacin y compresin que puede manejar. Esta lista se conoce como cipher suite y est ordenada de
acuerdo al nivel de seguridad. El servidor responde con un mensaje de saludo ServerHello en el que informa cules algoritmos
seleccion. El servidor elige un conjunto u otro de algoritmos y con una cierta longitud de claves en funcin de las posibilidades
criptogrficas del cliente. Normalmente selecciona los ms robustos que puedan manejar ambas partes. La posibilidad de elegir entre
tan amplia variedad de algoritmos dota a SSL/TLS de una gran flexibilidad criptogrfica.
Luego de la fase de saludo, se pasa a la fase de autenticacin para as verificar quien es cada quien. Con este fin el servidor enva al
cliente sus credenciales de autenticacin, esto es el certificado digital que contiene su clave pblica. El tipo de certificado debe ser el
apropiado para el algoritmo de clave pblica acordado entre el cliente y el servidor (RSA, Diffie-Hellman, DSS). Normalmente es del
tipo X.509 y basado en una infraestructura de clave pblica (PKI). Por su parte el cliente (por lo general un navegador como Internet
Explorer o Firefox) verifica que el certificado sea vlido, que haya sido emitido por una entidad certificadora de confianza (ej.
Verisign), que no haya caducado y que corresponda a ese servidor. Si el certificado no es de confianza (por ejemplo es autofirmado) el
navegador le preguntar al usuario si desea confiar en el certificado, debiendo este ltimo aceptar o rechazar el certificado.
Uno de los riesgos que existe en esta fase, es que el usuario se haya conectado a un sitio falso y que la pantalla sea una simple
fachada para capturar sus datos personales (phishing). Con el fin de reducir este riesgo, los certificados que cumplen con el nuevo

-6formato EV-SSL permiten mostrar de forma mucho ms clara que la pgina es autntica, ya que en el navegador la barra de
direcciones o parte de ella es de un color verde.

Luego de enviar su certificado, el servidor solicita al cliente que le enve su certificado digital. Por lo general resulta algo complicado
obtener e instalar un certificado digital vlido del lado del cliente, por lo que el usuario usualmente se autentica de otra manera (ej.
contrasea o PIN).
Al superar exitosamente la fase anterior de autenticacin, se pasa a la fase de creacin de la clave de sesin, la cual consiste en un
nmero aleatorio generado por el cliente y enviado al servidor, de manera que ambos extremos la compartan. El cliente enva esa clave
cifrndola mediante el algoritmo RSA y usando la clave pblica del servidor (que extrajo de su certificado). Otra forma de generar la
clave de sesin es mediante el algoritmo Diffie-Hellman en vez de RSA.
En la fase final del handshaking, el cliente enva un extracto (hash) cuyos argumentos son la clave de sesin y todos los mensajes
anteriores intercambiados entre l y el servidor. El propsito de este mensaje es probar que el cliente conoce la clave de sesin y
verificar la integridad de los datos enviados.
El servidor con su clave privada descifra la clave de sesin. Al igual que lo hizo el cliente, el servidor enva un extracto cuyos
argumentos son la clave de sesin y todos los mensajes, anteriores intercambiados entre ambos. Este mensaje permite probar que el
servidor conoce la clave de sesin y verificar la integridad de los datos enviados.
Si todo sale bien finalmente se habr levantado de un tnel VPN, es decir de canal seguro sobre una red pblica y abierta como
puede ser Internet y entonces puede comenzar el intercambio de datos entre ambos extremos, encriptados mediante la clave de sesin y
haciendo uso del algoritmo de cifrado acordado previamente. Adems con la firma digital o con HMAC se protege la integridad y
autenticidad de los datos.

Seccin B: Establecimiento de una conexin SSL/TLS mediante HTTPS

A continuacin se va a realizar una serie de experiencias con conexiones SSL/TLS a sitios Web seguros (por ejemplo bancos). No se
necesita realizar ninguna accin especial para esto: basta con utilizar un URL que empiece por https://. El navegador se encarga del
resto. Al establecerse la sesin SSL/TLS luego del handshaking inicial, se puede asegurar la autenticidad, integridad y
confidencialidad de los datos intercambiados.
1. Para empezar las pruebas, conctese con un banco, por ejemplo el Banco Mercantil. All seleccione Mercantil en lnea Personas.
Debera ser reenviado a un servidor Web seguro en https://www30.bancomercantil.com.

2. Si usa Firefox, haga clic sobre el smbolo del sitio a la izquierda del URL. En la ventana que se abre, pulse Ms informacin.

-73. Observe la informacin de la Identidad del sitio Web. En Detalles tcnicos dice que la conexin est cifrada con RC4 y clave de 128
bits. Es seguro? En Europa los banco usan AES con clave de 256 bits.

4. Pulse Ver certificado y compruebe que el certificado est respaldado por una autoridad reconocida (ej. Digicert o Verisign). Bajo la
pestaa Detalles hay ms informacin. Viendo esa informacin, el usuario o visitante tendr algo ms de confianza de que no se trata
de un sitio falso para capturar sus datos personales (phishing).

-85. (Opcional). Si en vez de Firefox usa Internet Explorer, haga clic sobre el smbolo de candado a la derecha del URL. Pulse Ver
certificados y analice la informacin relativa al certificado digital. Internet Explorer no muestra que se usa una conexin cifrada RC4
con clave de 128 bits. Es til o importante conocer este dato para el usuario?

6. Adems del certificado digital, otro instrumento que utilizan algunos bancos para convencer al usuario tenga la certeza de que
realmente estn conectados con su banco, es mostrar una foto de algo familar, previamente seleccionada por el usuario cuando se
registr la primera vez.

Con la proliferacin de ciberdelicuentes, los bancos se han visto en la necesidad de implantar medidas avanzadas de seguridad para
proteger del robo de identidad a los usuarios que realizan transacciones en lnea. En muchos pases ya se est utilizando el token
criptogrfico, el cual se sincroniza con un servidor a la hora de ser activado por primera vez y genera una contrasea nica en un
perodo de tiempo (segundos es lo mas comn) a travs de un algoritmo secreto.

-97. Continuando con el estudio de entender cmo se establece una sesin segura con SSL/TLS, active un analizador de trfico (sniffer),
preferiblemente Wireshark, poniendo eventualmente un filtro para SSL o para el puerto TCP 443. Luego conctese al Banco Mercantil
en https://www30.bancomercantil.com (u otro sitio que utilice HTTPS) y capture el trfico.

8. Entre los numerosos paquetes, busque el mensaje ClientHello enviado por el navegador para iniciar una sesin con el servidor Web
y analice su contenido, que es la siguiente:
# de bytes
Tipo de mensaje = 1

Longitud del mensaje

Nmero de versin del protocolo

Nmero aleatorio (Rcliente)

32

Longitud del ID de sesin

ID de sesin

variable

Longitud de la lista de la suite de algoritmos

criptogrficos

Algoritmos criptogrficos

variable

Longitud de la lista de los mtodos de

compresin

Mtodos de compresin

variable

9. La descripcin detallada de los distintos campos se encuentra en el anexo al final de esta gua y en Technet de Microsoft.
Bsicamente con este mensaje el cliente le proporciona al servidor una lista (suite) de los algoritmos de cifrado, autenticacin y
compresin que puede manejar. Si en Wireshark expande el campo Cipher Suites ver una lista ordenada por prioridad, siendo
usualmente la primera en la lista, la suite ms segura. Se acostumbra utilizar un formato compacto para definir una suite especfica.
Por ejemplo: TLS_RSA_WITH_AES_256_CBC_SHA significa: Usar el protocolo TLS, usar certificados RSA para la identificacin y
el intercambio de claves, usar AES con clave de 256 bits y modo CBC para la encriptacin, usar SHA para el resumen del mensaje".

-10-

En los aos recientes ha ido aumentando la cantidad de algoritmos que soporta SSL/TLS, por ejemplo la encriptacin mediante
CAMELLIA y la criptografa de clave pblica basada en curvas elpticas, de manera que la sigla ECDHE significa Elliptic Curve
Diffie-Hellman Exchange y sigla ECDSA significa Elliptic Curve Digital Signature Algorithm. Aplicaciones como Gmail utilizan estas
nuevas suites para lograr ms seguridad mediante Perfect Forward Secrecy (PFS).
10. (Opcional). Si en vez de Firefox usted utiliza Internet Explorer, la lista de Cipher Suite es ms corta. Qu relevancia tiene eso?

11. (Opcional). Esa lista la extrae Internet Explorer directamente de Windows y para verla (o modificarla), en la lnea de comandos de
Windows ejecute gpedit.msc para as abrir el Editor de directivas de grupo local. Luego seleccione Configuracin de equipo |
Plantillas administrativas | Red | Opciones de configuracin SSL.

-11-

12. (Opcional). En el caso de Linux (Ubuntu), el comando openssl ciphers [cipherlist] permite visualizar o modificar la lista de
Cipher Suite que soporta ese sistema operativo.
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_IDEA_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
13. Continuando con el anlisis de la sesin SSL/TLS, en Wireshark busque el mensaje ServerHello que es la respuesta a ClientHello y
analice su estructura, que es la siguiente:

-12# de bytes
Tipo de mensaje = 2

Longitud del mensaje

Nmero de versin del protocolo

Nmero aleatorio (Rservidor)

32

Longitud del ID de sesin

ID de sesin

variable

Algoritmo criptogrfico seleccionado

Mtodo de compresin seleccionado

14. En particular, busque la Cipher Suite seleccionada por el servidor, en este caso TLS_RSA_WITH_RC4_128_SHA. Qu tan
segura es esta Cipher Suite? Por qu no se utiliza otra quizs ms segura?

15. Visite otros bancos venezolanos (ej. Provincial, Banesco, Banco de Venezuela, Venezolano de Crdito, Exterior), vea el certificado
digital y capture el trfico SSL. Busque los mensajes ServerHello y vea cul es la Cipher Suite seleccionada por el servidor.
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA

Qu tan seguro es AES-256 en comparacin con RC4-128? Tome en cuenta que el ataque BEAST (Browser Exploit Against
SSL/TLS) se aprovecha de una vulnerabilidad en el cifrado Cipher Block Chaining (CBC) utilizado con los algoritmos AES y TripleDES. Especialistas en seguridad han sugerido el uso RC4 para evitar dicha vulnerabilidad en SSL/TLS, ya que RC4 es un algoritmo de
cifrado de flujo y no utiliza el cifrado de bloque de encadenamiento (CBC).
16. Visite algunos bancos americanos (ej. Citibank, Bank of America, Chase, Wells Fargo) y europeos (ej. BBVA, Barclays, Lloyds,
UBS, BNL). Vea el certificado digital y capture el trfico SSL. Busque los mensajes ServerHello y vea cul es la Cipher Suite
seleccionada por el servidor. Cul es la ms utilizada en EE.UU? Cul es la ms utilizada en Europa?
17. Adems de los bancos, proveedores de correo como Gmail, Hotmail, Yahoo...) y redes sociales como Facebook y Twitter utilizan
HTTPS para encriptar todo el trfico. Vaya a algunos de esos sitios y vea el certificado digital.
18. El navegador da una advertencia de seguridad cuando hay algn problema con el certificado, por ejemplo, que haya sido firmado
por una autoridad de raz desconocida o que el nombre no coincida con el URL del sitio Web. Analice por ejemplo el caso de CADIVI
o SUSCERTE.

-13-

Seccin C: Encriptacin del trfico mediante SSL/TLS

En la seccin anterior se ha visto cmo se establece una sesin SSL/TLS mediante el handshaking inicial, luego de lo cual se puede
asegurar la autenticidad, integridad y confidencialidad de los datos intercambiados.
1. Para verificar que efectivamente los datos viajan encriptados, conctese a algunos de los sitios Web seguros en los cuales posea una
cuenta, por ejemplo Gmail, Hotmail, Yahoo, Facebook o Twitter. Active la captura mediante un sniffer con Wireshark y vea el
contenido de los paquetes TLSv1 Application Data. Se dar cuenta que estn encriptados, sin embargo se pueden distinguir claramente
el encabezado TCP y el encabezado IP.

2. Si en vez de SSL/TLS utilizara IPSec, tendra otro tipo de tnel VPN y no se podran distinguir ni siquiera esos encabezados. Sera
esa forma de comunicacin todava ms segura?

-14-

3. Si usted utiliza con Firefox un complemento como Live HTTP Headers, podr ver los encabezados de los mensajes entre el
navegador y el servidor, incluyendo las cookies y las credenciales de autenticacin, pero sin encriptacin. Para instalar Live HTTP
Headers, en la barra de mens de Firefox seleccione Complementos (Adds-on en ingls).

4. En el Administrador de complementos busque LiveHTTPheaders y, una vez encontrado en Internet, proceda a instalarlo.

Deber reiniciar Firefox para que la instalacin surta efecto.

Luego de lo cual, el complemento debera aparecer debajo de Herramientas.

-15-

5. Haga clic sobre Live HTTP headers y se mostrar la siguiente pantalla. Note que la casilla Capturar est marcada, lo cual indica que
a partir de este momento se mostrarn las cabeceras del trfico HTTP que cursa por Firefox.

6. Conctese a alguno de los sitios Web seguros en los cuales posea una cuenta, por ejemplo Gmail, Hotmail, Yahoo, Facebook o
Twitter. Cmbiese a la ventana Live HTTP headers y observe como aparecen numerosas peticiones y respuestas HTTP en tiempo real,
a medida que se va descargando la pgina Web. Cada peticin con su respectiva respuesta est separada de la siguiente mediante una
lnea horizontal. Slo se muestran los encabezados y los parmetros enviados mediante GET o POST, mas no el cuerpo completo del
mensaje (el cual suele ser muy largo).
7. Todava ms interesante puede resultarse conectarse a un banco y capturar las credenciales de autenticacin. Por ejemplo vaya a
Banco Provincial. Seleccione Provinet - Personas e introduzca un nmero de 19 dgitos (ej. 5895240106119158751) en campo
Nmero de Tarjeta y una clave de 6 dgitos (ej. 123456).

-168. (Opcional). Vaya a Banco Mercantil. Introduzca un nmero de 18 dgitos para la llave Mercantil (ej. 501878200008985836) y una
clave telefnica de 4 dgitos (ej. 1234). Cmbiese a la ventana Live HTTP headers y vea los mensajes intercambiados.
9. (Opcional). Vaya a Banesco. Seleccione BanescOnline e introduzca un nombre de usuario y una clave de 8 o ms caracteres.
Cmbiese a la ventana Live HTTP headers y vea los mensajes intercambiados.

Seccin D: Es SSL/TLS realmente seguro?

Herramientas como Cain y Ettercap permiten realizar mediante ARP spoofing, ataques del hombre en el medio (MITM) sobre
comunicaciones seguras basadas en SSL/TLS, reemplazando al vuelo el certificado digital de sitio Web con otro muy parecido, pero
falso, el cual se crea al interceptar el inicio de la sesin SSL. Los datos del certificado falso se rellenan con los datos del certificado
verdadero, excepto la firma digital, que por supuesto es distinta, tratando de engaar al usuario. El navegador alerta que algo anda mal
con el certificado digital, pero la mayora de los usuarios no saben nada de certificados digitales ni comprenden la importancia de la
alerta y simplemente la ignoran. Adems el hecho de que muchos sitios usen un certificado de raiz desconocida (ej. CADIVI), hace
que dichas alertas sean relativamente frecuentes y finalmente sean ignoradas. Al establecerse la sesin SSL, se crean 2 tneles SSL y el
trfico pasar por la mquina del atacante, donde es desencriptado y espiado para capturar datos confidenciales y contraseas, para
luego ser reencriptado y enviado a la mquina de destino, todo de forma trasparente para la vctima.

Para probar este tipo de ataque, efecte la prctica Ataques de falsificacin ARP mediante Cain o Ataques de falsificacin ARP
mediante Ettercap.
En Septiembre de 2011 corri como la plvora el descubrimiento y posterior demostracin, por parte de 2 investigadores, de una
vulnerabilidad en los protocolos de seguridad SSL 3.0 y TLS 1.0, lo cual permitira descifrar las comunicaciones con sitios de
comercio electrnico como PayPal. Dicha vulnerabilidad est reportada en la popular base de datos CVE como CVE-2011-3389.
BEAST (Browser Exploit Against SSL/TLS) es una herramienta para automatizar dicho ataque. Consiste en cdigo JavaScript que
funciona con un sniffer para descifrar las cookies que llevan las credenciales de los usuarios para acceder a sus cuentas. Se trata del
primer ataque sofisticado al protocolo SSL/TLS que termina con xito y bsicamente se traduce en que millones de pginas que
realizan transacciones bancarias y de pagos, quedaran expuestas.

-17-

El problema se debe a una vulnerabilidad en el cifrado Cipher Block Chaining (CBC) utilizado con los algoritmos AES y Triple-DES,
ya que los vectores de inicializacin (IVs) no son asignados al azar para cada bloque (los vectores se supone que aseguran que los
bloques idnticos no generan el mismo texto cifrado). Esto permite que las cookies que se transmite de forma cifrada se puedan
descubrir mucho ms rpido con "conjeturas" que con la fuerza bruta. Para tener xito, sin embargo, se debe utilizar un ataque Man-inthe-middle (MITM) con el fin de interceptar la conexin de la vctima servidor y comunicarse con el servidor en el contexto de la
vctima.
Especialistas en seguridad han sugerido el uso RC4 para evitar dicha vulnerabilidad en SSL/TLS, ya que RC4 es un algoritmo de
cifrado de flujo y no utiliza el cifrado de bloque de encadenamiento (CBC). Las implementaciones de CBC en todas las versiones
hasta SSL 3.0/TLS 1.0 son vulnerables a los ataques.
El problema puede ser resuelto por el cambio a la versin de TLS 1.1, que fue adoptada en 2006: en ella, los vectores de
inicializacin de CBC son aleatorios, lo que hace que el ataque descrito resulte ineficaz. Sin embargo, el cambio es potencialmente
problemtico porque no todos los servidores y navegadores son compatibles con el estndar. Slo Windows 7 y 2008 Server R2 puede
utilizar TLS 1.1. Opera 10, por el contrario, funciona incluso con TLS 1.2. Adems, no sirve de nada cambiar la configuracin del
navegador, si el servidor no es compatible con la norma.
En Diciembre de 2011 Microsoft public la actualizacin de seguridad MS12-006 que aparentemente resuelve el problema en
Windows, al modificar la forma en que el componente de canal seguro de Windows (SChannel) enva y recibe los paquetes de red
cifrados.
Ms informacin:
http://www.contextis.com/research/blog/beast/
http://www.phonefactor.com/blog/slaying-beast-mitigating-the-latest-ssltls-vulnerability.php
http://www.xombra.com/go_news.php?nota=5771
http://www.phonefactor.com/resources/CipherSuiteMitigationForBeast.pdf

Seccin E: Informe
Elabore un informe de no menos de 8 pginas donde se reportan las experiencias ms relevantes, se analizan los resultados obtenidos,
finalizando con conclusiones y eventuales recomendaciones.
El informe debe ser individual y redactado con palabras propias; no se permite repetir el texto del material que se encuentra en esta
gua, en Internet o en otras fuentes. Debe contener un resumen de las actividades realizadas, con ejemplo de resultados. Deben
analizarse y discutirse esos resultados, en particular si se presentaron problemas o aspectos inesperados. Tambin deben incluirse las
conclusiones y eventuales recomendaciones.
Los informes deben enviarse regularmente al profesor a lo largo del curso, mediante el correo electrnico. Sern penalizadas las
entregas retrasadas y no se aceptarn entregas muy retrasadas. Adems NO se aceptarn informes entregados todos juntos los ltimos
das de finalizacin del curso.

-18-

Descripcin detallada del protocolo SSL/TLS

El protocolo SSL (Secure Socket Layer) o Capa de Conector Seguro, fue diseado en 1994 por Netscape
Communications Corporation y es un protocolo que provee tres grados de proteccin:
Autenticacin

de las entidades (cliente y servidor) involucradas en la comunicacin, utilizando criptografa de clave

pblica, como RSA, Diffie-Hellman y DSS. El sistema de clave pblica tambin es usado para el intercambio de una
clave simtrica que permite:
Confidencialidad de la informacin a travs del uso de criptografa de clave secreta, como DES, Triple-DES, RC4, RC2,
AES.
Integridad de la informacin a travs del uso de cdigos de autenticacin de mensajes, como MD5 y SHA.
SSL es un protocolo de seguridad en tiempo real, por lo que los nodos involucrados negocian interactivamente para
autenticarse y establecer los parmetros de seguridad de la sesin. Este se ubica en el modelo de capas de Internet
entre el nivel de transporte y de aplicacin, suministrando un canal seguro de comunicacin a nivel de socket (conector),
de all su nombre. Fue desarrollado principalmente para permitir transacciones comerciales seguras sobre la Web, por lo
que el protocolo que ms lo usa es el HTTP, sin embargo SSL ha sido diseado para ser independiente de la capa de
aplicacin, por lo que tambin es usado para hacer seguros otros protocolos de este nivel, como FTP para transferencia
de archivos, SMTP para correo electrnico, Telnet para conexin a mquinas remotas, etc.

Figura 1. SSL opera sobre la capa de transporte para proveer seguridad

independientemente de la aplicacin

Por funcionar sobre la capa de transporte, SSL no altera el sistema operativo sino que es implementado en un proceso de
usuario (user process).
SSL requiere a TCP como protocolo de la capa de transporte, en vez de UDP. Este requisito fue impuesto para que la
estructura de este protocolo resultara ms simple, ya que no tiene que encargarse del control de flujo que TCP realiza (ni
del timing-out ni de la retransmisin de los datos perdidos).
Como se observa, cuando se usa SSL, la aplicacin interacta con ste en vez de con TCP. Por esta razn, cuando un
protocolo de la capa de aplicacin como HTTP, SMTP, POP3, etc., selecciona una conexin de socket segura, no utiliza
el puerto TCP que tradicionalmente tiene asignado.
Protocolo
https
smtp
pop3
telnet
ftp
nntp
ldap

Puerto TCP asignado

80
25
110
23
21
119
389

Protocolo protegido por SSL

https
Ssmtp
spop3
Telnets
Ftps
Nntps
ssl-ldap

Puerto TCP asignado

443
465
995
992
989 (Datos), 990 (Control)
563
646

Puertos TCP tradicionales y puertos TCP al usar SSL

-19Puertos diferentes les son adjudicados que le indican a la mquina destino que el protocolo por encima de TCP que
recibir los datos es SSL, el cual luego de procesarlos, se los entregar al protocolo correspondiente de la capa de
aplicacin.
Al usar SSL se establece una red privada virtual (VPN: Virtual Private Network) entre el servidor y el cliente. Como los
datos de la aplicacin viajan encriptadas, esto crea un tnel o canal de comunicacin seguro sobre redes pblicas,
abiertas, con recursos de transmisin y conmutacin compartidos. El tnel es equivalente a una red que transporta trfico
privado, pero sobre redes pblicas.
SSL fue originalmente implementado en el navegador Netscape. Luego que la versin 2 fue publicada, Microsoft mejor
algunos de sus problemas de seguridad e introdujo un protocolo similar denominado PCT (Private Communications
Technology). Luego Netscape mejor notablemente el protocolo desarrollando la versin 3, la cual es la ms usada hoy
en da. Tomando en cuenta que no era bueno para la industria tener tres protocolos similares y con el mismo propsito,
pero incompatibles, la IETF, acertadamente, desarroll un cuarto, tambin similar e incompatible, basado en la versin
tres de SSL, al que llam TLS (Transport Layer Security). La principal diferencia es que TLS incluye ciertos algoritmos de
cifrado que SSL no cubre.

Operacin bsica del protocolo

La idea bsica del protocolo es utilizar criptografa de clave pblica para autenticar los nodos y para establecer una clave
de sesin simtrica que luego es usada para cifrar y proteger la integridad de la informacin cursada entre ellos.
En SSL se llevan a cabo dos fases, una inicial denominada fase de handshake en la que se negocian los parmetros de
seguridad que regirn la sesin, se autentica el servidor y opcionalmente, se autentica el cliente. Una segunda fase que
es en la que se transmiten los datos de la aplicacin que est utilizando SSL, bajo los parmetros de seguridad que se
hayan negociado.
A continuacin se muestra una forma simplificada del protocolo, en la que se asume el uso de RSA como algoritmo de
clave pblica y autenticacin slo del servidor:

Figura 2. Forma simplificada del protocolo SSL

-201. El cliente inicia la conexin enviando un mensaje de saludo al servidor en el que proporciona una lista de los
algoritmos de cifrado, autenticacin y compresin que soporta.
2. El servidor enva un mensaje de saludo en el que responde con uno de los algoritmos de cifrado, autenticacin
y compresin que soporta, de los del grupo provisto por el cliente.
3. A continuacin el servidor enva al cliente su certificado con su clave pblica.
4. Luego el cliente verifica el certificado y de ser autentico, genera la clave de sesin, la cifra con la clave pblica
del servidor y se la enva.
5. Adicionalmente el cliente enva un extracto cuyos argumentos son la clave de sesin y todos los mensajes
anteriores intercambiados entre l y el servidor. El propsito de este mensaje es probar que el cliente conoce la
clave de sesin y garantizar la integridad de la informacin cursada entre l y el servidor.
6. El servidor con su clave privada descifra la clave de sesin. Ahora, tanto cliente como servidor disponen de una
clave secreta con la cual proteger criptogrficamente la comunicacin entre ambos.
7. Al igual que lo hizo el cliente, el servidor enva un extracto cuyos argumentos son la clave de sesin y todos los
mensajes, anteriores a ste, intercambiados entre ambos. Este mensaje permite probar que el servidor conoce
la clave de sesin y garantiza la integridad de la informacin cursada entre l y el cliente.
8. Finalmente comienza el intercambio de los datos protegidos criptogrficamente entre cliente y servidor. Los
datos son fragmentados, se les agrega un cdigo de autenticacin y se cifran, antes de transmitirse.

Estructura y Operacin detalladas del protocolo

Como se muestra en la figura, SSL est distribuido en dos capas que se establecen entre la capa de transporte y la de
aplicacin en el modelo TCP/IP.

Aplicacin
Capa de Mensajes

SSL

Capa de Registro
Transporte

La superior se denomina capa de mensajes y, como su nombre lo indica, contempla mensajes de tres protocolos, estos
son: el protocolo de Handshake, el protocolo de Alerta y el protocolo para Cambio de Especificaciones de Cifrado. Esta
capa tambin permite el paso directo hacia la capa de registro de mensajes con los datos de la aplicacin que usa SSL.

Aplicacin
Protocolo
de
Handshake

Protocolo
de
Alerta

Protocolo de
Cambio de
Especificaciones
de Cifrado

Datos
de la
Aplicacin

Protocolo de Registro
Transporte

La fase de handshake referida con anterioridad, es ejecutada por el protocolo del mismo nombre: Protocolo de
Handshake. Durante su ejecucin se negocian los algoritmos y claves de seguridad que regirn la sesin, se autentica el

-21servidor y opcionalmente, se autentica el cliente. El protocolo de Alerta se encarga de notificar y ejecutar acciones en
caso de alarmas y errores durante la sesin. El protocolo de Cambio de Especificaciones de Cifrado se encarga de
indicar cambios en los algoritmos de cifrados que el servidor y el cliente manejan.
La capa inferior, denominada de registro, contempla el protocolo del mismo nombre, el Protocolo de Registro. Este se
encarga de proveer un formato nico para toda la informacin proveniente de la capa de mensajes: mensajes de
handshake, mensajes de alerta, mensajes para cambio de especificaciones de cifrado o mensajes con datos de la
aplicacin. En esta capa los mensajes son acomodados en bloques que en algunos casos son protegidos
criptogrficamente.
El protocolo de Handshake
Como su nombre lo indica, es el encargado de la fase de handshake de SSL. Es usado para establecer, mantener y
finalizar las conexiones SSL, para negociar los parmetros de seguridad de una sesin, para autenticar el servidor y,
opcionalmente, para autenticar el cliente.
A continuacin se muestra el intercambio detallado de mensajes que se lleva a cabo en esta fase:

Cliente

Servidor

Saludo de cliente
Saludo de servidor
Certificado *
Intercambio de clave de servidor *
Solicitud de certificado *
Saludo de servidor completado
Certificado *
Intercambio de clave de cliente
Verificacin de certificado *
Cambio de especificacin de cifrado
Fin del handshake
Cambio de especificacin de cifrado
Fin del handshake
Datos de la aplicacin

Datos de la aplicacin

Figura 3. Intercambio de mensajes del protocolo de handshake

( * Indica mensajes opcionales)

-22-

Figura 4. Ilustracin del intercambio de mensajes del protocolo de handshake

1. El cliente inicia la conexin enviando un mensaje de saludo (Client Hello) en el que proporciona una lista de los
algoritmos de cifrado, autenticacin y compresin que soporta, as como un nmero aleatorio que ser usado
posteriormente en el clculo de la clave de sesin.
2. El servidor enva un mensaje de saludo (Server Hello) en el que responde con uno de los algoritmos de cifrado,
autenticacin y compresin que soporta, y que seleccion de la lista provista por el cliente. El conjunto de
algoritmos escogidos normalmente es el ms robusto. Adicionalmente, proporciona un nmero aleatorio que
tambin ser usado posteriormente en el clculo de la clave de sesin.

-233. Los tres mensajes que siguen: Certificado (Certificate), Intercambio de clave del servidor (Server Key Exhange)
y solicitud de certificado (Certificate Request), son opcionales y dependen de si el servidor y/o el cliente sern
autenticados, y del algoritmo de clave pblica que se haya acordado entre ellos.
- El servidor enviar un certificado digital si necesita ser autenticado por el cliente, lo cual
generalmente es el caso. El tipo de certificado debe ser el apropiado para el algoritmo de clave
pblica acordado por el cliente y el servidor (RSA, Diffie-Hellman, DSS). Usualmente es del tipo
X.509.v3, con una clave pblica que permitir el intercambio de informacin entre estos dos nodos,
en base a la cual establecer una clave de sesin.

- El servidor enviar un mensaje de Intercambio de Clave del Servidor, cuando el mensaje con su
certificado no contenga una clave pblica que le permita al cliente enviarle informacin cifrada para
el clculo de la clave de sesin. Este es el caso cuando el certificado del servidor es vlido solo
para firmar (certificado DSS o RSA solo para firmar).

- El servidor solicita un certificado al cliente si desea que este se autentique. Aunque SSL provee
esta opcin, es comn que el cliente no posea un certificado. Por esta razn y para evitar el uso de
la compleja criptografa de clave pblica en la autenticacin del cliente, muchas implementaciones
de SSL permiten que este enve su nombre y una contrasea encriptados con la clave de sesin,
una vez que esta ha sido establecida.
4. Luego el servidor enva un mensaje para indicarle al cliente que su saludo ha finalizado: Saludo de Servidor
Completado (Server Hello Done). Este ya ha remitido toda la informacin que deba enviar al cliente y se
encuentra en espera de sus respuestas.
5. A continuacin el cliente examina los mensajes del servidor, verifica el certificado del servidor y prepara las
respuestas apropiadas. Si el servidor le ha solicitado un certificado para poder autenticarlo, y si lo posee, se lo
enva (Certificate).
6. Luego el cliente ejecuta dos procesos. Por un lado, calcula la clave de sesin y por el otro, enva un mensaje de
Intercambio de Clave (Client Key Exchange) con informacin para que el servidor pueda establecer la clave de
sesin. La forma en que calcule la clave de sesin y la informacin que enve al servidor depender del
algoritmo de clave pblica que se haya acordado entre ambos.

- En el caso de usar RSA, el cliente genera otro nmero aleatorio, S, llamado secreto pre-maestro, a
partir del cual calcula, junto con Rcliente y Rservidor, lo que se denomina el secreto maestro de la
sesin, N:
N = f (S, Rcliente, Rservidor)
A partir de N, y usando una vez ms a Rcliente y Rservidor, calcula la clave de sesin, K:
K = f (N, Rcliente, Rservidor)
En realidad se calculan dos claves de sesin, una para cifrar y otra para calcular los cdigos MAC
para garantizar integridad.
Adicionalmente, el cliente cifra el secreto pre-maestro S con la clave pblica del servidor y se lo
enva.

- En el caso de usar Diffie-Hellman, el cliente determina una clave secreta con los parmetros del
servidor (obtenidos del certificado o del mensaje de Intercambio de clave del servidor): nmero
pblico o clave pblica TS del servidor, el mdulo p y el generador g, y la funcin exponencial
discreta que caracteriza al algoritmo Diffie-Hellman:
Clave secreta = (TS )C mod p,
donde c es un nmero aleatorio generado por el cliente.
Esta clave es usada como el secreto pre-maestro S, a partir del cual se calcula el secreto maestro
N y las claves de sesin:
N = f (S, Rcliente, Rservidor)

K = f (N, Rcliente, Rservidor)

-24La informacin que enva el cliente para que el servidor determine las claves de sesin es su
nmero pblico Tc (nmero pblico o clave pblica del cliente). El servidor usar este parmetro
para calcular dicha claves de la misma forma que lo hizo el cliente.
7. Opcionalmente, el cliente puede enviar un mensaje de Verificacin de Certificado (Certificate Verify). Como su
nombre lo indica, su propsito es comprobar explcitamente el certificado del cliente. El cliente prepara una
firma digital de todos los mensajes de handshake que hasta ahora han intercambiado el y el servidor, excepto el
de Saludo de Cliente. La comprobacin de esta firma por parte del servidor, le permite autenticar al cliente, as
como corroborar la integridad de la informacin cursada entre ambos.
8. El cliente enva un mensaje de Cambio de Especificacin de Cifrado (Change Cipher Spec) para notificarle al
servidor que los registros o records sucesivos que enve estarn protegidos de acuerdo a las claves y
algoritmos recin negociados.
9. El cliente concluye su participacin en la fase de handshake con un mensaje de fin (Handshake finished), el
cual contiene un extracto o resumen de todos los mensajes anteriores a ste, intercambiados entre cliente y
servidor, y la clave de sesin para integridad que comparten; por tal razn permite verificar la integridad de la
informacin cursada entre ambos, as como comprobar que el intercambio de la clave fue exitoso.
10.El servidor, por su parte, descifra la informacin recibida del cliente y procede a calcular la clave de sesin. La
forma en que realice este clculo depende del algoritmo de clave pblica que hayan acordado:

- En el caso de usar RSA, descifra el secreto pre-maestro, a partir del cual calcula, junto con Rcliente y
Rservidor, el secreto maestro de la sesin, N:
N = f (S, Rcliente, Rservidor)
A partir de N, y usando una vez ms a Rcliente y Rservidor, calcula la clave de sesin, K:
K = f (N, Rcliente, Rservidor)

- En el caso de usar Diffie-Hellman, el servidor toma el nmero pblico del cliente Tc y determina la
clave secreta, mediante la funcin exponencial discreta que caracteriza a Diffie-Hellman:
Clave secreta = (Tc )A mod p,
donde A es un nmero aleatorio generado por el servidor para determinar su nmero pblico.
Esta clave es usada como el secreto pre-maestro S, a partir del cual se calcula el secreto maestro
N y las claves de sesin:
N = f (S, Rcliente, Rservidor)

K = f (N, Rcliente, Rservidor)

11. Luego de este clculo, el servidor enva un mensaje de cambio de especificacin de cifrado para notificarle al
cliente que los registros sucesivos que enve estarn protegidos de acuerdo a las claves y algoritmos recin
negociados.
12.Al igual que lo hizo el cliente, el servidor concluye su participacin en la fase de handshake con un mensaje de
fin (Handshake finished), el cual contiene un extracto cuyos argumentos son la clave de sesin para integridad y
todos los mensajes, anteriores a ste, intercambiados entre ambos. Este mensaje permite probar que el
intercambio de la clave fue exitoso y garantiza la integridad de la informacin cursada entre l y el cliente.
13.Finalmente comienza el intercambio entre ambos de los datos, protegidos criptogrficamente.
Reanudacin de sesin
Como ya se ha visto, en SSL la autenticacin de los nodos que se comunican y el establecimiento de una clave maestra
entre ellos requieren del uso de criptografa de clave pblica (asimtrica). Los algoritmos de clave pblica tienen el
inconveniente de ser computacionalmente intensivos y resultan algo lentos, reduciendo el desempeo de los nodos; por

-25esta razn existen casos en los que en el handshake inicial entre el cliente y el servidor, el servidor permite la
reanudacin de sesiones, esto con la finalidad de que en la eventualidad de sesiones posteriores entre ellos, no
necesiten realizar un proceso de handshake completo, obvindose especficamente la parte de ste en la que se utiliza la
criptografa de clave pblica.
Si el servidor va a permitir la reanudacin de sesiones con un cliente, ste le enva un identificador de sesin en su
mensaje de saludo, y a su vez, almacena en memoria dicho identificador.
Cuando el cliente y el servidor deciden reanudar una sesin previa, el intercambio de mensajes que se lleva a cabo es el
siguiente:
Cliente

Servidor

Saludo de cliente
Saludo de servidor
Cambio de especificacin de cifrado
Fin del handshake
Cambio de especificacin de cifrado
Fin del handshake
Datos de la aplicacin

Datos de la aplicacin

Figura 5. Intercambio de mensajes del protocolo de handshake para reanudacin de sesin

1. El cliente le enva un saludo al servidor en el que incluye el identificador de la sesin que se desea reanudar.

-262. El servidor busca el identificador de sesin en su cach y si consigue una coincidencia, enviar un mensaje de
saludo con dicho identificador indicando que efectivamente desea reanudar la sesin.
3. Tanto cliente como servidor proceden a enviar mensajes de cambio de especificacin de cifrado y de fin de
handshake.
4. Una vez reestablecida la sesin, el cliente y el servidor pueden comenzar a intercambiar datos de la capa de
aplicacin.
Es de hacer notar que si en el punto 2 el servidor no consigue en su cach el identificador de sesin, ste generar uno
diferente (o lo establecer en cero), obligando a que se efecte una fase de handshake completa.
Mensajes del protocolo Handshake
A continuacin se explica de forma ms detallada la estructura de cada uno de los mensajes del protocolo de handshake.
Saludo del cliente (ClientHello)
Mensaje enviado por el cliente para iniciar una sesin con el servidor. Su estructura es la siguiente:
# de bytes
Tipo de mensaje = 1

Longitud del mensaje

Nmero de versin del protocolo

Nmero aleatorio (Rcliente)

32

Longitud del ID de sesin

ID de sesin

variable

Longitud de la lista de la suite de algoritmos

criptogrficos

Algoritmos criptogrficos

variable

Longitud de la lista de los mtodos de

compresin

Mtodos de compresin

variable

Figura 6. Mensaje de ClientHello

Tipo: Nmero que identifica el tipo de mensaje de handshake.
Longitud del mensaje: Debido a que este mensaje posee campos

de longitud variable, se necesita este

valor para especificar su tamao.
Nmero de versin del protocolo: Especifica la versin del protocolo que se usar durante la sesin. Este
campo fue incorporado para compatibilidad con versiones anteriores.
Nmero aleatorio generado por el cliente (Rcliente): Uno de los nmeros usados para generar las claves de
sesin. Est conformado por 32 bytes distribuidos de la siguiente forma: 28 bytes obtenidos de un
generador de nmeros aleatorios; y 4 bytes que constituyen la hora y la fecha de la estacin cliente al
momento de generar este mensaje, representadas en formato UNIX (segundos transcurridos desde Enero
1 de 1970). Este ltimo elemento se incluy con el objeto de evitar que en algn momento coincidieran los
nmeros aleatorios generados por la estacin cliente y el servidor.
Identificador (ID) de sesin: Valor opcional que al ser incluido identifica una sesin previa cuyos parmetros
de seguridad desea reutilizar el cliente. Este campo es usado para reanudacin de sesin.
Longitud del identificador (ID) de sesin: Campo que indica el tamao del identificador de sesin.
Longitud de la lista de la suite de algoritmos criptogrficos: Longitud de lista en la que se especifica el
conjunto de algoritmos criptogrficos que el cliente soporta.
Algoritmos criptogrficos: Secuencia que especifica el conjunto de algoritmos que el cliente soporta,
ordenados segn su preferencia.
Longitud de la lista de los mtodos de compresin: Longitud de lista en la que se especifica el conjunto de
mtodos de compresin que el cliente soporta.

-27de compresin: Lista que contiene los mtodos de compresin que el cliente soporta. A pesar de
que esta opcin est disponible en SSL, normalmente los datos no se comprimen, por lo que este campo
tiene el valor de cero.

Mtodos

Saludo del servidor (ServerHello)

Mensaje de respuesta del servidor a un saludo del cliente (ClientHello). Su estructura se muestra a continuacin:
# de bytes
Tipo de mensaje = 2

Longitud del mensaje

Nmero de versin del protocolo

Nmero aleatorio (Rservidor)

32

Longitud del ID de sesin

ID de sesin

variable

Algoritmo criptogrfico seleccionado

Mtodo de compresin seleccionado

Figura 7. Mensaje de ServerHello

Slo se incluyen los campos de este mensaje que no son auto-explicativos o hayan sido revisados con anterioridad:
Nmero

aleatorio generado por el servidor (Rservidor): Uno de los nmeros usados para generar las claves de
sesin. Esta conformado por 32 bytes distribuidos de la siguiente forma: 28 bytes obtenidos de un
generador de nmeros aleatorios; y 4 bytes que constituyen la hora y la fecha del servidor al momento de
generar este mensaje, representadas en formato UNIX (segundos transcurridos desde Enero 1 de 1970).
Este ltimo elemento se incluy con el objeto de evitar que en algn momento coincidieran los nmeros
aleatorios generados por la estacin cliente y el servidor.
Identificador (ID) de sesin: Valor opcional que al ser incluido por el servidor identifica una sesin cuyos
parmetros de seguridad sern reutilizados con el cliente. Este campo es usado para reanudacin de
sesin.
Algoritmo de criptogrfico: Grupo de algoritmos seleccionados de la lista suministrada por el cliente y que el
servidor soporta.
Mtodo de compresin: Algoritmo de compresin seleccionado por el servidor de la lista suministrada por el
cliente y que el servidor soporta. Normalmente esta opcin no se usa, por lo que este campo tiene el valor
de cero.
Certificado (Certificate)
Mensaje usado por el servidor para enviar su certificado digital, si va autenticarse ante el cliente, lo cual generalmente es
el caso. Este se enva luego del mensaje de saludo del servidor (ServerHello). El tipo de certificado debe ser el apropiado
para el algoritmo de clave pblica acordado por el cliente y el servidor (RSA, Diffie-Hellman, DSS) y generalmente es del
tipo X.509.v3. El certificado normalmente contiene una clave pblica que permitir el intercambio de informacin entre el
cliente y el servidor, en base a la cual establecer la clave de sesin.
Este mismo mensaje tambin es usado por el cliente en respuesta a una solicitud de certificado realizada por el servidor
cuando desea que el cliente se autentique.
La estructura de este mensaje es la siguiente:

# de bytes
Tipo de mensaje = 11

Longitud del mensaje

-28-

Certificados
adicionales

Longitud del certificado

Certificado

Variable

Longitud del certificado de la primera

autoridad certificadora
Certificado de la primera
autoridad certificadora
Longitud del certificado de la segunda
autoridad certificadora
Certificado de la segunda
autoridad certificadora

3
Variable
3
Variable

Longitud del certificado de la ltima

autoridad certificadora
Certificado de la ltima
autoridad certificadora

3
Variable

Figura 8. Mensaje de Certificate

Certificado

y certificados adicionales: Secuencia de certificados comenzando con el certificado del emisor

del mensaje en primer lugar y, opcionalmente, seguido por el certificado de autoridades certificadoras.

Intercambio de clave del servidor (ServerKeyExchange)

Este mensaje es enviado por el servidor cuando ste no posee un certificado y esta usando el protocolo Diffie-Hellman
para el intercambio de clave simtrica junto con un certificado vlido slo para firmar digitalmente (por ejemplo, un
certificado DSS o RSA solo para firmar), o una clave temporal RSA, para el intercambio de clave simtrica junto con un
certificado vlido slo para firmar digitalmente. Su objetivo entonces es permitir establecer una clave del servidor que
permita el intercambio cifrado de informacin entre el y el cliente. La estructura del mensaje vara dependiendo del
algoritmo de clave pblica que se este utilizando. La estructura general del mensaje es la siguiente:
# de bytes
Tipo de mensaje = 12

Longitud del mensaje

Parmetros del
Algoritmo de
Clave Pblica

Longitud de la firma

Firma

variable

Figura 9. Mensaje de ServerKeyExchange

Si el algoritmo a usar es el RSA, la estructura del mensaje es la siguiente:

# de bytes
Tipo de mensaje = 12

Longitud del mensaje

Longitud del mdulo

Mdulo

variable

-29Longitud del exponente

Exponente

variable

Longitud de la firma

Firma

variable

Figura 10. Mensaje de ServerKeyExchange

Los parmetros que se incluyen en el mensaje en este caso son la clave pblica del servidor, o exponente e y el mdulo
m, de la funcin exponencial discreta que define la encriptacin en el algoritmo RSA:
C = Me mod m
Texto cifrado

Texto en claro

Una vez que el mensaje es recibido por el cliente, el usar esta funcin, el mdulo y la clave pblica del servidor para
cifrar un nmero aleatorio, llamado secreto pre-maestro, que permitir el posterior establecimiento de la clave de sesin
entre ambos.
Secreto pre-maestro cifrado = (Secreto pre-maestro)e mod m
Si el algoritmo a usar es el Diffie-Hellman, la estructura del mensaje es la siguiente:
# de bytes
Tipo de mensaje = 12

Longitud del mensaje

Longitud del mdulo

mdulo

variable

Longitud del generador

Generador

variable

Longitud del nmero pblico del servidor

Nmero pblico del servidor

variable

Longitud de la firma

Firma

variable

Figura 11. Mensaje de ServerKeyExchange

Los parmetros que se incluyen en el mensaje en este caso son el nmero pblico o clave pblica T S del servidor, el
mdulo p y el generador g, con los cuales el cliente determina una clave secreta mediante la funcin exponencial
discreta que caracteriza al algoritmo Diffie-Hellman:
Clave secreta = (TS)C mod p,
donde c es un nmero aleatorio generado por el cliente.
La clave secreta ser usada como el secreto pre-maestro, que permitir el posterior establecimiento de las claves de
sesin entre cliente y el servidor.
Para garantizar integridad de los parmetros transferidos en cada caso, estos son firmados digitalmente por el servidor
con su clave privada DSS o RSA. El resultado de la firma se incluye en el mensaje.
Solicitud de Certificado (CertificateRequest)

-30Mensaje mediante el cual el servidor solicita un certificado al cliente para autenticarlo. Para brindar flexibilidad la solicitud
incluye una lista de distintos tipos de certificados que el servidor puede aceptar (el tipo depende del mtodo de
autenticacin que se use). El tipo ms utilizado es el 1 que corresponde a RSA. Adicionalmente, el mensaje incluye una
lista de autoridades certificadoras aceptadas por el servidor.
La estructura de esta solicitud es:
# de bytes
Tipo de mensaje = 13

Longitud del mensaje

Longitud de la lista de tipos de certificados

Lista de tipos de certificados

variable

Longitud de la lista de autoridades

certificadoras
Longitud del nombre de la primera
autoridad certificadora

2
2

Primera autoridad certificadora

variable

Longitud del nombre la segunda

autoridad certificadora

Segunda autoridad certificadora

variable

Longitud del nombre de la ltima

autoridad certificadora

Ultima autoridad certificadora

variable

Figura 12. Mensaje de CertificateRequest

Saludo de Servidor Completado (ServerHelloDone)
Este mensaje es enviado para indicar que el servidor ha finalizado su saludo y cualquiera de los mensajes opcionales
asociados a dicho saludo: envo de su certificado, intercambio de clave de servidor, solicitud del certificado de cliente.
Esta constituido solo por dos campos, uno que indica el tipo de mensaje de handshake y otro su longitud, este ltimo
constituido por tres bytes rellenos de ceros.
# de bytes
Tipo de mensaje = 14

Longitud del mensaje = 0

Figura 13. Mensaje de ServerHelloDone

Intercambio de clave del cliente (ClientKeyExchange)
Con este mensaje el cliente enva informacin para que el servidor pueda establecer las claves de sesin. La informacin
que enve depender del algoritmo de clave pblica que se haya acordado entre ambos.
A continuacin se muestra su estructura:
# de bytes
Tipo de mensaje = 16

Longitud del mensaje

Informacin para establecer la clave de

sesin

variable

Figura 14. Mensaje de ClientKeyExchange

-31En el caso de usar RSA, la informacin que enva el cliente para que el servidor determine las claves de sesin es el
secreto pre-maestro (nmero aleatorio), cifrado con la clave pblica del servidor.
Secreto pre-maestro cifrado = (Secreto pre-maestro)e mod m
# de bytes
Tipo de mensaje = 16

Longitud del mensaje

Secreto pre-maestro cifrado

variable

Figura 15. Mensaje de ClientKeyExchange

En el caso de usar Diffie-Hellman, la informacin que enva el cliente para que el servidor determine las claves de sesin
es su nmero pblico. Ntese que para este algoritmo en particular, se har uso de este mensaje solo en caso que el
nmero pblico del cliente no se le haya hecho saber al servidor mediante un mensaje Certificado del cliente.
# de bytes
Tipo de mensaje = 16

Longitud del mensaje

Nmero pblico del cliente

variable

Figura 16. Mensaje de ClientKeyExchange

El servidor toma el nmero pblico o clave pblica del cliente Tc y determina la clave secreta, mediante la funcin
exponencial discreta que caracteriza a Diffie-Hellman:
Clave secreta = (Tc)A mod p,
donde A es un nmero aleatorio generado por el servidor, y el mdulo p ha sido enviado al cliente previamente en un
mensaje de Certificado o de Intercambio de Clave del Servidor. Como ya se dijo, la clave secreta ser usada como el
secreto pre-maestro, que permitir el posterior establecimiento de las claves de sesin entre cliente y el servidor.
Verificacin de certificado (CertificateVerify)
Como su nombre lo indica, el propsito de este mensaje es comprobar explcitamente el certificado del cliente. El cliente
prepara una firma digital de todos los mensajes de handshake que han intercambiado l y el servidor hasta ahora,
excepto el de Saludo de Cliente. La comprobacin de esta firma por parte del servidor, le permite autenticar al cliente, as
como corroborar la integridad de la informacin cursada entre ambos.
Este mensaje solo es enviado por un cliente con un certificado vlido para firmar. Su estructura es:

# de bytes
Tipo de mensaje = 15

Longitud del mensaje

Longitud de la firma

Firma

variable

Figura 17. Mensaje de CertificateVerify

Fin del Handshake (HandshakeFinished)

-32Este mensaje finaliza la fase de handshake. Contiene un extracto o condensado de todos los mensajes, anteriores a ste,
intercambiados entre cliente y servidor, y la clave de sesin que comparten; por tal razn permite verificar la integridad de
la informacin cursada entre ambos, as como comprobar que el intercambio de la clave fue exitoso. El extracto obtenido
es producto de la combinacin de las funciones MD5 y SHA.
# de bytes
Tipo de mensaje = 20

Longitud del mensaje = 36

Digest

36

Figura 18. Mensaje de HandshakeFinished

Los mensajes de cambio de especificacin de cifrado, como se ver ms adelante, no son considerados parte del
protocolo de handshake, por lo tanto no son incluidos en el condensado.
El protocolo de registro (Record Protocol)
La funcin principal de este protocolo es proveer un formato nico para toda la informacin proveniente de la capa
superior de SSL la cual incluye los mensajes de handshake, los mensajes de alerta, los mensajes para cambio de
especificaciones de cifrado o los mensajes con datos de la aplicacin. Los datos proveniente de esta capa superior son
fragmentados en bloques de 214 bytes (16383 bytes) y encapsulados, para luego ser entregados al protocolo TCP.
Opcionalmente al fragmento se le comprime, se le aplica un algoritmo MAC para garantizar su integridad y se le encripta.
Todo esto se lleva a cabo en el extremo emisor. En el extremo receptor se sigue el proceso contrario: el fragmento se
desencripta, se verifica su integridad calculando su MAC, se descomprime y se reensambla, antes de entregarse a la
capa superior los datos que ste contiene. El diagrama ilustra este proceso:

Figura 19. Capa de registro

A los fragmentos se les denomina registros o records. A cada clase de mensaje de la capa superior de SSL, se le asigna
un tipo de registro:

20

Mensaje de Cambio de especificacin de cifrado

-3321

Mensaje de alerta

22

Mensajes de handshake

23

Mensaje con datos de la aplicacin

Tipos de registros
Los mensajes de handshake normalmente se transmiten uno por registro, aunque existen implementaciones de SSL que
agrupa varios mensajes de este tipo en un solo registro. Los mensajes de alerta y de cambio de especificacin de cifrado,
se transmiten uno por record. En el caso particular de mensajes con datos de la aplicacin, la capa de registro los
secciona libremente, independientemente de los lmites que la aplicacin les haya asignado.
Cada registro posee un encabezado que lo identifica el cual contiene los siguientes campos: el tipo de registro, la versin
del protocolo SSL que se est usando y la longitud en bytes del fragmento de datos incluido en el registro. Este es igual o
menor a 214 bytes.
# de bytes
Tipo de registro

Nmero de versin del protocolo

Longitud del fragmento

Figura 20. Encabezado del registro

Todos los registros enviados luego del registro de cambio de especificacin de cifrado, estn criptogrficamente
protegidos con algoritmos y claves recin negociados. Para garantizar la integridad del registro se usan los cdigos de
autenticacin basados en funciones hash (HMAC) MD5 y SHA. La confidencialidad del registro se logra mediante el uso
de una variedad de algoritmos de cifrado, la mayora de ellos cifradores de bloque como DES, triple-DES, AES y RC2,
excepto el cifrador de flujo RC4.
En el diagrama se muestra todo el proceso que se lleva a cabo en la capa de registro, en el caso de que se use un
cifrador de bloque.

Nmero de secuencia

Encabezado del registro

Registro

Encabezado del registro

Registro

HMAC

Encabezado del registro

Registro

HMAC

Encabezado del registro

Registro

HMAC

Cifrado

Encabezado del registro

Registro cifrado

Clave para
integridad

Relleno

Clave de
cifrado

-34-

Figura 21. Registro protegido criptograficamente

Para el clculo del HMAC se usan dos argumentos, la clave de sesin para integridad y los datos. Los datos estn
conformados por un nmero de secuencia de 64 bits, asignado al mensaje por el emisor, seguido por el encabezado y los
datos del registro. El nmero de secuencia slo es usado en el clculo anterior y no se transmite; su nico propsito es
proteger contra rplicas y desordenes en los mensajes, en caso de que TCP falle. Cada nodo mantiene nmeros de
secuencia distintos para la transmisin y recepcin de mensajes. El valor de dichos nmeros es inicializado en cero
cuando se enva o se recibe mensajes de cambio de especificacin de cifrado.
Como el cifrador usado en este caso requiere un tamao de bloque determinado; si el conjunto datos/HMAC no es igual a
este tamao, o multiplo de el, deben usarse bits de relleno para lograrlo.
Solo el conjunto datos/HMAC/relleno es cifrado, mientras que el encabezado se transmite en texto en claro.
Protocolo de Cambio de Especificacin de Cifrado (ChangeCipherSpec)
Este protocolo fue creado para indicar cambios en los algoritmos de cifrados que servidor y cliente manejan. Est
constituido por un solo mensaje que es enviado tanto por el servidor como por el cliente en la fase de handshake, para
as notificar que los registros subsiguientes estarn protegidos de acuerdo a las claves y algoritmos recin negociados.
Tambin es enviado despus de los mensajes de saludo durante la reanudacin de una sesin previa. La estructura del
mensaje se muestra a continuacin:
# de bytes
Tipo de cambio de especificacin de cifrado

Figura 22. Mensaje de ChangeCipherSpecification

Tipo

de cambio de especificacin de cifrado: Hasta ahora ha sido definido un solo tipo de cambio de
especificacin de cifrado, denotado por 1 y que indica: Cambie a los algoritmos recin negociados. No est
claro para que tantos bits en este campo si existe un nico mensaje de cambio de especificacin de cifrado.

A pesar de que el mensaje de Cambio de Especificacin de Cifrado es usado siempre en la fase de handshake, este fue
clasificado como un protocolo aparte y se le asign un tipo de registro distinto.
La razn detrs de esto es para demarcar que la informacin transmitida en los registros luego de este mensaje estar
protegida de acuerdo a las claves y algoritmos recin negociados. Es decir, el Cambio de Especificacin de Cifrado funge
como registro delimitador entre registros que no estn protegidos criptogrficamente o si lo estn, usan algoritmos y
claves distinto a los recin negociados.
Protocolo de Alerta
El protocolo de Alerta se encarga de notificar y ejecutar acciones en caso de alarmas y errores durante la sesin. Est
constituido por dos tipos de mensajes: alarma (warning) y fatal. Los mensajes de alarma avisan de una situacin irregular
que puede ser subsanada. Los mensajes fatales finalizan inmediatamente la sesin. La estructura del mensaje es la
siguiente:
# de bytes

Technet de Microsoft.Nivel de alerta

Descripcin del alerta

-35Figura 23. Mensaje de Alerta

Nivel de alerta: Es un valor que define el tipo de mensaje de alerta, 1 para alarma (warning) y 2 para fatal.
Descripcin del alerta: Es un valor que se corresponde con una descripcin del alerta segn la siguiente

tabla:
Nmero

Nombre del alerta

Descripcin

Notificacin de cierre
(Close_notify)

No es un mensaje de error, fue creado para indicar que el emisor no

tiene ms informacin que enviar. Es enviado como mensaje final
para cerrar la sesin SSL. Si el nivel de alerta que se le asigna es
de alarma, la sesin podr ser reanudada. Si el nivel de alerta que
se le asigna es fatal, la sesin no podr ser reanudada.

10

Mensaje inesperado
(Unexpected_message)

Indica que se ha recibido un mensaje que no es el esperado.

20

MAC del record incorrecto

(Bad_record_mac)

Indica que el extracto o cdigo de autenticacin (MAC) del registro

es incorrecto. Va acompaado por un nivel de alerta fatal.

30

Falla al descomprimir
(Decompression_failure)

Indica que no se pudo descomprimir correctamente los datos en el

record. Va acompaado por un nivel de alerta fatal.

40

Falla en el handshake
(Handshake_failure)

Indica que el emisor no logr negociar un conjunto de parmetros

de seguridad aceptables; por ejemplo, si los algoritmos propuestos
por el otro nodo no satisfacen los requerimientos del emisor.

41

Sin certificado
(No_certificate)

Enviado por el cliente como respuesta a una solicitud de certificado

del servidor, cuando no posee un certificado con las caractersticas
de los especificados en la solicitud.

42

Certificado falsificado
(Bad_certificate)

Enviado cuando el nodo receptor de un certificado comprueba que

es fraudulento: no esta avalado por una autoridad certificadora
reconocida o no pasa la verificacin de la firma digital que lo avala.

43

Cerificado no soportado
(Unsupported_certificate)

Enviado cuando el emisor no soporta el tipo de certificado enviado

por el otro nodo.

44

Certificado revocado
(Certificate_revoked)

Enviado cuando el nodo recibe un certificado que ha sido revocado.

45

Certificado vencido
(Certificate_expired)

Enviado cuando el nodo recibe un certificado cuyo perodo de

validez ha expirado.

46

Certificado desconocido
(Certificate_unknown)

Enviado si cualquier otro error, no contemplado en los casos

anteriores, surge durante la verificacin del certificado.

47

Parmetro ilegal
(Illegal_parameter)

Enviado si el nodo recibe un parmetro o un campo fuera de rango

en la fase de handshake. Va acompaado por un nivel de alerta
fatal.

Tipos de alertas