Correo seguro con GnuGPG, Thunderbird y Enigmail

Muchos ya lo conoceis, se trata de Gnu Privacy Guard GnuGPG o simplemente GPG  la alternativa software libre a PGP (Pretty Good Privacy), un programa  inventado por Phil Zimmermann para securizar para el envío de correo electrónico.

Pretty Good Privacy (PGP). Fundamentos

PGP se basa en el uso de la criptografía asimétrica para el intercambio de claves y criptografía simétrica para el cifrado de los datos, en este caso RSA e IDEA respectivamente. Es decir, se parece bastante a una PKI salvo por la no existencia de jerarquía de CAs, entidades anejas y certificados. Para la "confianza" una comunidad de usuarios hace disponibles sus claves públicas y firman las claves públicas de quienes confían bien intercambiándolas directamente entre sí, o  bien dejándolas disponibles en un sitio "web de confianza" conocido como servidor de claves .
Para transmitir la confianza y la verificación de la autenticidad de las claves públicas se hace uso de la firma electrónica. Por ejemplo, si Marcos confía en Juan, firmará la clave pública de Juan. Por otro lado, Ana que confía en Marcos, recibe un correo de Juan. Ana recupera la clave pública  de Juan (recibida o desde repositorio) y verifica que está firmada   correctamente por Marcos (comprueba la firma con la clave pública de Marcos). Entonces, por transitividad, Ana sabe que Juan es de confianza y le manda su clave pública para iniciar el intercambio de mensajes cifrados.

Básicamente PGP es un proceso de : "Yo no sé quien eres tú, pero mi amigo al que quiero mucho y confío en él me dice que tú eres un tipo majete y yo me lo creo".

De esta forma se van creando circuitos de confianza en la comunidad. El problema está en la "actualización", que al contrario que en una PKI tradicional no está centralizada por un certificado en la CA y por lo tanto si Juan pierde o renueva  su clave debe notificar al resto ,publicándola en la web de confianza, mandándola de nuevo, que la ha cambiado. Y esto no garantiza que llegue a todos los usuarios forzosamente. Conclusión: Es un sistema que es apropiado y seguro para un pequeño grupo de usuarios pero que no debe implantarse para grandes comunidades por el motivo referenciado. Asimismo, se ha de ser muy cuidadoso al compartir y al confiar la claves.


GnuGPG. El reemplazo

GPG deriva directamente de PGP con la diferencia de que se trata de software libre .
GPG utiliza el estándar del IETF denominado OpenPGP. Es estable, calificado como un software para el uso en producción y es comúnmente incluido  con todas las distribuciones GNU/Linux.

Aunque básicamente el programa tiene una interfaz de consola, actualmente hay varias aplicaciones gráficas que utilizan recursos de GPG. Vamos a hablar en este caso de Enigmail  un plugin  que se integra con Mozilla y Thunderbird y que trabaja en Windows, GNU/Linux y otros sistemas operativos.

Disclaimer: Un plugin no forma parte de GPG, se trata de desarrollo que hacen uso de él y por lo tanto debemos tener en cuenta que pueden presentar vulnerabilidades que hacen recomendable tener las aplicaciones convenientemente parcheadas y actualizadas.

Una vez explicado el funcionamiento de GPG vamos a ver una aplicación práctica.

Firma y cifrado con GPG y Enigmail

Instalación

En primer lugar, debes descargar e instalar GnuPG, disponible para los sistemas operativos más usados. Esto generalmente en Linux no es necesario puesto que ya viene con la distribución.

En segundo lugar, debes instalar la extensión Enigmail en tu cliente de correo, la cual puedes obtener en Mozilla Addons, entre otros sitios.

Una vez instalado el puglin recomiendo abrir el menú OpenPGP y editar las preferencias, donde puedes configurar a tu gusto el comportamiento , los servidores de claves etc. Esto es recomendable porque las opciones por defecto no simpre son las más seguras. 

Generación del par de claves

Fuente: Mozilla-Doc

Abre Thunderbird y verás una nueva opción en el menú superior a la izquierda de Herramientas titulado OpenGPG. Selecciona OpenPGP > Administración de claves. Se abrirá una ventana; selecciona en el menú Generar > Nuevo par de claves.

En el diálogo que aparece puedes especificar varias preferencias de la clave:

• La cuenta/identificación que quieres usar para el par de claves.
• La contraseña o frase clave del par de claves. La contraseña sirve para proteger tu clave privada contra un uso fraudulento; si alguien consigue robar tu clave privada, aún necesitará conocer la contraseña asociada para poder utilizarla.
• El tiempo de expiración de la clave, es decir, el tiempo durante el cual la clave que generes será válida. Puedes hacer pruebas con una clave con un tiempo de expiración bajo, pero más tarde puedes generar una clave que no expire nunca sin problemas, pues siempre puedes utilizar un certificado de revocación para invalidar tu clave.
• En la pestaña Avanzadas, el tamaño y el tipo de clave. Asegúrate de que seleccionas un tipo de clave DSA y El Gamal. Cuanto más grande sea la clave, más segura será, pero también requerirá más recursos el cifrado y descifrado lícito de mensajes.

Haz clic en el botón "Generar clave". El proceso puede llegar a tardar varios minutos, como indica la nota al pie del diálogo.

Cuando haya acabado, se te preguntará si quieres generar un certificado de revocación, el cual necesitarás si pierdes tu clave privada o te la roban. Haz clic en Sí y guarda el certificado en alguna carpeta que no sea de acceso público. También puedes guardarla en un lápiz USB, en un CD-ROM o en un disquete.

Una vez guardado el certificado de revocación en un lugar seguro podrás ver tu nueva clave en la lista de claves conocidas en negrita, y, en el campo Tipo, "pub/sec", que significa "pública/secreta", es decir, que posees tanto la clave pública como la clave privada.


Configuración de las claves

Fuente: Mozilla-Doc

Puedes utilizar tu nueva clave para firmar los correos que envíes. Para ello, abre el diálogo de configuración de las cuentas y en la sección Seguridad OpenPGP selecciona "Activar el soporte OpenGPG (Enigmail) para esta identidad".

Si sólo tienes la clave que acabas de generar, utiliza la opción "Usar la dirección de correo de esta identidad para identificar la clave OpenPGP", pero, si tienes más de una, puedes utilizar la opción "Usar un ID de clave OpenPGP específico" para elegir la que quieres usar.

Más abajo puedes activar el firmado y/o cifrado de los mensajes por defecto. Si no lo activas, siempre puedes hacerlo mientras estés redactando un correo a través del menú OpenPGP o los botones OpenPGP y S/MIME de la ventana de redacción, que se muestran por defecto tras instalar Enigmail.

Si sólo tienes tu clave privada y pública no puedes cifrar mensajes, sólo firmarlos, ya que necesitas la clave pública del usuario al que quieres enviar el mensaje cifrado para poder hacerlo. Si el usuario al que quieres enviar mensajes cifrados ya tiene clave pública, pídele que te la proporcione; si no, pídele que genere un par de claves de la misma manera que tú lo hiciste.

Subir la clave pública a un servidor de claves

Fuente: Mozilla-Doc

A pesar de que las claves públicas (nunca las privadas) se pueden distribuir por correo electrónico, mediante un lápiz USB, etc., lo más común es usar los llamados servidores de claves, que no son otra cosa que repositorios en Internet de claves públicas, de acceso libre, normalmente. Para publicar tu clave en uno de estos servidores, no tienes más que hacer clic derecho en ella en la ventana de administración de claves de Enigmail y seleccionar la opción Subir claves públicas al servidor de claves. En la lista de servidores que aparece, selecciona uno, por ejemplo, pgp.mit.edu (acuérdate de la dirección) y pulsa el botón Aceptar.

El usuario al que quieras enviar correo cifrado deberá realizar el mismo proceso (o el equivalente con su gestor de claves GPG) para subir su clave pública a un servidor de su elección, cuya dirección te deberá proporcionar. En la ventana del administrador de claves de OpenPGP, selecciona en el menú Servidor de claves > Buscar claves. En el diálogo que aparece, introduce la dirección del servidor de claves que te proporcionó el otro usuario y el nombre o identidad con que registró su clave. Pulsa Aceptar y aparecerá una ventana con las claves encontradas en el servidor que coinciden con tu criterio de búsqueda. Selecciona la que quieras importar y pulsa Aceptar, tras lo cual podrás ver la clave pública del contacto en la lista de claves disponibles, esta vez con el tipo "pública" presente en la columna Tipo.

Firmar y/o cifrar mensajes

Firmar y cifrar mensajes desde la ventana de redacción es muy sencillo.

Si quieres firmar tu mensaje, selecciona en el menú superior OpenPGP > Firmar mensaje, o pulsa el botón OpenPGP de la barra de herramientas y marca la opción. Al enviar el mensaje se te pedirá la contraseña o frase de paso de tu clave privada, si la protegiste de esta manera, y se generará un código a partir del contenido de tu mensaje que se adjuntará a éste y permitirá al destinatario verificar que el cuerpo del mensaje no ha sido alterado en su trayecto.

Si quieres cifrar tu mensaje, selecciona en el menú superior OpenPGP > Cifrar mensaje, o pulsa el botón OpenPGP de la barra de herramientas y marca la opción. Como ya se comentó, para enviar un mensaje cifrado a alguien necesitas su clave pública. Las claves de los destinatarios especificados en los campos «Para:» se buscarán en tu anillo de claves en función de su dirección de correo electrónico. Si al enviar el mensaje no se encuentra alguna clave o no es de confianza, se abrirá una ventana pidiéndote seleccionar las claves públicas que se usarán para cifrar, desde la que puedes también descargarte las claves que te falten desde los servidores de claves.

Fuente: Mozilla-Doc

Otro día veremos como se usa y gestiona directamente GPG: Desde el interfaz de comandos }:-)

Bondades del bonding

¿ Dispones en tu equipo de 2 tarjetas de red ?. ¿ Te gustaría sacarle partido a la ethernet que tienes integrada en la placa base ?
Haz bonding.
Con el término bonding entendemos la unión de 2 interfaces de red como si fuese un grupo, de modo que podemos hacer que actúen en conjunto, o bien en balanceo de carga, o una activa y otra de backup... etc.

La implementación es bastante sencilla y en este caso lo explico para Fedora aunque en otras distros de Linux es igual o muy similar. En Ubuntu ver ifenslave

Hoy en día creo que todas, o casi todas las distros incluyen el módulo del kernel necesario para levantar una interfaz "bond". EL módulo se llama como no, bonding. Este módulo por defecto no se carga en el inicio del kernel, pero si existen los ficheros de configuración para el bonding de las tarjetas y una adecuada definición, al arrancar  el servicio de red,  el módulo se cargará en memoria. El comportamiento o modo de operación del interfaz de bonding se hace asignando unos parámetros en la  carga del módulo. Esta parametrización se realiza en el  archivo de configuración del módulo, que estará ubicado bajo /etc/modprobe.d (o directamente en /etc/modprobe.conf si en  tu SO se encuentra).

Ejemplo
Supongamos tengo 2 ethernet , eth0 y eth1.
Primero definimos la interfaz bond  que agrupará las 2 tarjetas. La llamaremos bond0




mihost@root#vi /etc/sysconfig/network-scripts/ifcfg-bond0


El prefijo ifcfg- es la nomenclatura para la definición de los fichero de configuracion de las interfaces)



NBOOT=yes
DEVICE=bond0
IPADDR=192.168.50.210
NETMASK=255.255.255.0
GATEWAY=192.168.50.1
BOOTPROTO=none
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no 

Ajustar los valores a las IPs que tengais de router y a vuestra red

Luego editamos los ficheros de configuración de eth0 y eth1 para que queden similares a:

mihost@root#vi /etc/sysconfig/network-scripts/ifcfg-eth0


SLAVE=yes 

MASTER=bond0

 ONBOOT=yes 

TYPE=Ethernet 

DEVICE=eth0 

BOOTPROTO=none 

PEERDNS=yes 

USERCTL=no 

IPV6INIT=no



mihost@root#vi /etc/sysconfig/network-scripts/ifcfg-eth1


SLAVE=yes
MASTER=bond0
ONBOOT=yes
TYPE=Ethernet
DEVICE=eth1
BOOTPROTO=none

Finalmente agregamos un ficherito de configuración para que en el arranque el módulo bondig tome sus parámetros, en este caso he elegido el modo active-backup (o mode 1), donde el tráfico pasa por la primera tarjeta disponible quedando la segunda como backup en el caso de fallo. Tambén se prodría haber configurado para que las dos actúen a la vez (mode 4 o link-aggregation) o en balanceo de carga por Round Robin (mode 0). Mas info tirando de man o aquí

mihost@root#vi /etc/modprobe.d/netbond.conf

alias bond0 bonding

options bonding miimon=100 mode=active-backup primary=eth1

Y ya está. Reiniciais los servicios de red con service network restart.... y al hacer ifconfig veréis un bonito interfaz bond0.

Podréis seguir el estado  del interfaz en el fichero /proc/net/bonding/bond0

Analizando SSL (III de III): Funcionamiento y ejemplos

Funcionamiento

A partir de ahora nos referiremos directamente a TLS, en concreto TLSv1.0 que es la evolución de SSL ( SSL 3.1). Actualmente y desde 1999 en que se establece como estándar IETF es el protocolo de conexión segura por autonomasia. Posteriormente aparecieron TLSv1.1 y TLSv1.2

TLS es un protocolo de 2 capas: TLS Record Protocol y una capa superior compluesta por protocolos que son encapsulados por la capa de registro: Handshake, Alert Protocol, Change cipher Spec y Application protocol.

El protocolo de registro (Record Protocol) se implementa sobre la capa TCP y tiene como 2 propiedades fundamentales que:

1. Conexión privada con cifrado simétrico, basado en secreto compartido y negociado en el handshake. Puede usarse sin cifrado
2. Conexión confiable:  El transporte del mensaje usa un mensaje de chequeo de integridad que utiliza un MAC (Message Authentication Code) con clave, usando funciones de hash seguras como SHA y MD5, pero puede operar sin usarla.

Este protocolo encapsula protocolos de más alto nivel, como el  HandShake Protocol.
Fundamentalmente se encarga de tomar los mensajes a ser transmitidos, fragmenta los datos en bloques manejables, opcionalmente comprime los datos, aplica una MAC, cifra y transmite el resultado. El dato recibido es desencriptado, verificado, descomprimido y reensamblado, entregándose a los clientes en niveles más altos. Este proceso se lleva a cabo mediante el uso de cuatro estados posibles de conexión : el estado de lectura actual, el estado de escritura actual, el estado pendiente de lectura y el estado pendiente de escritura. Cada estado especifica el algoritmo de compresión, el algoritmo de encriptación y el algoritmo de MAC, junto con el MAC con clave y el tamaño de las claves de encriptación.

Para cifrar los datos, el Record Protocol utiliza alguno de los siguientes algoritmos de criptografia simétrica: RC4, DES, IDEA,.

El protocolo de Handshake es el que  permite a las 2 partes autenticarse mutuamente y negociar el cifrado antes de intercambiar datos. Negocia y establece la conexión.  Sus propiedades principales son:

1. Autenticación asimétrica de al menos una de las dos partes
2. Negociación del secreto compartido o premaster secret (simétrico) seguro, mediante  técnicas de encriptación de clave pública (asimétricos). De ese premaster secret se derivará una clave simétrica común con la que se cifrarán los datos.
3. Negociación confiable: no es posible una modificación sin que se ninguna de las dos partes se de cuenta de ello.
4. Proporciona los parámetros de seguridad a la capa de registro (Record Protocol)

Para realizar el intercambio de claves, el Record Protocol utiliza los siguientes algoritmos: RSA, Diffie Hellman.
Como vemos , con este protocolo conseguimos una conexión segura gracias a la capa de Registro que nos proporciona la confidencialidad y la integridad y la capa de Handshake que pemite la autenticación.

Recordemos de la parte (Analizando SSL ( II  de III): Aplicaciones y Estructura) la estructura y los tipos que tenemos en el Protocolo Handshake:

Seguridad

TLS/SSL implementa un buen número de medidas de seguridad:

• Protección contra un posible "downgrade" hacia una versión inferior del protocolo (menos segura).
• Numeración de los registros de Aplicación con un número de secuencia y uso de esta secuencia en los Mensajes de Autenticación de Codigo (MACs). Estos mensajes se crean empleando funciones de hash que protegen la integridad.Esto se especifica en el RFC2104
• Uso de funciones resumen hash potenciadas con el uso de clave de modo que solo el poseedor de la clave puede comprobar el MAC. Esto evita los ataques por colisión o Meet in The Middle
• El mensaje que finaliza el Handshake incluye un hash de todos los mensajes de handshake previamente intercambiados con lo que garantizamos la comunicación íntegra.

Handshake

Se pueden dar tres modalidades de Handshake a la hora de establecerse la comunicación entre el cliente y servidor:

1.  Handshake completo: Tanto el servidor como el cliente se intercambian certificados
2. Handshake simple: Solo el servidor y no el cliente se autentica con entrega de su certificado
3. Handshake resumido: Debido a que las operaciones con clave publica (generalmete RSA) son costosas computacionalmente, TLS incorpora un modo "resume" para evitar esas operaciones del handshake completo. En el establecimiento de una conexión el servidor y cliente intercambian  un id de sesión que el cliente asociará con la IP y puerto del servidor de modo que cuando el cliente se reconecte usará ese id. El servidor comprobará que tiene en caché ese id de sesión ofrecido por el cliente y en ese caso puede decidir retomar la conexión con los parámetros ya negociados anteriormente (resume) o ofrecer un nuevo id obligando a realizar de nuevo un handshake completo. Como se puede entender, es un método que conviene usar muy repetidamente pues estamos reutilizando las misma claves de cifrado que pueden tiempo y mas oportunidad de análisis a un tercero que capture el tráfico. 

La negociación y  establecimiento de la conexión consta de un intercambio de varias estructuras handshake (Message Types) y que, en el caso una conexión simple (autenticación de servidor) podemos ver esquematizada en la siguiente figura:

Fig 1. SSL/TLS Handshake

Detalle de un Handshake simple

1. Client Hello. El cliente envía un mensaje ClientHello al servidor especificando una lista de conjunto de cifrados (Cipher Suites), métodos de compresión (Compression Methods) y la versión del protocolo SSL más alta permitida. Éste también envía bytes aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además puede incluir un identificador no nulo de la sesión si quiere intentar "retomar" una sesión establecida con anterioridad. Si el Id es nulo se renegocia handshake completo.
2. Server Hello. El servidor contesta al cliente escogiendo una suite de las ofrecidas, enviando id de sesión, versión, compresión y  un numero aleatorio (Random) que se usará con el de cliente en la creación de la clave simétrica.
3. Certificate. Ofrece su certificado. Este puede contener clave pública para el cifrado o ser un certificado de firma con lo será necesario el paso 4 para enviar una clave pública firmada. 
4. ServerKeyExchange. Este mensaje se envía sólo si el anterior mensaje no incluye clave pública para el cifrado escogido. Con este mensaje el servidor ofrece para el cifrado asimétrico entre cliente y servidor la clave pública firmada con la clave del Certificado . De esta forma se separa la autenticación (paso 3 , certificate) del cifrado. Lo más común es que el Certificado sea un certificado de autenticación de servidor que incluya la clave pública de cifrado
5. Server Hello Done. El server da por concluida su fase de negociación asimétrica.
6. ClientKeyExchange. El cliente tras haber comprobado y validado el certificado, genera el premaster secret (48 bytes, 2 bytes de la versión SSL y 46 aleatorios) que será el elemento secreto compartido que junto a otros datos intercambiados previamente (random, id de servidor y cliente) daran lugar a un mismo master secret en la parte servidor y en la cliente y que será la clave simétrica utilizada para cifrar los datos. El premaster secret es cifrado con la clave pública del servidor y enviada. De este modo sabemos que solo el servidor legítimo puede descifrarlo y generar el master secret de la sesión.
7. ChangeCipherSpec. Con este mensaje el cliente informa que los sucesivos estarán cifrados con el cifrado acordado.
8. Finished. El cliente da por finalizada su handshake. El mensaje que finaliza el Handshake incluye un hash de todos los mensajes de handshake que garantiza la integridad de la comunicación.
9. ChangeCipherSpec. El servidor tras checkear que todo ha ido correctamente (en base al hashing MAC) , descifra con su clave ptrivada el premaster secret enviado por el cliente en el paso 6 y genera el master secret del mismo modo que el cliente. En este momento cliente y servidor han logrado establecer una clave simétrica y acordado un cifrado. Con este mensaje el servidor indica que sus mensajes desde este momento se cifran.
10. Finished. Parte servidor finaliza el handshake....

El canal SSL está creado, todos los datos serán cifrados. Tiempo para el Application Protocol. Empieza la fiesta privada!!!

Handshake Abreviado

Esta tabla muestra los diferentes mensajes en la conexión abreviada. Cada link lo llevará a la explicación del mensaje.

Mensajes para la conexión con handshale abrebiado

Cliente	Server
ClientHello
	ServerHello
	ChangeCipherSpec
	Finished
ChangeCipherSpec
Finished
Datos de Aplicación <----->	<-----> Datos de Aplicación

En una forma resumida, el handshake es como sigue:
El cliente envía un ClientHello usando el session-ID de la sesión a ser reanudada y otros 48 bytes random. El server luego chequea en su cache de sesiones para ver si encuentra esa sesión. Si se encuentra la sesión, y el server está dispuesto a reestablecer la conexión bajo el estado especificado de sesión, mandará un ServerHello con el mismo valor de session-ID y otros 48 bytes random. Se debe regenerar el master secret y las claves de sesión, los secretos MAC y los IVs. En este punto tanto el cliente como el server deben enviar directamente mensajes ChangeCipherSpec y Finished. Una vez que el reestablecimiento esta completo, el cliente y server empiezan a intercambiar datos de aplicación.
Si el server no puede encontrar el session-ID en su cache, el server genera una nuevo session-ID y tanto el cliente como el server TLS ejecutan un handshake completo.

Analizando SSL (I  de III) :Historia

Analizando SSL ( II  de III): Aplicaciones y Estructura

Analizando  SSL (III de III): Funcionamiento y ejemplos

Pool de direcciones IPv4 out

Bueno amigos, fue bonito mientras duró. El espacio de direcciones IPv4 se ha agotado. Ayer 3 de febrero de 2011 la Internet Assigned Numbers Authority (IANA) en acto oficial  entregó a las 5 RIRs (Regional Internet Registry) las últimas  cinco direcciones IPv4 /8  para su asignación en acuerdo con la Politica Global del espacio de direcciones Ipv4 restante. Con esta acción el pool  libre de direcciones IPv4 se ha agotado.


Durante  un tiempo existirá una convivencia entre el mundo de los 32bits (Ipv4) e IPv6 (128bits). Llegados a este día cabe preguntarse ¿estoy preparado? .Echan un vistazo a mi configuración veo que tengo ipv6 activado por defecto pero sin configurar. ¿Y tu? ¿Que tal el ping6 ipv6.google.com ? ¿ Network is unreachable ?..... Bien , pues manos a la obra  ipv6 es la solución.

Si aun no tienes dir ipv6 en tu router puedes probar con un tunel. Aqui puedes obtener uno e incluso "certificarte"
Suerte

Analizando SSL ( II de III): Aplicaciones y Estructura

Aplicaciones

SSL/TLS se ejecutan en una capa por debajo los protocolos de aplicación como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP. Es importante señalar que ambos protocolos se ejecutan sobre una capa de transporte definida, pero no determinada. Esto indica que pueden ser utilizados para cualquier tipo de comunicaciones. La capa de transporte más usada es TCP sobre la cual pueden implementar seguridad en HTTP, conocida como HTTPS.

SSL también puede ser usado para tunelizar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.
Como punto de diferencia se puede mencionar que existen protocolos implementados sobre la capa de red, por ejemplo sobre IP. Tal es el caso de IPSec.

¿ De que están compuestos ?

El protocolo SSL/TLS se basa en un modelo de 2 capas implementado por registros:


Una capa que se situa por encima de TCP , el Record Protocol o Protocolo de Registro
La otra capa inmediatamente superior, es la capa de los protocolos que proporcionan mensajes TLS válidos: Handshake, Alert, ChangecipherSpec y los específicos de Aplicación.

Fig 1. Componentes del protocolo SSL/TLS

Como vemos, TLS usa la capa Record Protocol para recibir los mensajes de las cuatro diferentes  fuentes  que pueden crear mensajes TLS: El protocolo ChangeCipherSpec, el protocolo Alert, el Handshake y el protocolo de Aplicación como por ejemplo, http (https). La capa de registro acepta esos mensajes de protocolo y entonces los formatea,  fragmenta y opcionalmente, comprime y cifra (dependiendo de las necesidades del protocolo superior)

Fig 2. Record Protocol.  Encapsulado de mensajes por la capa de Registro.

Mientras los Protocolos de Handshake se encargan de negociar los parámetros de seguridad, es en la capa de Registro donde se realizan las operaciones de fagmentado , compresión y  cifrado que aseguran los datos. El Prototocolo  Change Cipher Spec es enviado por ambos, el cliente y servidor para notificar la política de recepción de los subsiguientes registros los cuales estarán protegidos bajo la nueva negociación del CipherSpec y las claves. El Alert Protocol se usa para notificar errores  y dependiendo de la criticidad puede hacer finalizar la conexión. Los mensajes de datos de aplicación son entregados por el protocolo de Aplicación que la capa de Registro  fragmenta, comprime y cifra , llevándolos a la capa de transporte.

Formato detallado de los Registros TLS

Cada registro tiene un campo de un 1 byte usado para content_type (ver protocol en Fig 2) que especifica el protocolo de nivel superior que se está encapsulando.

Figura 3. Formato genérico de un registro SSL/TLS

Tipos:

Como vemos en la Figura 3  el registro genérico de protocolo SSL/TLS define los 4 posibles valores mediante el campo content_type : 20,21,22 y 23

El tipo Handshake (content_type=22) es el que se usa en el trasiego del establecimiento de la conexión cliente-servidor y donde se negocian las especificaciones de cifrado, certificados, intercambio de claves ,etc que gobernarán la comunicación TLS y que se definen en el campo "Message type" (ver Fig 3).  tipos content_type=20 ( ChangeCipherSpec) y content_type=21 (Alert)   se usarán para cambiar el cifrado en uso o para manejo de errores (por ejemplo cuando el certificado no es de confianza). Una vez de acuerdo cliente y servidor se inicia el intercambio de datos cifrado con registros de content_type =23 (Aplication).

Figura 3:  Handshake TLS . Obsérvese los diferentes Message Types

En la siguiente entrega veremos el funcionamiento del protocolo TLS

Analizando SSL (I  de III) :Historia

Analizando SSL ( II  de III): Aplicaciones y Estructura
Analizando  SSL (III de III): Funcionamiento y ejemplos