SSL/TLS: Una guía rápida de comprensión y elementos para PCI-DSS

Resumen:

La presente guía intentará sentar las bases y definiciones de los protocolos Secure Socket Layer
(SSL) y Transport Layer Security (TLS) pasando por entender las nociones básicas usadas para asegurar la
confidencialidad, integridad y no repudiación de los datos que se transmiten utilizando dichos protocolos.
Seguidamente, se introducirán los requerimientos asociados a la transmisión de datos de tarjeta en el
estándar PCI-DSS y como una implementación adecuada permite a las entidades cumplir con dicha
solicitud.

En muchas ocasiones, proveedores de servicios y demás entidades relacionadas solicitan la
implementación de un mecanismo de cifrado adicional en la capa de aplicación, aunque si bien esto podría
contribuir con el principio de “defensa profunda” se verá como con el uso del protocolo TLS ya se asegura
la confidencialidad como requisito para la transmisión de datos de tarjeta en redes públicas o abiertas.
Se aprovechará también para tener una sección práctica que muestra en detalle una sesión de
comunicación bajo el protocolo TLS de manera presentar como se mantiene la confidencialidad de los
datos que se envían en ese canal.

Introducción

A todas aquellas entidades que procesan, almacenan o transmiten datos de tarjeta, existe la
exigencia de reguladores y bancos adquirientes en el cumplimiento del estándar Payment Card Industry
Data Security Standard (PCI-DSS). El estándar PCI-DSS contempla, a través de sus 12 requerimientos, el
mantener la confidencialidad e integridad de datos de tarjeta en todas las funciones que puedan estar
teniendo comerciantes y otros proveedores de servicios que se involucren en la autorización, conciliación
y compensación de transacciones con tarjeta de débito y crédito.

El requerimiento 4 del estándar PCI-DSS tiene por principal objetivo preservar la confidencialidad
de los datos de tarjeta capturados y que son transmitidos a la red de pagos para obtener una respuesta
de autorización en una transacción regular. Mantener la confidencialidad involucra por ende la
implementación de criptografía para permitir que los datos sean ilegibles para elementos ajenos a la
comunicación entre el cliente que tiene datos de tarjeta y el servidor que espera dichos datos para la
autorización.

Contemplando la necesidad de confidencialidad, las comunicaciones en las redes públicas y
abiertas en Internet se basan en el uso de protocolos como SSL y TLS para tal fin ya que contemplan un
marco para el intercambio de llaves criptográficas y mecanismos adicionales para evitar la no repudiación
que aseguren de manera integral la comunicación sin necesidad de que desarrolladores y programadores
tengan que reinventar la rueda.

Protocolo Secure Sockets Layer (SSL)

SSL es el protocolo de comunicaciones usado en mayor parte por la comunidad de internet. Hay
muchas aplicaciones que actualmente que hacen uso de este protocolo para la transmisión segura sobre
TCP. El protocolo se base de manera integral en tres puntos fundamentales para asegurar la comunicación
en las conexiones:

• Privacidad y confidencialidad – a través del uso de algoritmos de cifrado.
• Identidad y autenticación – mediante certificados digitales.
• No repudiación – capacidad de mantener la conexión segura e identificar posibles alteraciones en
tránsito.

La versión actual del protocolo SSL es la 3.0 que fue propuesta por Netscape en el año 1990. Al
momento en que se ha escrito este documento, esta versión del protocolo tiene vulnerabilidades
conocidas entre las que se pueden destacar: POODLE, BEAST, CRIME entre otros. Para más información
sobre estas vulnerabilidades referirse a la entrada: TLS/SSL Explained en la bibliografía.

¿Cómo funciona SSL?

El protocolo SSL se basa en 4 capas (Record Layer, ChangeCipherSpec Protocol, Alert Protocol y
Handshake Protocol) para encapsular de forma segura todas las comunicaciones entre cliente y servidor.
Basicamente estas capas buscan que se pueda establecer el uso de una llave para el cifrado/descrifrado y
autenticación entre cliente y servidor basándose en el uso de la criptografía de llave pública y llave
privada.

La criptografía de llave pública y llave privada utiliza dos tipos de llave, una de carácter y
conocimiento público utilizada para cifrar y una privada para descifrar. Este mecanismo es utilizado en la
capa de Handshake del protocolo SSL para poder intercambiar una llave de criptografía simétrica que
pueda cifrar y descrifrar los datos que serán transmitidos por este canal.

Handshake Protocol

Los mensajes que son intercambiados entre cliente y servidor son coordinados en primera
instancia por un “handshake”. Esta capa funciona como el elemento para poner de acuerdo al cliente con
el servidor en su identidad y que llave se utilizará para cifrar/descrifrar y firmar la comunicación. Los
mensajes que componen el handshake son: ClientHello, ServerHello, ServerKeyExchange,
ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, Finished, ChangeCipherSpec, Finished. A
continuación se explicarán brevemente cada una de las fases del handshake:

ClientHello

El primer mensaje para el inicio de la comunicación es el ClientHello. El cliente que solicita la
sesión de comunicación segura con un servidor envía este mensaje detallando: Versión del protocolo SSL
que utilizará, la suite de cifrado y compresión que soporta, un número aleatorio de 32 bytes para asistir
en la generación de las llaves simétricas y un Id de sesión para que se pueda identificar la comunicación
con el servidor.

ServerHello

El segundo mensaje es el ServerHello. En este mensaje el servidor que recibe la solicitud le
comunica de vuelta al cliente, basado en las opciones ofrecidas por el cliente en la suite de cifrado,
compresión y elementos aleatorios, cuales serán entonces los algoritmos y mecanismos utilizados para
establecer la sesión.

ServerKeyExchange

Ya el servidor ha podido tomar decisiones y establecer las características que se utilizarán para la
transmisión en el canal, es momento de que cliente y servidor se pongan de acuerdo como serán cifrados
los datos que intercambiarán. Dado que no se ha negociado un algoritmo, todos estos datos son enviados
en claro.

La llave pública del servidor es utilizada por el cliente para cifrar una llave de sesión creada para
esta comunicación. Cliente y Servidor utilizarán entonces esta llave de sesión dentro del ámbito de la
criptografía simétrica para cifrar y descrifrar los datos en la conversación.

Para asegurar que las partes se están comunicando con quien dice ser, se hacen uso de
certificados digitales como medio para proveer identificación digital. Los certificados digitales combinan
la llave pública y la conecta con el nombre del dueño de dicha llave. Adicionalmente, estos certificados
contienen la llave pública de las autoridades de certificación como RSA Security o VeriSign así como una
fecha de vencimiento de forma que la entidad que recibe el certificado pueda verificar su autenticidad.
Los certificados solo contienen llaves públicas y nunca deberán tener llaves privadas agregadas en ellos,
ya que, el hacerlo compromete la parte fundamental de la criptografía asimétrica y el certificado digital
sería inválido.

ServerHelloDone

Una vez completado la fase ServerKeyExchange el cliente recibe el mensaje ServerHelloDone para
indicar que el servidor ha culminado con sus mensajes. Esto se podría asemejar a una conversación con
“walkie talkies” donde cada una de las partes dice “cambio” para anunciar que finalizó de enviar un
mensajes y avisa a la otra parte que reconoce haber enviado un mensaje.

ClientKeyExchange

Considerando que el protocolo SSL no requiere que un cliente tenga una llave pública y privada
para establecer la comunicación, el mensaje ClientKeyExchange contiene la información acerca de la llave
que el cliente y el servidor utilizarán para comunicarse de manera confidencial bajo la arquitectura de
criptografía simétrica. Este mensaje completa la negociación entre el cliente y el servidor.

ChangeCipherSpec

Los dos mensajes siguientes, denominados ChangeCipherSpec señalan el intermcabio de datos
desde un estado inseguro a un estado seguro. Cada parte envía dicho mensaje para cambiar su lugar de
la conexión a lo que previamente pudieron negociar en algormitos y llaves de sesión.

Finished

Los dos mensajes finales que indican la finalización del handshake aseguran que los tres elmentos
fundamentales del protocolo han sido verificados. Estos son:

• Información sobre las llaves
• El contenido de todos los mensajes previos fueron intercambiados exitosamente
• Un valor especial que indica si la entidad que envia mensajes es cliente o servidor

La ilustración a continuación muestra gráficamente el flujo de intercambio de mensajes en un
handshake del protocolo SSL.

Protocolo TLS

El protocolo TLS es una derivación del protocolo SSL, fue introducido luego de que se detectaran
varias vulnerabilidades en la versión 3 del protocolo SSL, la más famosa siendo el ataque POODLE.
Basicamente TLS contempla una versión mejorada del handshake para solucionar dichas vulnerabilidades.
Actualmente se encuentra en la versión 1.2 y se plantea tener la versión 1.3 para finales del año 2019.
Las diferencias fundamentales entre SSL y TLS tienen que ver con la especificación de la
autenticación de mensajes en tránsito utilizando funciones HMAC que no necesariamente se basen en
MD5 o SHA. Se agregaron también una serie de mensajes adicionales para poder establecer una
verificación exitosa de certificados. Al momento, se sugiere que todos las transmisiones que contengan
datos sensibles hagan uso del protocolo TLS 1.2.

Prueba Práctica SSL/TLS

En esta sección se mostraran de forma práctica y se observarán, con ayuda de un analizador de
protocolos, como transcure una comunicación SSL desde su handshake hasta el intercambio de datos en
una sesión. Con esto lo que se pretende mostrar es como los datos viajan cifrados y sentar un precedente
para poder definir que no es necesario contar con otros mecanismos adicionales de cifrado si se utiliza correctamente el protocolo. Lo que se debe tener claro es que, como toda implementaciónd de criptografía de llave pública y llave privada, los certificados digitales deben poderse validar correctamente para evitar comprometer la confidencialidad y al integridad.
A continuación se verá, con ayuda de la aplicación OpenSSL, como un cliente y un servidor establecen la comunicación segura.
De forma práctica, se dejó un cliente local ejecutando la opción openssl s_client que se comunicará con un servidor openssl en version s_server para poder visualizar los pasos del handshake. Los screenshots a continuación muestran este detalle.

 

En la primera de las ilustraciones, se puede observar como el cliente se conecta al servidor y se
inician los mensajes de Handshake entre los que se pueden visualizar ClientHello, ServerHello y el envío
del certificado.

 

Esta serie de ilustraciones muestra entonces de forma práctica los pasos de negociación del
handshake y muestra la negociación de una llave de sesión simétrica utilizando métodos de criptografía
asimétrica.

A continuación se mostrarán detalles de captura de paquetes con el analizador de protocolos
Wireshark. Este analizador de protocolos permite capturar paquetes del protocolos IP, UDP y además
analizar protocolos de nivel de aplicación como TLS. Las ilustraciones a continuación muestran sobre el
mismo ejemplo anterior como luego de que se termina el handshake, la conexión está protegida y un
actor ajeno que pueda capturar paquetes solo verá payload y application data cifrada.

La ilustración 7 en definitiva muestra como los datos intercambiados se encuentran cifrados, de manera
que incluir una capa adicional de criptografía simétrica sobre el mensaje sería innecesaria.

Conclusión

A través de las páginas del presente documento se mostró una visión básica del funcionamiento
de los protocolos SSL/TLS y como hace uso de criptografía asimétrica para el intercambio de llaves de
sesión simétricas que permiten mantener la confidencialidad, integridad y no repudación en una sesión
de comunicación de tipo cliente servidor.

Asi mismo se pudo demostrar con herramientas de captura de paquetes como una vez que se
establece la negociación con el handshake los datos de la conversación viajan ilegibles, cumpliendo así
con el requisito 4 de PCI-DSS sobre transmisión de datos de tarjeta. Incluir una capa interna de criptografía
por parte de los desarrolladores incrementaría el overhead de procesamiento además de la gestión de
llaves adicionales sin otorgar mayor beneficio sobre la confidencialidad que el que ya se estableció al inicio
de la comunicación.

Sobre 1stSecureIT – a GMSecurity Technologies Company

1stSecureIT es una empresa QSA certificada por el PCI Council para llevar a cabo certificaciones
PCI-DSS y PA-DSS. Desde el 2018 pasa a ser una empresa del grupo GMSecurity Technologies con el
objetivo de ofrecer una amplia gama de soluciones de consultoría y servicios administrados de seguridad.
Contamos con una experiencia acumulada de más de 20 años contribuyendo con la ciberseguridad en el
mundo.

Puede visitar nuestras páginas web para conocer más sobre nosotros:

https://www.gmsectec.com/
https://www.1stsecureit.com/

Bibliografía

AGATHOKLIS, P. (2017, March 22). TLS/SSL Explained – Examples of a TLS Vulnerability and Attack, Final
Part. Retrieved from Acunetix: https://www.acunetix.com/blog/articles/tls-vulnerabilitiesattacks-
final-part/

Espana, R. (2016). Rickespana Blog. Retrieved from Rickespana:
Diffie-Hellman for Dummies

Kinsta. (2018, July 19). Kinsta.com. Retrieved from Kinsta: https://kinsta.com/knowledgebase/how-sslworks/

McKinley, H. (2019). Sans. Retrieved from Sans.org: https://www.sans.org/readingroom/
whitepapers/protocols/ssl-tls-beginners-guide-1029