1222

https://doi.org/10.37815/rte.v36n2.1222

Artículos originales

Evaluación de la Seguridad de Certificados Digitales en las Plataf= ormas Financieras de Ecuador

Assessment of the Security of Digital Certificates in the Financial Platforms in Ecuador

David Peñarrieta¹ ^{https://orcid.org/0009-0003-4888-0000}= ,

Marlon Navia²⁼^{https://orcid.org/0000-0001-9775-37=
78}, Eliana Garc= ía²^{https://orcid.org/0009-0002-0857-89=
77}, Dannyll Zambrano²^{https://orcid.org/0000-0003-4413-44=
25}

¹Gob= ierno Autónomo Descentralizado Municipal de Junín, Junín, Ecuador<= o:p>

d.penarrieta@junin.gob.ec

²Uni= versidad Técnica de Manabí, Portoviejo, Ecuador

marlon.navia@utm.edu.ec, eliana.garcia@utm.edu.ec, michellc.zambrano@utm.edu.ec

Enviado: 2024/07/24<= span style=3D'font-size:10.0pt;font-family:"Segoe UI",sans-serif;mso-ansi-langua= ge: ES-MX'>

Aceptado: 2024/12/24

Publicado: 2024/12/30 =

Resumen

Sumario: Introducción, Materiales y Métodos, Resultados y Discusión, Conclusiones.

= ;

Como citar= : Peñarrieta, D., Navia, M., García, E. & Zambrano, D. (2024). Evaluación de la Seguridad de Certificados Digitales en las Plataformas Financieras de Ecuador. Revista Tecnológica - Espol, 36(2), 174-189. <= span lang=3DES-EC>https://rte.espol.edu.ec/index.php/tecnologica/article/view/1222=

Este art= ículo muestra un diagnóstico de la aplicación de los certificados digitales en = los servicios de banca virtual del Ecuador. La importancia de esta temática se fundamenta en los crecientes ataques a los servicios electrónicos de plataformas financieras en la región y el mundo, a causa de la explotació= n de vulnerabilidades descubiertas por ciberdelincuentes, en la frágil aplicaci= ón de los conjunto de cifrados. El objetivo de la investigación es mostrar el ni= vel de seguridad que poseen estos portales de banca online (personas), en la aplicabilidad de los protocolos SSL/TLS, con sus respectivos suites de cifr= ados del lado del servidor. Para ello, se analizaron 18 entidades financieras, mediante la herramienta en línea SSL server Test de Q= ualys SSLLabs. Se encontró que el 20% de las entidad= es bancarias analizadas presentan debilidad en la aplicabilidad de los certificados digitales, lo que podría ocasionar ataques informáticos a di= chas plataformas virtuales, durante el proceso de comunicación entre cliente/se= rvidor a través del servicio de internet. La confidencialidad, integridad y disponibilidad de los datos son características indispensables de la segur= idad de la información que un usuario debe recibir en el servicio de banca virt= ual personas. Como aporte adicional de este trabajo, se realiza una revisión d= e las recomendaciones de uso de certificados digitales de acuerdo con las regulaciones que emite la IETF a través de los respectivos RFC.

= Palabras clav= e: Ataques, banca electrónica, conjunto de cif= rado, SSL, TLS, vulnerabilidades.

Abstract

This article presents a diagno= sis of the application of digital certificates in the virtual banking services = of Ecuador. The importance of this topic is based on the increasing attacks on electron= ic services of financial platforms in the region and the world, due to the exploitation of vulnerabilities discovered by cybercriminals in the weak application of cipher suites. The objective of the research is to show the level of security of these online banking portals (individuals), in the applicability of SSL/TLS protocols, with their respective cipher suites on = the server side. Eighteen financial entities were analyzed using the online tool SSL Server Test by Qualys SSL Labs. It was found that 20% of the analyzed banking entities show weaknesses in the applicability of digital certificat= es, which could lead to cyberattacks on these virtual platforms during the clie= nt/server communication process over the internet. Confidentiality, integrity, and availability of data are indispensable characteristics of information secur= ity that a user should receive in the virtual banking service. Additionally, th= is work reviews the recommendations for the use of digital certificates accord= ing to the regulations issued by the IETF through the respective RFCs.

Keywords: Attacks, Electronic Banking, Cipher Suite, SSL, TLS, Vulnerabilities.

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 p= or 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 acre= cienta la cantidad de clientes que acceden a este medio electrónico; pero este pr= oceso de modernización genera ciertas interrogantes a los clientes de los servic= ios 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 d= irectivos de las entidades financieras constantemente pretenden disminuir las debilid= ades 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 servido= r y viceversa), entre otras. La confidencialidad, integridad y disponibilidad de los datos son características indispensables de la seguridad de la informa= ción que un usuario debe recibir en el servicio de estos canales virtuales, de a= llí que se hace imprescindible el uso de los protocolos de seguridad para acced= er 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 (Transp= ort Layer Security), la aplicación de certificados= de seguridad, técnicas de encriptación, uso de llaves simétricas y asimétr= icas, 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.

Figura = 1=

Conexión segura de un sitio web,= a través de un dominio con https

Ante este contexto, el propósito d= e este trabajo de investigación es evaluar el nivel de seguridad de los certifica= dos digitales en el servicio de banca electrónica, en lo referente al protocol= o de seguridad TLS y sus versiones correspondientes, el beneficio que este conll= eva, 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 v= alí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 v= arias secciones. La sección I muestra la introducción sobre el entorno del prob= lema, antecedentes y propósito relevante del artículo; además tópicos relacio= nados 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 herrami= entas y los métodos utilizados para obtener los datos. En la sección III se muest= ran los resultados del diagnóstico realizado a las entidades financieras media= nte el uso de test de certificados digitales en línea. Y, por último, la secc= ió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<= /span> Layers Security

En mayo de 1996, se conformó un gr= upo 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 (<= span class=3DSpellE>Ristić, 2014). TLS 1.0 fue finalmente lanzado en ene= ro 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 no= mbre 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 no= rmas por la IETF (The Internet Engineering Task Force (IETF), n.d.)= , incluyendo entre otras RFCs 2246, 3546, 4346, 4= 366, 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 segu= ra 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.

Figura = 2=

Transacción e intercambio de paq= uetes entre cliente/servidor, mediante SSL (Cisco, 2017)

1. &n= bsp; El cliente inicia una con= sulta enviando un mensaje de tipo ClientHello,= que contiene en particular los conjuntos de cifrado que admite.

2. &n= bsp; El servidor responde con = un ServerHello que contiene la suite retenida.

3. &n= bsp; El servidor envía un men= saje de Certificado que, en particular, contiene su clave pública dentro de un certificado digital.

4. &n= bsp; El servidor transmite en = un ServerKeyExchange un valor efímero que firma = usando la clave privada asociada con la clave pública anterior.

5. &n= bsp; El servidor manifiesta qu= e está en espera con un ServerHelloDone.=

6. &n= bsp; Después de la verificaci= ón del certificado y la autenticación del valor anterior, el cliente, a su vez, e= lige un valor efímero que cifra mediante la clave pública del certificado y lu= ego lo transmite en un ClientKeyExchange;

7. &n= bsp; El servidor señala que a= ctiva la suite completamente con un ChangeCipherSpec<= /span>.

8. &n= bsp; El cliente envía un mens= aje (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. &n= bsp; El servidor señala la activación de la misma suite con un ChangeCipherSp= ec.

10. El servidor envía a su vez un mensaje (<= i>Finished) finalizado, su primer mensaje seguro.

En agosto de 2018 se aprobó defini= tivamente TLS v1.3 (Rescorla, 2018), luego de 28 revision= es 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 pr= ivada 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 mostra= da en el portal SSL Pulse (2019), de 135.2= 54 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 202= 3), el 99,9% del total soportan TLS v1.2. En ese mismo contexto, el 38, 1% rest= ante tienen una seguridad inadecuada, del lado del servidor permite el uso de ve= rsiones declaradas obsoletas (Dell & Farrell, 2021) TLS v1.1, TLS v1.0 y de est= a 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 gar= antizar 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 segurid= ad a través de la capa de transporte en el modelo TCP IP, estos protocolos ofre= cen servicios de autenticación, encriptación, intercambio de claves de cifrad= o e integridad. Para gestionar cada una de estas características, se puede parametrizar un algoritmo específico en función de las necesidades a nive= l de servidor.

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

Figura = 3=

Componentes de un Conjunto de Cif= rados 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, 200= 8), exclusivos para el protocolo TLS en su versión 1.2.

Tabla <= /span>1=

Posibles valores combinables en l= os Conjunto de Cifrados TLS 1.2 (Rescorla, 2008)

Componente	Valores posib= les
Protocolo	TLS
Intercambio de cla= ves	ECDH, ECDHE
Autenticación	ECDSA, RSA
Algoritmo de cifra= do	AES
Longitud de clave<= o:p>	128, 256=
Modo de cifrado	CBC, GCM
Algoritmo de Hash<= o:p>	SHA256, SHA38= 4

En la versión de TLS 1.3 existen diferencias en la estructura del conjunto de cifrado, son más cortos que l= os 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 obse= rva en la Figura 4.

Figura = 4=

Componentes de un conjunto= de cifrados TLS v1.3

Los esquemas de cifrados con autent= icación AE (Auntenthicated Encrypt= ion) utilizan un cifrador simétrico (de bloque o de flujo) y un mecanismo MAC. AEAD (Authen= tication 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 pa= ra uso recomendado son según el Centro Criptológico Nacional (2017):

·&n= bsp; Cifrador de bloque AES: (= EAX, GCM y CCM).

·&n= bsp; Cifrador de flujo CHACHA2= 0 :( 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).

Tabla <= /span>2=

Conjuntos de cifrados para TLS 1.= 3 - Consideraciones IANA (Rescorla, 2018)

Conjunto de Cifrados TLS 1.3
Descripción	Valor
TLS_AES_128_GCM_SHA256	{0x13,0x01}
TLS_AES_256_GCM_SHA384	{0x13,0x02}
TLS_CHACHA20_POLY1305_SHA256	{0x13,0x03}
TLS_AES_128_CCM_SHA256	{0x13,0x04}
TLS_AES_128_CCM_8_SHA256	{0x13,0x05}

<= o:p>

Debilidades y Amenazas

Las organizaciones y empresas ven c= omo su superficie de ataque aumenta en un panorama de intimidaciones cada vez más hostil. Existen varias amenazas descubiertas desde la invención del protoc= olo SSL ahora TLS, las que han evoluc= ionado en el tiempo, muchas han sido res= ueltas 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 Be= ast, Crime, Breach, Hear= tbleed, Poodle, Freak, Logjam son susceptibles a las debilidades presentadas al aplicar configuraciones bási= cas en los certificados digitales de los servidores web. A continuación se abordaran algunos tipos de posibl= es ataques a los que son expuestos, sobre todo, las detectadas en el proceso de investigación.

Poodle SSL v3

Poodle<= /span> posee la capacidad = de que un atacante (MITM) pueda bajar la versión actualizada de los navegadores mode= rnos 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 soluc= ió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 n= o debe ser permitido su uso del lado del servidor. Aunque existe un grupo de clien= tes 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 ver= siones de Sistemas Operativos Windows (XP, 7, 8, 8.1), respectivamente. A corto pl= azo, es posible mitigar varias técnicas de ataques en este caso Poodle, evitando el uso de suites con modos de cifrados CBC.

Figura = 5=

Uso de SO. Microsoft Desktop en Ecuador, período (septiembre 2022- septiembre 2023)

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ć, 20= 14), 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 confidenci= alidad de la información.

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

·&n= bsp; 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.

·&n= bsp; Los clientes: mantener actualizado los navegadores con la versión más reciente.

Ataque Drow= n

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

Ataque Beas= t

Las versiones del protocolo criptog= rá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 Crim= e

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 subcad= ena que se repite en otro punto del texto, ambas serán sustituidas por el toke= n.

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

Openssl Padding Oracle (CVE-2016-2107)

Es un ataque que utiliza la validac= ió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 registr= os 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 Securit= y Auditors: Seguridad SSL/TLS: LUCKY 13, n.d.). La revisión de relleno se reescribió para qu= e 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)<= /o:p>

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 mensa= jes 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 ata= que rompe por completo la confidencialidad de TLS cuando se utiliza con encriptación RSA. Los hosts HTTPS que admiten intercambios de clave de cif= rado RSA son vulnerables; un atacante = puede registrar pasivamente el tráfico y luego descífralo. Este ataque afecta l= os modos de cifrado TLS que usan cifrado RSA (Böck et al., 2017). La gran mayoría de las conexiones TLS actuales usan el interca= mbio de claves Elifftic Curve D= iffie 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<= /span> de pilas TLS modernas mediante la técnica clásica del oráculo de relleno CB= C, 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 obso= letos, sin embargo, inexplicablemente aún son compatibles con TLSv1.2 (Young, 201= 9a).

Las debilidades son expuestas por C= VE - MITRE (2014). Un servidor configurado con un perfil cliente SSL/TLS puede s= er 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 ata= que MITM, a pesar de que el atacante no haya obtenido acceso a la clave privada= del servidor.

GOLDENDOODLE se puede usar para sec= uestrar sesiones TLS autenticadas si el servidor revela la validez del relleno de l= os registros de datos de la aplicación, de tal manera que un atacante MITM pu= eda 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 suit= es de cifrados

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

Hay varios parámetros obsoletos qu= e deben ser evitados (Ristic, 2017):

·&n= bsp; Los conjuntos Diffie-Hellman Anónymos = (ADH) no proporcionan autenticación.

·&n= bsp; Los conjuntos de cifrado = NULL no proporcionan cifrado.

·&n= bsp; Evitar el modo de cifrado= TLS que usa cifrado RSA (TLS_RSA).

·&n= bsp; Exportar conjuntos de cif= rado es inseguro cuando se negocian en una conexión.

·&n= bsp; Suites débiles (típicam= ente de 40 y 56 bits) usan cifrado que puede romperse fácilmente.

·&n= bsp; RC4 es inseguro.

·&n= bsp; 3DES es lento y débil.

·&n= bsp; 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, empres= as como IBM han encontrado ciertas vulnerabilidades (Merg= et et al., 2019).

Para la mayoría de los sitios web,= la seguridad proporcionada por las claves RSA de 2048 bits es suficiente. En 2= 048 bits, estas claves proporcionan alrededor de 112 bits de seguridad (Centro Criptográfico Nacional, 2023). Si se desea más seguridad, hay que conside= rar que las claves RSA no se adaptan muy bien. Para obtener 128 bits de segurid= ad, 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 mej= or 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 A= EAD (en TLS 1.2 son los que usan los algoritmos AES-GCM y ChaCha20-Poly1305), las cuales proporcionan una autentica= ción fuerte, un intercambio de claves, un secreto avanzado y un cifrado de al me= nos 128 bits (Centro Criptográfico Nacional, 2023).

Estas especificaciones de cifrado a= dmiten el intercambio de claves de curva elíptica efímera, el cifrado en modo AE= S-GCM y los algoritmos de integridad de mensajes basados en SHA-256 y SHA-384 (IB= M, 2021).

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

Tabla <= /span>3=

Conjunto de Cifrados TLS 1.2 (Recomendación) (Sheffer et al., 2022)<= /p>

Recomendación - Conjunto de Cifrados TLS 1.2

Descripción

Valor

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

=3D{}0xC0,0x2B;

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

=3D{}0xC0,0x2C;

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

=3D{}0xC0,0x2F;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

=3D{}0xC0,0x30;

<= o:p>

Otra recomendación importante para los servidores que uti= lizan TLS para proteger el tráfico HTTP (es decir, HTTPS) e= sincluir el uso HSTS (HTTP Strict T= ransport 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 mej= ora notablemente la seguridad.

Con HSTS habilitado, los navegadore= s 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 permit= e a los sitios electrónicos declarar accesibles solo a través de conexiones segur= as, 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., 201= 2).

La política HSTS define una nueva = cabecera HTTP llamada 'Strict-Trans= port-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 S= SL Server Test, obteniendo datos ese= nciales y categóricos. Se aplicó el enfoque evaluativo, dado que los resultados f= ueron interpretados para determinar el nivel de seguridad de los sitios electrón= icos.

Se evaluó un total de 15 bancos de= l 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 handsha= ke, el cual realiza simulaciones entre los suites de cifrados soportados, de acuerdo a los protocolos permitidos por la configuración del lado del serv= idor, 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 capacid= ad 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 Dis= cusión

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

Para efecto de esta investigación, los bancos ecuatorianos objeto de este estud= io 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). Siend= o la mejor ponderación “AAA” y la menor “E”.

SSL Server Test de SSLLabs también posee valoracio= nes de calificación, donde “A+” es la mayor y “F” es la menor para este c= aso de estudio.

Tabla 4=

Calificación SSLLabs obtenida en el estudio realizado a los servicios de banca online

Clasificación de Riesgo Financiero	Calificación SSLLabs	Total
F=	C=	B=	A=	A+<= /span>
-A		1=			1	2
AA=				1		1
AA+			1=		3	4
AAA-	1		1	4	3	9
AAA				1=	1	2
Total=	1	1	2	6	8	18

La Tabla 4 muestra las calific= aciones 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.<= /span>

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 parametrizac= ió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 se= guridad en su proceso de comunicación cliente/servidor a través de la capa de transp= orte.

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

Figura 6=

Debilidades en la aplicación de suite de cifrados de las diferentes bancas en línea

La Figura 6<= /span> muestra las debilid= ades que presentaron las entidades financieras en la aplicación de suites de cifrad= os 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<= span style=3D'mso-spacerun:yes'> DH_anon, a= demás soportaron el cifrado RC4.

La Figura 7<= /span> 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 cua= ndo se utilizan sistemas operativos o navegadores web obsoletos, los que se muestr= an vulnerables ante cualquier amenaza de ataque, orquestado por algún ciberdelincuente u organización delictiva.

Figura 7=

Ataque a los que están expuestos las plataformas financieras virtuales ecuatorian= os

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 segur= idad.

Conclusiones

Se concluye qu= e el 80% de las entidades financieras objetos de esta investigación se muestran seg= uras 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 cier= ta 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 d= e los datos obtenidos afirma que existen un grupo minúsculo de personas en el Ec= uador que hacen uso de sistemas operativos y navegadores obsoletos, a ello, se su= ma que ciertas entidades financieras permiten el acceso a las plataformas de b= anca personas con estas herramientas desactualizadas por la aplicación de suite= s 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 detecc= ión de intrusos. La combinación de estos mecanismos de seguridad informática es<= span style=3D'mso-spacerun:yes'> 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 panoram= a de amenazas en la red informática más insegura conocida como internet.<= /o:p>

Sería importa= nte complementar este estudio con un trabajo futuro, para analizar la seguridad= en el proceso de autenticación, en las aplicaciones en los canales electróni= cos 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 de= claran la contribución y participación equitativa de roles de autoría para esta publicación.

Referencias

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

Aviram, N., Schinzel, S., Som= orovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderma= n, J. A., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., & Shavitt, Y. (20= 16). 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<= span lang=3DES-EC style=3D'font-size:10.0pt;line-height:90%'> 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-st= ic-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 8= 11. 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=3Dhtml=

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=3DCVE-2019-6593<= /o:p>

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 Frea= k de SSL. https://www.ecucert.gob.ec/wp-content/uploads/2021/07/Ficha-Tecnica-Freak-S= SL.pdf

Hodges, J., Jackson, C., & Barth, A. (2012). H= TTP Strict Transport Security (HSTS). In IETF - Internet Engineering Task Fo= rce. 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=3Dprotocols-cipher-suite-consid= erations-when-upgrading-tls-v12

Merget, R., Somorovsky= , J., Aviram, N., Young, C., Fliegenschmidt, J., Schw= enk, 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.t= xt

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

Rescorla, E. (2008). [ECC] TLS Elliptic Curve Ciph= er 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 Securi= ty (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-Practi= ces

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-an= d-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 Secur= ity Blog. https://blog.qualys.com/product-tech/2019/04/22/zombie-poodle-and-goldendoo= dle-vulnerabilities

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

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

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

SUPERINTENDENCIA DE BANCOS. (2023). Calificación de Riesgo Instituciones Financieras= . Web Page. https://www.superbancos.gob.ec/bancos/calificacion-de-riesgo-instituc= iones-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 paddin= g – Applications to SSL, IPSEC, WTLS. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture N= otes in Bioinformatics), 2332, 534–545. https://doi.org/https://doi.org/10.1007/3-540-46035-7_35<= /p>
Young, C. (2019a). Introducing Zombie POODLE and GOLDENDOODLE. Tripwire. https://www.tripwire.com/state-of-security/zombie-poodle-goldendoodle<= /o:p>

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

=

Recomendación - Conjunto de Cifrados TLS 1.2
Descripción	Valor
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	=3D{}0xC0,0x2B;
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	=3D{}0xC0,0x2C;
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	=3D{}0xC0,0x2F;
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	=3D{}0xC0,0x30;