Conjunto de cifrados
Un conjunto de cifrados,[1] una suite de cifrado[2] o una suite criptográfica[3] (en inglés: cipher suite) es un conjunto de algoritmos que permiten cifrar una conexión de red.
Los conjuntos de cifrados utilizan generalmente el protocolo de comunicación Transport Layer Security (TLS) o su predecesor obsoleto Secure Socket Layer (SSL), y suelen estar compuestos por un algoritmo de intercambio de claves, un algoritmo de cifrado masivo y un algoritmo de código de autenticación de mensaje (MAC).[4] El algoritmo de intercambio de claves se emplea para intercambiar una clave entre dos dispositivos. Esta clave se utiliza para cifrar y descifrar los mensajes que se envían entre dos máquinas. El algoritmo de cifrado masivo se utiliza para cifrar los datos que se envían. El algoritmo de MAC proporciona comprobaciones de integridad de los datos para asegurar que estos permanecen inalterados en tránsito. Además de estos, una suite criptográfica puede incluir firmas y un algoritmo de autenticación para facilitar la autenticación del servidor o del cliente.
Existen cientos de suites de cifrado que a su vez contienen distintas combinaciones de estos algoritmos. Algunas suites ofrecen mejor seguridad que otras. Sin embargo, con la adopción de TLS 1.3, solo cinco suites cuentan con soporte y definición oficial.[5]
La estructura y el uso del conjunto de cifrados están definidos en el documento de especificación de TLS.[6] TLS 1.2 es la versión más extendida de TLS. La última versión, TLS 1.3, incluye requisitos adicionales a los conjuntos de cifrados. Los conjuntos definidos para TLS 1.2 no se pueden utilizar en TLS 1.3 y viceversa, salvo que se especifique lo contrario en su definición. El Registro de Conjuntos de Cifrados de TLS (TLS Cipher Suite Registry) proporciona una lista de referencia de conjuntos de cifrado.[7]
Historia[editar]
El uso de cifrados ha formado parte del protocolo Secure Socket Layer (SSL) desde su creación. SSL ha sido sustituido en gran medida por TLS. Sin embargo, el nombre cipher suite no se utilizó en el esbozo original de SSL. En lugar de eso, la capacidad de un cliente y de un servidor de escoger entre un pequeño conjunto de algoritmos de cifrado se denominó cipher choice («elección de cifrados»).[8][9] No fue hasta el lanzamiento de SSL v3, la última versión de SSL, que se empezó a usar la denominación cipher suite.[10] Desde entonces, todas las versiones de TLS han empleado este nombre en su estandarización. El concepto y propósito de una suite de cifrado no ha cambiado desde que se acuñó el término. Se utilizó, y se sigue utilizando, como una estructura que describe los algoritmos para los que una máquina tiene soporte de forma que dos máquinas puedan acordar qué algoritmos utilizar para asegurar su conexión. Lo que sí ha cambiado son las versiones de los algoritmos con soporte en los conjuntos de cifrados. Cada nueva versión de TLS ha añadido soporte para las versiones más robustas de los algoritmos y ha dejado de dar soporte a las versiones que se han identificado como inseguras.
TLS 1.3 establece un cambio en la manera en que las suites de cifrado se coordinan entre máquinas. La suite de cifrado escogida para que dos máquinas se comuniquen se determina en el proceso de establecimiento de comunicación (handshake). Se hicieron cambios en TLS 1.3 para reducir el número de mensajes que deben enviarse en el proceso, lo que permite reducir el procesado y el tráfico de paquetes y aumentar la eficiencia respecto de versiones anteriores de TLS.
Nomenclatura[editar]
Cada conjunto de cifrados tiene un nombre único que se emplea para identificarlo y para describir sus contenidos algorítmicos. Cada uno de los segmentos de un conjunto de cifrados se refiere a un algoritmo o protocolo.
Un ejemplo es el nombre TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, cuyo significado se detalla a continuación:
- TLS define el protocolo para el que está destinado este conjunto de cifrados, que normalmente será TLS;
- ECDHE indica el algoritmo de intercambio de claves;
- RSA indica el método de autenticación empleado en el establecimiento de comunicación;
- AES es el cifrado de sesión;
- 128 es el tamaño (en bits) de la clave de cifrado de sesión;
- GCM indica el tipo de cifrado (dependencia de bloques de cifrado y opciones adicionales);
- SHA es el código de autenticación de mensaje (MAC);
- 256 es el tamaño (en bits) del digesto o hash.
Coordinación de conjuntos de cifrados[editar]
Para poder usar un conjunto de cifrados, el cliente y el servidor deben ponerse de acuerdo en el conjunto específico de cifrados que se va a usar en el intercambio de mensajes. Tanto el cliente como el servidor tienen que poder usar el conjunto acordado. Si el cliente y el servidor no se ponen de acuerdo, no se podrá realizar la conexión.[11] El proceso de selección tiene lugar durante el protocolo de establecimiento de comunicación o handshake de TLS, aunque el protocolo de TLS 1.3 difiere del utilizado en versiones anteriores de TLS/SSL.
Se puede utilizar un escáner de SSL/TLS para comprobar qué cifrados TLS soporta un servidor.[12]
Establecimiento de comunicación de TLS 1.0-1.2[editar]
El cliente empieza el proceso enviando un mensaje clientHello (literalmente, el «hola» del cliente) al servidor que incluye la versión de TLS en uso y una lista de conjuntos de cifrados en el orden de preferencia del cliente. En respuesta, el servidor envía un mensaje serverHello (el «hola» del servidor) que incluye el conjunto de cifrados escogido y el identificador de sesión. A continuación, el servidor envía al cliente un certificado digital para verificar su identidad. El servidor también puede solicitar al cliente su certificado digital.
Si el cliente y el servidor no están utilizando claves precompartidas, entonces el cliente envía un mensaje cifrado al servidor que permite al cliente y al servidor calcular qué clave secreta se utilizará durante los intercambios.
Tras verificar con éxito la autenticación del servidor y, en caso necesario, intercambiar la clave secreta, el cliente envía un mensaje finished («terminado») para indicar que ya ha concluido el proceso de establecimiento de comunicación. Tras recibir este mensaje, el servidor a su vez envía un mensaje finished para confirmar que el proceso de establecimiento de comunicación está completo. En este momento, el cliente y el servidor están de acuerdo en qué conjunto de cifrados van a utilizar para comunicarse entre sí.
Establecimiento de comunicación de TLS 1.3[editar]
El protocolo de establecimiento de comunicación de TLS 1.3 se ha condensado a un solo viaje de ida y vuelta frente a los dos requeridos por versiones anteriores de TLS/SSL.
En primer lugar, el cliente envía un mensaje clientHello al servidor con una lista de los conjuntos cifrados que soporta en su orden de preferencia, y hace una estimación de qué algoritmo de clave se está utilizando para poder enviar una clave secreta si es necesario. Al hacer esta suposición, elimina un viaje de ida y vuelta.
Tras recibir el clientHello, el servidor envía un serverHello con su clave, un certificado, el conjunto de cifrados escogido y el mensaje finished. Al recibir el mensaje finished del servidor, el cliente ya está coordinado con el servidor con el conjunto de cifrados que van a utilizar.[13]
Algoritmos permitidos[editar]
En TLS 1.0-1.2[editar]
En TLS 1.3[editar]
En TLS 1.3, se ha prescindido de muchos algoritmos heredados de versiones anteriores de TLS para hacer el protocolo más seguro.[15] Además, todos los algoritmos de cifrado y autenticación están combinados en el algoritmo de cifrado autenticado con datos asociados (AEAD, por sus siglas en inglés). También se debe utilizar ahora un algoritmo de hash en la derivación de claves basada en HMAC (HKDF).[16] Todos los cifrados que no son AEAD han sido retirados debido a posibles debilidades o vulnerabilidades, y todos los cifrados deben usar un algoritmo de intercambio de claves efímeras para que se puedan generar nuevos pares de claves para cada intercambio.[17]
DTLS con conjuntos de cifrados[editar]
El protocolo Datagram Transport Layer Security (DTLS) está basado en TLS, pero se utiliza específicamente para conexiones UDP en lugar de TCP. Como DTLS está basado en TLS, puede usar la mayoría de los conjuntos de cifrados descritos para TLS. Sin embargo, deben tenerse en cuenta determinados casos especiales al emplear conjuntos de cifrados TLS con este protocolo. DTLS no es compatible con el cifrado de flujo RC4, lo que quiere decir que no se puede utilizar con DTLS ningún conjunto de cifrados TLS que incluya RC4.[18]
Para determinar si un cifrado TLS es compatible con DTLS, no basta con mirar su nombre, ya que todos los conjuntos de cifrados TLS incluirán el identificador «TLS» en su nombre, por ejemplo, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. En cambio, todos los registros de parámetros TLS incluyen actualmente la bandera DTLS-OK para indicar si un conjunto de cifrados es compatible con DTLS.[19]
Vulnerabilidades[editar]
Un conjunto de cifrados es tan seguro como los algoritmos que contiene. Si la versión del algoritmo de cifrado o de autenticación de un conjunto de cifrados tiene vulnerabilidades conocidas, el conjunto de cifrados y la conexión TLS podrán entonces ser vulnerables. Por ello, un ataque habitual contra TLS y conjuntos de cifrados es el ataque de degradación (downgrade attack). La degradación de TLS se produce cuando un cliente moderno se conecta con un servidor que usa versiones anticuadas de TLS o SSL.
Al iniciar el establecimiento de comunicación o handshake, el cliente ofrecerá el protocolo más avanzado que pueda utilizar. Si la conexión falla, volverá a intentarlo con un protocolo inferior como TLS 1.0 o SSL 3.0 hasta que tenga éxito la comunicación con el servidor. El propósito de la degradación es que las nuevas versiones de TLS sean compatibles con versiones anteriores. Sin embargo, es posible que un atacante se aproveche de esta característica y haga que un cliente degrade automáticamente su protocolo de seguridad a una versión de TLS o SSL que admita conjuntos de cifrados que contengan algoritmos conocidos por su falta de seguridad y sus vulnerabilidades.[20] Esto ha dado lugar a ataques tales como POODLE.
Una forma de evitar este fallo de seguridad es deshabilitar la capacidad de un servidor o cliente degrade su protocolo a SSL 3.0. El inconveniente de esto es que el hardware reciente no pueda acceder a un hardware más antiguo. Sin embargo, si es necesario el soporte de SSL 3.0 para un hardware antiguo, existe el conjunto de cifrados TLS_FALLBACK_SCSV que verifica que no se fuercen degradaciones para propósitos maliciosos.[20]
Conjuntos de cifrados para dispositivos limitados[editar]
Los algoritmos de cifrado, intercambio de claves y autenticación suelen requerir una gran potencia de procesamiento y memoria. Para poder proporcionar seguridad a dispositivos limitados (constrained devices)[21] en potencia de procesamiento, memoria y duración de la batería como los que alimentan la Internet de las cosas, existen conjuntos de cifrado específicamente elegidos como los dos siguientes ejemplos:
TLS_PSK_WITH_AES_128_CCM_8(clave precompartida)[22]TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8(clave pública en bruto)
Cada uno de estos conjuntos de cifrados está implementado para poder utilizarse en dispositivos con limitaciones en potencia de procesado y memoria. Ambos están implementados en el proyecto de fuente abierta TinyDTLS.[23] Las implementaciones de la suite con clave precompartida apenas utilizaron 1889 bytes de memoria RAM y 38366 de memoria flash, mucho menos que la mayoría de algoritmos.[24] Los algoritmos han sido probados como seguros, aunque pueden no ser tan seguros como alternativas con mayores necesidades de recursos; por ejemplo, usan cifrado de 128 bits en lugar de cifrado de 256. Además, utilizan claves precompartidas o claves públicas en bruto, lo que requiere de menos memoria y potencia que la infraestructura de clave pública (PKIX) tradicional.[25]
Véase también[editar]
Referencias[editar]
- ↑ Visto en:
- «Configuración del servidor SMTP para utilizar AWS SES». Cisco. 8 de septiembre de 2022. Consultado el 9 de enero de 2024.
- «Módulo Apache mod_ssl». Apache. Consultado el 9 de enero de 2024.
- ↑ «Cómo saber si una conexión HTTPS es Insegura (vulnerable a FREAK o Bar Mitvzah)». Un informático en el lado del mal. 1 de abril de 2015. Consultado el 9 de enero de 2024.
- ↑ «suite criptográfica». Diccionario Español de Ingeniería (1.0 edición). Real Academia de Ingeniería de España. 2014.
- ↑ «Cipher Suites in TLS/SSL (Schannel SSP)». Microsoft Learn (en inglés). Consultado el 8 de enero de 2024.
- ↑ «Configuring a Cipher Suites List Using TLS v1.3». Microfocus (en inglés). Consultado el 8 de enero de 2024.
- ↑ The Transport Layer Security (TLS) Protocol Version 1.2, doi:10.17487/RFC5246, RFC 5246.
- ↑ «TLS Cipher Suites». IANA (en inglés). 23 de agosto de 2005, actualizado el 12 de diciembre de 2023. Consultado el 9 de enero de 2024.
- ↑ «The SSL 0.2 Protocol». www-archive.mozilla.org. Consultado el 7 de diciembre de 2017.
- ↑ «draft-hickman-netscape-ssl-00». tools.ietf.org (en inglés). Consultado el 7 de diciembre de 2017.
- ↑ «SSL 3.0 Specification». www.freesoft.org. Consultado el 7 de diciembre de 2017.
- ↑ Villanueva, John Carl (25 de octubre de 2022). «An Introduction To Cipher Suites». jscape.com (en inglés). Consultado el 10 de enero de 2024.
- ↑ «SSL Server Test». SSL Labs (en inglés). Consultado el 10 de enero de 2024.
- ↑ Valsorda, Filippo (23 de septiembre de 2016). «An overview of TLS 1.3 and Q&A». The Cloudflare Blog (en inglés). Consultado el 1 de septiembre de 2020.
- ↑ ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2, doi:10.17487/RFC8442, RFC 8442.
- ↑ «TLS 1.3 Protocol Support | wolfSSL Embedded SSL/TLS Library». wolfSSL (en inglés estadounidense). Consultado el 26 de octubre de 2017.
- ↑ E. Rescorla (4 de noviembre de 2016). «The Transport Layer Security (TLS) Protocol Version 1.3». Consultado el 11 de noviembre de 2016.
- ↑ Sullivan, Nick (11 de agosto de 2018). «A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)». The Cloudflare Blog (en inglés). Consultado el 11 de agosto de 2020.
- ↑ «Null or Standard Stream Cipher», Datagram Transport Layer Security, sec. 4.1.2.2, doi:10.17487/RFC4347, RFC 4347.
- ↑ «IANA Considerations», Datagram Transport Layer Security Version 1.2, sec. 7, doi:10.17487/RFC6347, RFC 6347.
- ↑ a b TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks, doi:10.17487/RFC7507, RFC 7507.
- ↑ «Constrained Nodes», Terminology for Constrained-Node Networks, sec. 2.1, doi:10.17487/RFC7228, RFC 7228.
- ↑ AES-CCM Cipher Suites for Transport Layer Security (TLS), doi:10.17487/RFC7228, RFC 7228.
- ↑ «Eclipse tinydtls». Eclipse Foundation. Consultado el 11 de enero de 2024.
- ↑ Perelmen, Vladislav (29 de junio de 2012). Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System. p. 38. Archivado desde el original el 29 de agosto de 2017. Consultado el 7 de diciembre de 2017.
- ↑ Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), doi:10.17487/RFC7250, RFC 7250.
- Esta obra contiene una traducción derivada de «Cipher suite» de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.