Introducción

Ingresar credenciales de acceso en un formulario de un sitio web es un requisito necesario para utilizar los servicios de una plataforma electrónica, ello implica introducir datos de carácter personal, por lo tanto, esta información se supone que es confidencial, ajena a cualquier agente externo, por lo que, no debería ser conocido por nada o nadie. Los usuarios no sofisticados se preocupan poco por la seguridad de los sitios electrónicos.

Las aplicaciones web implementadas por las instituciones financieras, ya sean estas públicas o privadas, han marcado un antes y un después en la manera tradicional de hacer banca, cada día acrecienta la cantidad de clientes que acceden a este medio electrónico; pero este proceso de modernización genera ciertas interrogantes a los clientes de los servicios de banca online, ¿es confiable este servicio? ¿es segura esta aplicación web?; es aquí cuando aparecen términos conocidos, concernientes a la seguridad como: vulnerabilidades, ataques cibernéticos, hackers, ciberdelincuencia, todos ellos correlacionados de alguna manera.

Los profesionales informáticos y directivos de las entidades financieras constantemente pretenden disminuir las debilidades en el servicio de banca virtual, por ejemplo, se destaca la implementación de varios factores de autenticación, aplicación de seguridad en la capa de transporte (encriptación de la información que transita en el internet, desde el cliente hacia el servidor y viceversa), entre otras. La confidencialidad, integridad y disponibilidad de los datos son características indispensables de la seguridad de la información que un usuario debe recibir en el servicio de estos canales virtuales, de allí que se hace imprescindible el uso de los protocolos de seguridad para acceder a estos portales web.

La Figura 1 muestra un ejemplo de una aplicación de banca virtual, cuya URL utiliza el protocolo HTTPS (Hypertext Transfer Protocol Secure) que es la versión segura del protocolo HTTP, ampliamente utilizado para la transmisión de datos en la web. En este ejemplo, el navegador Mozilla reconoce que esta página web utiliza un certificado digital seguro, la información que transita desde y hacia el servidor viaja cifrada, gracias al uso del protocolos de seguridad TLS (Transport Layer Security), la aplicación de certificados de seguridad, técnicas de encriptación, uso de llaves simétricas y asimétricas, la combinación de suites de cifrados convierten al protocolo HTTP en HTTPS (S de security), evitando que personas mal intencionadas intercepten y utilicen los datos para usos indebidos.

Ante este contexto, el propósito de este trabajo de investigación es evaluar el nivel de seguridad de los certificados digitales en el servicio de banca electrónica, en lo referente al protocolo de seguridad TLS y sus versiones correspondientes, el beneficio que este conlleva, así como, las consecuencias que produciría el no aplicar una configuración adecuada del lado del servidor. También se busca promover a los usuarios no sofisticados la masificación de esta temática, que cada día cobra más valía en el servicio de banca en línea.

Este manuscrito presenta un diagnóstico del uso de las suites de cifrados de varias bancas virtuales del Ecuador, en ciertos casos denotan debilidad o fortaleza en la aplicación de los certificados digitales; además, se presenta el tipo de vulnerabilidades a las cuales son susceptibles o inmunes.

El documento está constituido en varias secciones. La sección I muestra la introducción sobre el entorno del problema, antecedentes y propósito relevante del artículo; además tópicos relacionados a la seguridad en la capa de transporte, las vulnerabilidades más conocidas, recomendaciones de la aplicabilidad de suites de cifrados, para entender con mayor objetividad el tema presentado.

La sección II describe las herramientas y los métodos utilizados para obtener los datos. En la sección III se muestran los resultados del diagnóstico realizado a las entidades financieras mediante el uso de test de certificados digitales en línea. Y, por último, la sección IV concluye este trabajo y discute las direcciones de trabajos futuros.

Secure Sockets Layer

SSL es un protocolo de encriptación que fue concebido para establecer seguridad en las comunicaciones por internet, fue desarrollado originalmente por Netscape, quienes lo introdujeron para su plataforma comercial Netscape Navigator (Ristić, 2014).

SSL v1.0 fue la primera versión del protocolo, pero no salió a producción porque la comunidad criptográfica realizó muchas observaciones, haciendo énfasis en la aplicación de algoritmos criptográficos débiles.

Transport Layers Security

En mayo de 1996, se conformó un grupo de trabajo para migrar SSL de Netscape a IETF (Ristić, 2014). El proceso fue lento debido a las luchas políticas entre Microsoft y Netscape, una consecuencia de la disputa más grande para dominar la Web (Ristić, 2014). TLS 1.0 fue finalmente lanzado en enero de 1999, IETF realizó la publicación formal del protocolo a través del RFC (Request for Comments) 2246 (Dierks & Allen, 1999). Aunque las diferencias con SSL 3 no eran grandes, el nombre fue cambiado para complacer a Microsoft (Ristić, 2014).

TLS v1.2 fue aprobado mediante RFC 5246 en agosto de 2008 (Dierks and Rescorla, n.d.), esta especificación del protocolo, proporciona privacidad e integridad de los datos entre dos aplicaciones que se comunican, el protocolo es compuesto por dos capas: el protocolo de registro TLS y el protocolo de enlace TLS.

El protocolo se define en varias normas por la IETF (The Internet Engineering Task Force (IETF), n.d.) , incluyendo entre otras RFCs 2246, 3546, 4346, 4366, 4680, 4492, 5246, 5288, 5746, 6176 y 6655.

TLS se basa en la tecnología Infraestructura de Clave Pública (PKI), la cual garantiza que el tráfico se envíe al destinatario correcto (Ristić, 2014). Es el protocolo de cifrado más utilizado en Internet, tiene como objetivo garantizar la integridad y confidencialidad del mensaje, el cual transita por la red en la capa de transporte. Permite la comunicación segura de extremo a extremo, evitando la intercepción y alteración de la información.

La Figura 2 muestra la negociación de estos parámetros en un caso genérico. Hace uso de los siguientes intercambios entre el cliente y el servidor.

1. 1. El cliente inicia una consulta enviando un mensaje de tipo ClientHello, que contiene en particular los conjuntos de cifrado que admite.
2. 2. El servidor responde con un ServerHello que contiene la suite retenida.
3. 3. El servidor envía un mensaje de Certificado que, en particular, contiene su clave pública dentro de un certificado digital.
4. 4. El servidor transmite en un ServerKeyExchange un valor efímero que firma usando la clave privada asociada con la clave pública anterior.
5. 5. El servidor manifiesta que está en espera con un ServerHelloDone.
6. 6. Después de la verificación del certificado y la autenticación del valor anterior, el cliente, a su vez, elige un valor efímero que cifra mediante la clave pública del certificado y luego lo transmite en un ClientKeyExchange;
7. 7. El servidor señala que activa la suite completamente con un ChangeCipherSpec.
8. 8. El cliente envía un mensaje (Finished) finalizado, el primer mensaje está protegido de acuerdo con el conjunto de cifrado y los secretos proceden del intercambio de claves efímeras.
9. 9. El servidor señala la activación de la misma suite con un ChangeCipherSpec.
10. 10. El servidor envía a su vez un mensaje (Finished) finalizado, su primer mensaje seguro.

En agosto de 2018 se aprobó definitivamente TLS v1.3 (Rescorla, 2018), luego de 28 revisiones realizadas por el grupo de trabajo de la IETF.

En TLS, toda la seguridad comienza con la identidad de cifrado del servidor. Se necesita una clave privada fuerte para evitar que los ciberdelincuentes lleven a cabo ataques de suplantación. Es primordial tener un certificado válido y fuerte, que otorgue a la clave privada el derecho a representar un nombre de un host en particular. Sin estos dos elementos fundamentales, ninguna otra cosa puede estar segura.

De acuerdo a la información mostrada en el portal SSL Pulse (2019), de 135.254 sitios encuestados en julio de 2023, el 61,9% son denominados sitios seguros, de estas plataformas electrónicas el 63.5% admiten el protocolo TLS v1.3 (+0,5% en comparación con junio de 2023), el 99,9% del total soportan TLS v1.2. En ese mismo contexto, el 38, 1% restante tienen una seguridad inadecuada, del lado del servidor permite el uso de versiones declaradas obsoletas (Dell & Farrell, 2021) TLS v1.1, TLS v1.0 y de esta porción un grupo minoritario 2,1% aún permiten el uso de SSL v3.0 y SSL v2.0 (SSL Pulse, 2019).

Conjunto de cifrados

Es un grupo de algoritmos y reglas utilizadas para cifrar y descifrar información. Están diseñados para garantizar la seguridad y confidencialidad de los datos mediante la transformación de la información en un formato legible con la clave correspondiente.

Con la idea de lograr mejor seguridad a través de la capa de transporte en el modelo TCP IP, estos protocolos ofrecen servicios de autenticación, encriptación, intercambio de claves de cifrado e integridad. Para gestionar cada una de estas características, se puede parametrizar un algoritmo específico en función de las necesidades a nivel de servidor.

La Figura 3 modela un ejemplo de cómo se conforma un Conjunto de Cifrado en el protocolo TLS 1.2.

La Tabla 1 muestra los componentes combinables de los conjuntos de suites de cifrados considerados por IANA (Internet Assigned Numbers Authority) (Rescorla, 2008), exclusivos para el protocolo TLS en su versión 1.2.

En la versión de TLS 1.3 existen diferencias en la estructura del conjunto de cifrado, son más cortos que los respectivos conjuntos TLS 1.2, no hacen referencia al tipo de certificado, y al mecanismo de intercambio de claves, por lo que el número de negociaciones necesarias para determinar los parámetros de cifrado ha disminuido. Los conjuntos de cifrado en TLS 1.3 tienen el siguiente aspecto, según se observa en la Figura 4.

Los esquemas de cifrados con autenticación AE (Auntenthicated Encryption) utilizan un cifrador simétrico (de bloque o de flujo) y un mecanismo MAC. AEAD (Authentication Encryption with Associated Data) que ofrece la capacidad de aplicar el cifrado solo a la autentificación (Centro Criptológico Nacional, 2017).

Los esquemas AE/AEAD autorizados para uso recomendado son según el Centro Criptológico Nacional (2017):

• Cifrador de bloque AES: (EAX, GCM y CCM).

• Cifrador de flujo CHACHA20 :( POLY1305).

En TLS v1.3, los conjuntos basados en cifrado de bloque y cifrado de flujo incluyen: TLS_AEAD_SHA256 y TLS_AEAD_SHA384 (Rescorla, 2018).

La Tabla 2 muestra los conjuntos de suites de cifrados exclusivo para el protocolo TLS en su versión 1.3, considerados por IANA en el RFC8446 apéndice B.4 (Rescorla, 2018).

Debilidades y Amenazas

Las organizaciones y empresas ven como su superficie de ataque aumenta en un panorama de intimidaciones cada vez más hostil. Existen varias amenazas descubiertas desde la invención del protocolo SSL ahora TLS, las que han evolucionado en el tiempo, muchas han sido resueltas con las versiones actualizadas del protocolo. Los ciberdelincuentes actúan aprovechando debilidades técnicas descubiertas.

Las versiones anteriores de TLS 1.2 (incluido las versiones SSL) contienen vulnerabilidades.

Algunas configuraciones del servidor son expuestas a exploits. Ataques como Beast, Crime, Breach, Heartbleed, Poodle, Freak, Logjam son susceptibles a las debilidades presentadas al aplicar configuraciones básicas en los certificados digitales de los servidores web. A continuación se abordaran algunos tipos de posibles ataques a los que son expuestos, sobre todo, las detectadas en el proceso de investigación.

Poodle SSL v3

Poodle posee la capacidad de que un atacante (MITM) pueda bajar la versión actualizada de los navegadores modernos y forzar el uso de SSL3, alterando su versión a una desactualizada en sus conexiones en todo el trayecto hasta que puede ser vulnerada. Hay una solución a este problema, a través del indicador de TLS_FALLBACK_SCSV (Advisory, 2014), este es un mecanismo que resuelve los inconvenientes causados por reintentar conexiones fallidas y, por lo tanto, evita que los ciberdelincuentes induzcan a los navegadores usar SSL 3.0; debe ser implementada en los clientes y del lado del servidor con el fin de ser eficaz.

En un funcionamiento normal, SSL3 no debe ser permitido su uso del lado del servidor. Aunque existe un grupo de clientes que usan Sistemas Operativos desactualizados, ello conlleva a utilizar versiones de navegadores obsoletos, es el caso de Internet Explorer 6 en Windows XP.

La Figura 5 (Statcounter, 2023) muestra que en Ecuador hay un grupo minoritario aproximadamente un 6 % de ordenadores que aún utilizan versiones de Sistemas Operativos Windows (XP, 7, 8, 8.1), respectivamente. A corto plazo, es posible mitigar varias técnicas de ataques en este caso Poodle, evitando el uso de suites con modos de cifrados CBC.

Ataque Freak

La vulnerabilidad Freak (Factoring RSA Export Keys) es posible si el servidor implementa alguno de los cifrados de exportación de claves (Ristić, 2014), un atacante podrá recuperar la clave RSA para luego interceptar la comunicación entre cliente y servidor usando técnicas de tipo MITM (Man in the Middle), y dado que, el atacante es capaz de cifrar y descifrar toda la conversación, el cliente no será advertido en ningún momento, perdiendo la integridad y la confidencialidad de la información.

Para mitigar esta vulnerabilidad, es altamente recomendable Factoring & Export (1990):

• Del lado del servidor: Desactivar el soporte para versiones TLS del tipo EXPORT, desactivar SSL y versiones TLS inferiores a la versión 1.2.

• Los clientes: mantener actualizado los navegadores con la versión más reciente.

Ataque Drown

Básicamente el atacante se aprovecha de que un servidor permita conexiones SSLv2, para capturar las sesiones TLS y descifrar las claves RSA. Se necesitan capturar aproximadamente 1.000 sesiones TLS utilizando intercambios de claves RSA, después hacer unas 40.000 conexiones SSLv2 y realizar 2^50 operaciones de cifrado simétrico, para descifrar 1 sesión TLS (Aviram et al., 2016). Este ataque para ser efectivo requiere de un poco de paciencia, de lograr el objetivo, un atacante puede obtener información valiosa.

Ataque Beast

Las versiones del protocolo criptográfico TLS (v1.1 y v1.2) son inmunes al exploit (Rizzo & Duong, 2011). El ataque extrae pequeñas partes de datos encriptados, trabajo basado en la debilidad previamente conocida en la construcción predecible del vector de inicialización (IV) como se usa en TLS 1.0 (Ristić, 2014). Beast es el primer ataque que realmente desencripta las comunicaciones HTTPS, dado que el resto de amenazas SSL se han basado, por lo general, en el robo de identidad de sitios certificados como seguros.

Ataque Crime

Es otro tipo de ataque a SSL/TLS, a través del cual se podría obtener cookies de sesiones pese a estar realizándose vía HTTPS, mediante el uso de malware JavaScript para extraer las cookies del cliente en un ataque MITM activo (Ristić, 2014). La debilidad que permite descifrar tal información, se da por la compresión, la cual funciona localizando secuencias que se repiten, acortándolas en forma de token. Cuando una cadena de texto contiene otra subcadena que se repite en otro punto del texto, ambas serán sustituidas por el token.

En el caso de enviar una petición por HTTPS, con la compresión DEFLATE activada, todo lo enviado será comprimido y cifrado, tanto las cabeceras como el cuerpo. El problema de la compresión ya es comentado en el RFC 3749 (Transport Layer Security Protocol Compression Methods) (The Internet Engineering Task Force (IETF), 2004), donde en el apartado ‘Security Considerations’ explican que la compresión puede llegar a ser utilizada para deducir el mensaje que había sido cifrado.

Openssl Padding Oracle (CVE-2016-2107)

Es un ataque que utiliza la validación de relleno de un mensaje criptográfico para descifrar el texto cifrado.

En esta vulnerabilidad se determinó que OpenSSL filtraba la información de temporización al descifrar los registros encriptados del protocolo TLS/SSL, cuando la conexión utiliza el conjunto de cifrado AES_CBC y el servidor compatible con AES-NI (OpenSSL, 2016). Un atacante MITM podría usar esta debilidad para recuperar texto sin formato de paquetes cifrados mediante el uso de un servidor TLS/SSL (OpenSSL, 2016).

Paddding Oracle se introdujo como parte de la solución incorrecta del ataque Lucky 13 (CVE-2013-0169) (Blog de Internet Security Auditors: Seguridad SSL/TLS: LUCKY 13, n.d.). La revisión de relleno se reescribió para que se realice en tiempo constante, asegurándose de que siempre se lean los mismos bytes y se comparen con los bytes MAC o los de relleno.

Return Of Bleichenbacher's Oracle Threat (Robot)

Esta vulnerabilidad permite realizar operaciones de descifrado en firma RSA con la clave privada de un servidor TLS. En 1998, Daniel Bleichenbacher (Bleichenbacher, 1998) descubrió que los mensajes de fallos dados en los servidores SSL por errores en el relleno PKCS # 1 v1.5 permitían un ataque de texto cifrado elegido de forma adaptativa; este ataque rompe por completo la confidencialidad de TLS cuando se utiliza con encriptación RSA. Los hosts HTTPS que admiten intercambios de clave de cifrado RSA son vulnerables; un atacante puede registrar pasivamente el tráfico y luego descífralo. Este ataque afecta los modos de cifrado TLS que usan cifrado RSA (Böck et al., 2017). La gran mayoría de las conexiones TLS actuales usan el intercambio de claves Elifftic Curve Diffie Hellman y necesitan RSA solo para firmar. Para las suites de cifrados que no utilizan ECDHE es recomendable mejor deshabilitar los modos de encriptación RSA. Al deshabilitar el cifrado RSA se refiere a todos los cifrados que comienzan con TLS_RSA; se excluye los cifrados que usan TLS_ECDHE_RSA ellos no se ven afectados por Bleichenbacher’s (Böck et al., 2017).

Zombie POODLE y GOLDENDOODLE

Es un exploit de pilas TLS modernas mediante la técnica clásica del oráculo de relleno CBC, descrita por Serge Vaudenay (Vaudenay, 2002); aplicables solo si el servidor usa la versión del protocolo TLS 1.2, TLS 1.1 y TLS 1.0 cuyos conjuntos de cifrados usan el modo de encadenamiento de bloques de cifrado CBC (Sannegowda, 2019).

Estas vulnerabilidades afectan a los servidores que usan el protocolo HTTPS, con modos criptográficos que deberían haber quedado obsoletos, sin embargo, inexplicablemente aún son compatibles con TLSv1.2 (Young, 2019a).

Las debilidades son expuestas por CVE - MITRE (2014). Un servidor configurado con un perfil cliente SSL/TLS puede ser vulnerable a un ataque de texto cifrado elegido contra conjuntos CBC (Cipher Block Chaining). Cuando se explota, puede resultar en la recuperación de texto sin formato de mensajes cifrados a través de un ataque MITM, a pesar de que el atacante no haya obtenido acceso a la clave privada del servidor.

GOLDENDOODLE se puede usar para secuestrar sesiones TLS autenticadas si el servidor revela la validez del relleno de los registros de datos de la aplicación, de tal manera que un atacante MITM pueda reconocer el relleno bien formado independientemente de un Código de Autenticación de Mensaje (MAC) válido (Young, 2019b).

La diferencia entre GOLDENDOODLE y Zombie POODLE o POODLE TLS es el rendimiento (Young, 2019a).

Recomendaciones de aplicación de suites de cifrados

Como se especifica en el RFC 8446 (Rescorla, 2018), se recomienda aplicar y configurar del lado del servidor TLS 1.3 y TLS 1.2. Es suficiente si se requiere la compatibilidad con clientes, cumpliendo con las directivas del servidor, configurando correctamente suites de cifrado sólidas, es importante realizar constantemente auditorías internas mediante sistemas de monitoreo de amenazas. Adicional a ello, se deben deshabilitar las versiones anteriores de TLS 1.2.

Hay varios parámetros obsoletos que deben ser evitados (Ristic, 2017):

• Los conjuntos Diffie-Hellman Anónymos (ADH) no proporcionan autenticación.

• Los conjuntos de cifrado NULL no proporcionan cifrado.

• Evitar el modo de cifrado TLS que usa cifrado RSA (TLS_RSA).

• Exportar conjuntos de cifrado es inseguro cuando se negocian en una conexión.

• Suites débiles (típicamente de 40 y 56 bits) usan cifrado que puede romperse fácilmente.

• RC4 es inseguro.

• 3DES es lento y débil.

• Evitar el uso de OpenSSL en versiones desactualizados.

Desactivar los suites de cifrado que aplican modo CBC en los certificados de seguridad de los servidores, empresas como IBM han encontrado ciertas vulnerabilidades (Merget et al., 2019).

Para la mayoría de los sitios web, la seguridad proporcionada por las claves RSA de 2048 bits es suficiente. En 2048 bits, estas claves proporcionan alrededor de 112 bits de seguridad (Centro Criptográfico Nacional, 2023). Si se desea más seguridad, hay que considerar que las claves RSA no se adaptan muy bien. Para obtener 128 bits de seguridad, es necesario claves RSA 3072 bits, provocando un proceso de cifrado de información más lento.

ECDSA proporcionan una alternativa que ofrece una mayor seguridad y un mejor rendimiento. Las claves ECDSA, en 256 bits, proveen 128 bits de seguridad (Centro Criptográfico Nacional, 2023). Un pequeño número de clientes más antiguos no son compatibles con ECDSA, a diferencia de los clientes modernos. Es posible conseguir lo mejor de ambos mundos y desplegar claves simultáneamente RSA y ECDSA, obviando la sobrecarga de administración de tal configuración.

Otro aspecto fundamental es confiar principalmente en las suites AEAD (en TLS 1.2 son los que usan los algoritmos AES-GCM y ChaCha20-Poly1305), las cuales proporcionan una autenticación fuerte, un intercambio de claves, un secreto avanzado y un cifrado de al menos 128 bits (Centro Criptográfico Nacional, 2023).

Estas especificaciones de cifrado admiten el intercambio de claves de curva elíptica efímera, el cifrado en modo AES-GCM y los algoritmos de integridad de mensajes basados en SHA-256 y SHA-384 (IBM, 2021).

Con base a estas recomendaciones, IETF exhorta a aplicar el uso de los siguientes conjuntos de cifrados del protocolo TLS 1.2 en los servidores como primera opción, (Tabla 3).

Otra recomendación importante para los servidores que utilizan TLS para proteger el tráfico HTTP (es decir, HTTPS) esincluir el uso HSTS (HTTP Strict Transport Security), como se especifica en RFC 6797 (Hodges et al., 2012). Se debe aplicar esta especificación para mitigar muchas vulnerabilidades, de esta forma, se mejora notablemente la seguridad.

Con HSTS habilitado, los navegadores ya no permiten hacer clic en los errores de advertencia del certificado, que normalmente son triviales de explotar. Además, ya no enviarán solicitudes inseguras (texto sin formato), incluso si se les solicita.

HSTS define un mecanismo que permite a los sitios electrónicos declarar accesibles solo a través de conexiones seguras, impide que un atacante convierta una conexión HTTPS en HTTP. El mecanismo instruye al UA (user agent) finalizar la conexión con el servidor de destino, si ocurre algún error mientras intenta establecer comunicación mediante el protocolo (TLS) (Hodges et al., 2012).

La política HSTS define una nueva cabecera HTTP llamada 'Strict-Transport-Security' que puede ser enviada por un servidor web a sus clientes, con el fin de especificar una política con respecto a cómo el navegador va a manejar las conexiones futuras. Además, el host de un recurso web puede declarar que su política se aplica a todo el subárbol de nombres de dominio enraizado en su nombre de host. Esto permite que (HSTS) proteja las llamadas "cookies de dominio", que se aplican a todos los subdominios del nombre de host de un recurso web determinado.

Materiales y Métodos

La investigación adoptó un enfoque cuantitativo y descriptivo, ya que se analizó métricas de seguridad de los certificados digitales en los dominios de las 18 entidades financieras que ofrecen servicios de banca electrónica personas, mediante la herramienta SSL Server Test, obteniendo datos esenciales y categóricos. Se aplicó el enfoque evaluativo, dado que los resultados fueron interpretados para determinar el nivel de seguridad de los sitios electrónicos.

Se evaluó un total de 15 bancos del sector privado y 3 del sector público. La selección de estas entidades se basó en su relevancia y representatividad en el mercado financiero actual.

SSL Server Test

Es una herramienta de test en línea desarrollada por Qualys SSL Labs (Qualys, 2015), un esfuerzo de investigación no comercial, su creador y director es Ivan Ristic. Este instrumento expone la funcionalidad completa del servidor sobre el uso del protocolo SSL/TLS de forma inmediata, permitiendo la evaluación de la configuración del servidor a los administradores de los sitios web, de esta forma se pueden tomar los correctivos necesarios para mejorar la seguridad en la capa de transporte. Incluye un simulador de handshake, el cual realiza simulaciones entre los suites de cifrados soportados, de acuerdo a los protocolos permitidos por la configuración del lado del servidor, corroborando la compatibilidad de los diferentes navegadores con sus respectivas versiones del lado del cliente.

La elección de SSL Server Test se basó en la amplia aceptación de la comunidad de seguridad informática, su capacidad para realizar evaluaciones exhaustivas y detalladas, y su continua actualización de mejores prácticas. Los informes generados por SSLLabs proporcionaron una visión completa de la configuración SSL/TLS de cada sitio, permitiendo identificar fortalezas y debilidades.

Procesamiento de Datos

Los datos recolectados mediante la herramienta SSL Server Test fueron registrados en una hoja de cálculo y procesados utilizando tablas dinámicas, las cuales posibilitaron agrupar y filtrar la información de manera flexible, identificar patrones y tendencias en la configuración de los certificados digitales. Los datos útiles organizados permitieron modelar los resultados de manera gráfica.

Resultados y Discusión

En este trabajo se obtuvieron resultados importantes sobre la aplicación de los certificados digitales en los sitios web de banca electrónica (personas) del país, ello fue posible gracias al uso de la herramienta en línea SSL Server Test.

Para efecto de esta investigación, los bancos ecuatorianos objeto de este estudio se los clasificó de acuerdo a su calificación de riesgo de instituciones financieras, obtenidas en el sitio web de la Superintendencia de Bancos, con corte de septiembre del año 2022 (Superintendencia de Bancos, 2023). Siendo la mejor ponderación “AAA” y la menor “E”.

SSL Server Test de SSLLabs también posee valoraciones de calificación, donde “A+” es la mayor y “F” es la menor para este caso de estudio.

La Tabla 4 muestra las calificaciones obtenidas por los bancos públicos y privadas del sistema financiero del Ecuador, en pocos casos se denotó cierta debilidad en la configuración de los conjuntos de cifrados de sus respectivas plataformas electrónicas.

El 80 % de las bancas virtuales en línea analizadas propiciaron una buena aplicación del uso del certificado de seguridad. Existieron dos entidades bancarias con la mejor calificación de riesgo financiero “AAA”, una de ellas obtuvo calificación “A+” en el test de SSLLabs, como se manifestó anteriormente. Eso significa que posee una buena parametrización en la aplicación del conjunto de cifrados del protocolo TLS del lado del servidor y el restante se adjudicó “A”. Tres entidades crediticias pertenecientes al grupo de riesgo financiero “AAA-” obtuvieron la mejor calificación SSLLabs “A+”, determinando seguridad en su proceso de comunicación cliente/servidor a través de la capa de transporte.

El 20% del total de las plataformas bancarias virtuales que se analizaron obtuviero un grado considerable de vulnerabilidad, esto se debe a la permisibilidad del uso de protocolos TLS/SSL considerados obsoletos, el intercambio de llaves, algoritmos y modos de encriptación débiles.

La Figura 6 muestra las debilidades que presentaron las entidades financieras en la aplicación de suites de cifrados en las respectivas configuraciones de los servidores. En algunos casos no soportaron el protocolo TLS en sus versiones 1.3 (actual) y 1.2 (versión aún. segura), muchos no aplican la política de HSTS, varios no soportan Forward Secrecy, otros usan conjuntos de cifrados con el modo CBC, Renegociación Segura, otras develaciones importantes, varias entidades permitieron el uso de OpenSSL, Diffie Helman y DH_anon, además soportaron el cifrado RC4.

La Figura 7 devela los ataques a los que fueron susceptibles ciertas entidades financieras ecuatorianas, que aplican débiles configuraciones en las suites de cifrados del lado del servidor. Ello es mucho más permisible cuando se utilizan sistemas operativos o navegadores web obsoletos, los que se muestran vulnerables ante cualquier amenaza de ataque, orquestado por algún ciberdelincuente u organización delictiva.

Algo interesante es que no necesariamente la calificación financiera del banco tiende a estar relacionada con la calificación de la evaluación SSL/TLS. Es así que, de las entidades con calificación AAA-, la segunda mejor del grupo analizado, se encontraron casos con la mejor y la peor evaluación de seguridad.

Conclusiones

Se concluye que el 80% de las entidades financieras objetos de esta investigación se muestran seguras en sus respectivas plataformas de banca electrónica personas, gracias a las configuraciones de fuertes conjuntos de cifrados del lado del servidor.

De acuerdo a la información obtenida en esta investigación, se determinó que existe cierta debilidad en la aplicabilidad de los certificados digitales del lado del servidor en varias de las entidades financieras del Ecuador. El 20% de las plataformas de banca virtual (personas), posee vulnerabilidades, es decir, que son propensos a sufrir ataques cibernéticos, a causa de las configuraciones débiles existentes en las suites de cifrados implementados.

El análisis de los datos obtenidos afirma que existen un grupo minúsculo de personas en el Ecuador que hacen uso de sistemas operativos y navegadores obsoletos, a ello, se suma que ciertas entidades financieras permiten el acceso a las plataformas de banca personas con estas herramientas desactualizadas por la aplicación de suites de cifrados débiles, lo cual, se convierte en una amenaza por parte de los ciberdelincuentes.

En el contexto de los servicios de banca electrónica, la seguridad en la capa de transporte es un pilar fundamental para proteger la confidencialidad, integridad y disponibilidad de las transacciones financieras. Por ello, es necesario la implementación de protocolos criptográficos robustos, mecanismos de autenticación multifactor y sistemas de detección de intrusos. La combinación de estos mecanismos de seguridad informática es esencial para mitigar las amenazas cibernéticas y garantizar la confianza de los clientes. Además, es crucial realizar evaluaciones de vulnerabilidad periódicas y mantener los sistemas actualizados para responder de manera proactiva a la evolución del panorama de amenazas en la red informática más insegura conocida como internet.

Sería importante complementar este estudio con un trabajo futuro, para analizar la seguridad en el proceso de autenticación, en las aplicaciones en los canales electrónicos de banca personas de las entidades financieras del país. Otra investigación podría ir enfocada a las políticas de seguridad que aplican estas entidades.

Reconocimientos

Los autores declaran la contribución y participación equitativa de roles de autoría para esta publicación.

Referencias

Advisory, S. (2014). This POODLE Bites : Exploiting The. Google Security Blog. https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderman, J. A., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., & Shavitt, Y. (2016). Drown: Breaking TLS using SSLv2. Proceedings of the 25th USENIX Security Symposium, 689–706. https://drownattack.com/drown-attack-paper.pdf

Bleichenbacher, D. (1998). A Chosen Ciphertext Attack against Protocols based on the RSA Encryption Standard PKCS \textsf\symbol351. Proc. of Crypto ’98, 1462, 1–12.

Blog de Internet Security Auditors: Seguridad SSL/TLS: LUCKY 13. (n.d.). Retrieved January 7, 2024, from https://blog.isecauditors.com/2020/04/seguridad-ssl-tls-lucky13.html

Böck, H., Somorovsky, J., & Young, C. (2017). Return Of Bleichenbacher’s Oracle Threat (ROBOT). Cryptology EPrint Archive.

Centro Criptográfico Nacional. (2023). Guía de Seguridad de las TIC CCN-STIC 221 Guía de Mecanismos Criptográficos autorizados por el CCN. https://www.ccn-cert.cni.es/es/guias-de-acceso-publico-ccn-stic/6954-ccn-stic-221-guia-de-mecanismos-criptograficos-autorizados-por-el-ccn-1/file.html

Centro Criptológico Nacional. (2017). Guía de Seguridad de las TIC CCN-STIC 811. Interconexión en el ENS. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/521-ccn-stic-811-interconexion-en-el-ens/file?format=html

Cisco. (2017). SSL Introduction with Sample Transaction and Packet Exchange - Cisco. 1–8. https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-socket-layer-ssl/116181-technote-product-00.html#anc6

CVE - MITRE. (2014). CVE Record | CVE. CVE - MITRE. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6593

Dell, K. M., & Farrell, E. S. (2021). RFC 8996 Deprecating TLS 1.0 and TLS 1.1. Internet Engineering Task Force, 3329, 8422. https://www.rfc-editor.org/info/rfc8996

Dierks, T., & Allen, C. (1999). The TLS Protocol Version 1.0 (Issue 2246). https://www.ietf.org/rfc/rfc2246.txt

Dierks T. and Rescorla E. (n.d.). The Transport Layer Security (TLS) Protocol Version 1.2 [RFC 5246]. Retrieved May 10, 2022, from https://www.rfc-editor.org/rfc/pdfrfc/rfc5246.txt.pdf

Factoring, F., & Export, R. S. A. (1990). Vulnerabilidad Freak de SSL. https://www.ecucert.gob.ec/wp-content/uploads/2021/07/Ficha-Tecnica-Freak-SSL.pdf

Hodges, J., Jackson, C., & Barth, A. (2012). HTTP Strict Transport Security (HSTS). In IETF - Internet Engineering Task Force. https://doi.org/10.17487/rfc6797

IBM. (2021). Cipher suite considerations when upgrading to TLS V1.2 - IBM Documentation. https://www.ibm.com/docs/en/zos/2.4.0?topic=protocols-cipher-suite-considerations-when-upgrading-tls-v12

Merget, R., Somorovsky, J., Aviram, N., Young, C., Fliegenschmidt, J., Schwenk, J., & Shavitt, Y. (2019). Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities. USENIX Security Symposium.

OpenSSL. (2016). Memory corruption in the ASN.1 encoder (CVE-2016-2108). https://www.openssl.org/news/secadv/20160503.txt

Qualys, I. (2015). SSL Server Test. Projects. https://www.ssllabs.com/ssltest/

Rescorla, E. (2008). [ECC] TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) [RFC 5289]. RFC 5289, 1–6. https://datatracker.ietf.org/doc/html/rfc5289

Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3 [RFC 8446]. https://doi.org/https://doi.org/10.17487/rfc8446

Ristic, I. (2017). SSL and TLS Deployment Best Practices. Wiki, 4(December), 1–14. https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Ristić, I. (2014). Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications (Feisty Duck Limited (Ed.); Vol. 2015, Issue build 592). https://www.feistyduck.com/books/bulletproof-tls-and-pki/bulletproof-tls-and-pki-2ed-sample.pdf

Rizzo, J., & Duong, T. (2011). The Beauty (RC4) and The BEAST (TLS) – HACKMAGEDDON. Hakmagenon. https://www.hackmageddon.com/2011/09/25/the-beauty-rc4-and-the-beast-tls/

Sannegowda, Y. (2019). Zombie POODLE and GOLDENDOODLE Vulnerabilities | Qualys Security Blog. https://blog.qualys.com/product-tech/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities

Sheffer, Y., Saint-Andre, P., & Fossati, T. (2022, November). Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). https://doi.org/10.17487/RFC9325

SSL Pulse. (2019). Qualys SSL Labs - SSL Pulse. SSL Pulse. https://www.ssllabs.com/ssl-pulse/

Statcounter. (2023). Desktop Windows Version Market Share Ecuador | Statcounter Global Stats. In Statcounter Global Stats. https://gs.statcounter.com/windows-version-market-share/desktop/ecuador/#monthly-202209-202309-bar

SUPERINTENDENCIA DE BANCOS. (2023). Calificación de Riesgo Instituciones Financieras. Web Page. https://www.superbancos.gob.ec/bancos/calificacion-de-riesgo-instituciones-financieras-2022/

The Internet Engineering Task Force (IETF). (n.d.). Introduction to the IETF. Retrieved January 5, 2024, from https://www.ietf.org/about/introduction/

The Internet Engineering Task Force (IETF). (2004). RFC 3749 - TLS Compression Methods. https://www.rfc-editor.org/rfc/pdfrfc/rfc3749.txt.pdf

Vaudenay, S. (2002). Security flaws induced by cbc padding – Applications to SSL, IPSEC, WTLS. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2332, 534–545. https://doi.org/https://doi.org/10.1007/3-540-46035-7_35

Young, C. (2019a). Introducing Zombie POODLE and GOLDENDOODLE. Tripwire. https://www.tripwire.com/state-of-security/zombie-poodle-goldendoodle

Young, C. (2019b). “TripWire Vert, What is GOLDENDOODLE Attack?”https://www.tripwire.com/state-of-security/goldendoodle-attack