Seguridad de la capa de transporte

De Wikipedia, la enciclopedia libre
Esta es una versión antigua de esta página, editada a las 22:58 3 nov 2014 por 88.3.143.57 (discusión). La dirección URL es un enlace permanente a esta versión, que puede ser diferente de la versión actual.
Este artículo o sección se está traduciendo del idioma inglés a partir del artículo Transport Layer Security. Por esta razón, puede haber lagunas de contenidos, errores sintácticos o escritos sin traducir. Puedes colaborar con Wikipedia continuando con la traducción desde el artículo original.
Para otros usos de este término, véase TLS.
Transport Layer Security
(TLS)
Familia Internet
Función Seguridad en la capa de transporte
Última versión 1.2
Ubicación en la pila de protocolos
Aplicación HTTPS, IMAPS, POP3S, SMTPS, ...
Transporte TLS
TCP
Red IP
Estándares
RFC 5246, RFC 6176, otros
[editar datos en Wikidata]

Secure Sockets Layer (SSL; en español «capa de conexión segura») y su sucesor Transport Layer Security (TLS; en español «seguridad de la capa de transporte») son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet.

Descripción

SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

SSL implica una serie de fases básicas:

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

Historia y desarrollo

API de Secure Network Programming

Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API, por su sigla en inglés) de Secure Network Programming (SNP), la que en 1993 exploró la posibilidad de tener una API de capa de transporte segura similar a los sockets Berkeley, para facilitar la retroadaptación de las aplicaciones de red preexistentes con medidas de seguridad.[1]​

SSL 3.0

El protocolo SSL fue desarrollado originalmente por Netscape.[2]​ La versión 1.0 nunca se entregó públicamente; la versión 2.0 se presentó en febrero de 1995 pero "contenía una cantidad de fallas de seguridad que al final llevaron al diseño de la versión SSL 3.0".[3]​ Dicha versión, presentada en 1996, fue un rediseño completo del protocolo producido por Paul Kocher, quien trabajó con los ingenieros de Netscape Phil Karlton y Alan Freier. Las versiones más nuevas de SSL/TLS están basadas en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por la IETF como el histórico RFC 6101.

TLS 1.0

TLS 1.0 fue definido en el RFC 2246 en enero de 1999 y es una actualización de SSL versión 3.0. Como dice el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son significativas en impedir la interoperabilidad entre TLS 1.0 y SSL 3.0". TLS 1.0 incluye una forma en la cual la implementación puede conectarse en SSL 3.0, debilitando la seguridad.

TLS 1.1

TLS 1.1 fue definido en el RFC 4346 en abril del 2006.[4]​ Es una actualización de TLS 1.0. Las diferencias más significativas incluyen:

  • Agrega protección contra ataques de CBC.
    • El vector de inicialización (IV) implícito fue reemplazado por un IV explícito.
    • Cambio en el manejo de los errores de relleno.
  • Soporte para el registro de parámetros de IANA.

TLS 1.2

TLS 1.2 fue definido en el RFC 5246 en agosto del 2008. Se basa en una especificación anterior de TLS 1.1. Las mayores diferencias son:

  • la combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256, con la opción de usar PRFs especificados en la cipher-suite.
  • la combinación MD5-SHA-1 en el mensaje terminado fue reemplazada por SHA-256, sin la opción de usar algoritmos de hash específicos para la cipher-suite. Sin embargo, el tamaño del hash en el mensaje terminado es truncado a 96 bits.
  • la combinación MD5-SHA-1 en el elemento digitalmente firmado fue reemplazada por un hash simple negociado durante el handshake, que por defecto es SHA-1.
  • Mejoras en la habilidad de clientes y servidores para especificar que algoritmos de hash y de firma van a aceptar.
  • Expansión del soporte de cifras de cifrado autenticadas, usadas mayormente para modo Galois/Counter (GCM) y modo CCM del cifrado con Advanced Encryption Standard (o estándar de cifrado avanzado) (AES).
  • Se agregaron definición de Extensiones de TLS y de Ciphersuites de AES.

TLS 1.2 fue después redefinido en el RFC 6176 de marzo de 2011 redactando su retrocompatibilidad con SSL y TLS para que dichas sesiones jamás negocien el uso de SSL versión 2.0.

Funcionamiento

El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando.

Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el protocolo handshake (o protocolo de acuerdo), que tiene el content_type 22.

El cliente envía y recibe varias estructuras handshake:

  • Envía un mensaje ClientHello especificando una lista de conjunto de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida. Éste también envía bytes aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además puede incluir el identificador de la sesión.
  • Después, recibe un registro ServerHello, en el que el servidor elige los parámetros de conexión a partir de las opciones ofertadas con anterioridad por el cliente.
  • Cuando los parámetros de la conexión son conocidos, cliente y servidor intercambian certificados (dependiendo de las claves públicas de cifrado seleccionadas). Estos certificados son actualmente X.509, pero hay también un borrador especificando el uso de certificados basados en OpenPGP.[5]​
  • Cliente y servidor negocian una clave secreta (simétrica) común llamada master secret, posiblemente usando el resultado de un intercambio Diffie-Hellman, o simplemente cifrando una clave secreta con una clave pública que es descifrada con la clave privada de cada uno. Todos los datos de claves restantes son derivados a partir de este master secret (y los valores aleatorios generados en el cliente y el servidor), que son pasados a través una función pseudoaleatoria cuidadosamente elegida.

TLS/SSL poseen una variedad de medidas de seguridad:

  • Numerando todos los registros y usando el número de secuencia en el MAC.
  • Usando un resumen de mensaje mejorado con una clave (de forma que solo con dicha clave se pueda comprobar el MAC). Esto se especifica en el RFC 2104).
  • Protección contra varios ataques conocidos (incluyendo ataques man-in-the-middle), como los que implican un degradado del protocolo a versiones previas (por tanto, menos seguras), o conjuntos de cifrados más débiles.
  • El mensaje que finaliza el protocolo handshake (Finished) envía un hash de todos los datos intercambiados y vistos por ambas partes.
  • La función pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro.

Aplicaciones y adopción

SSL se ejecuta en una capa entre los protocolos de aplicación como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP. Puede proporcionar seguridad a cualquier protocolo que use conexiones de confianza (tal como TCP).

Sitios Web

Uno de los usos más importantes es junto a HTTP para formar HTTPS. HTTPS es usado para asegurar páginas World Wide Web para aplicaciones de comercio electrónico, utilizando certificados de clave pública para verificar la identidad de los extremos.

Soporte de protocolo de sitios web
Versión del
Protocolo 		Soporte en
Sitios Web[6]​ 		Seguridad[6]​[7]​
SSL 2.0 24.7% (-0.5%) Inseguro
SSL 3.0[n 1]​ 99.5% (±0.0%) Depende del cifrado y de la mitigación de BEAST en el cliente[n 2]​[n 3]​[n 4]​[n 1]​
TLS 1.0 99.3% (±0.0%) Depende del cifrado y de la mitigación de BEAST en el cliente[n 2]​[n 3]​[n 4]​[n 5]​
TLS 1.1 23.2% (+3.3%) Depende del cifrado[n 2]​[n 3]​[n 4]​[n 5]​
TLS 1.2 25.7% (+3.2%) Depende del cifrado[n 2]​[n 3]​[n 4]​[n 5]​
Notas
  1. ↑ a b La falla de renegociación insegura rompe este protocolo. Si las librerías implementan las mejoras listadas en el RFC 5746, esto violaría la especificación SSL 3.0, la que la IETF no puede cambiar a diferencia de TLS. Afortunadamente, la mayoría de las librarías actuales implementan las mejoras y no se preocupan por la violación que esto causa.
  2. ↑ a b c d ver seguridad del cifrado web en la tabla de más abajo
  3. ↑ a b c d varios ataques a RC4 debilitan o rompen el RC4 usado en SSL/TLS
  4. ↑ a b c d el ataque CRIME significa que la compresión TLS no es segura, y que el ataque BREACH que requiere compresión HTTP puede ser usado para vencer la seguridad tanto de TLS y de SSL 3.0 que sea parchado con el RFC 5746 cuando la compresión HTTP está habilitada.
  5. ↑ a b c RFC 5746 debe estar implementado en orden a resolver un defecto en la renegociación que de otra forma podría romper el protocolo.

Intercambio de claves o acuerdo de clave

Antes de que un cliente y el servidor pueden empezar a intercambiar información protegida por TLS, deben intercambiar en forma segura o acordar una clave de cifrado y una clave para usar cuando se encripte los datos (ver Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves son: las claves públicas y privadas generadas con RSA (denotado TLS_RSA en el protocolo de handshake TLS), Diffie-Hellman (llamado TLS_DH), Diffie-Hellman efímero (denotado TLS_DHE), Diffie-Hellman de Curva Elíptica (denotado TLS_ECDH), Diffie-Hellman de Curva Elíptica efímero (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon),[8]​ y PSK (TLS_PSK).[9]​

El método de acuerdo de claves TLS_DH_anon no autentica el servidor o el usuario y por lo tanto rara vez se utiliza. Sólo TLS_DHE y TLS_ECDHE proporcionan secreto-perfecto-hacia-adelante.

Los certificados de clave pública que se utilizan durante el intercambio/acuerdo también varían en el tamaño de las claves de cifrado públicas/privadas utilizadas durante el intercambio y, por tanto, en la solidez de la seguridad que proveen. En julio de 2013, Google anunció que dejaría de utilizar claves públicas 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad de la encriptación TLS que proporciona a sus usuarios.[10]​

Cifrado

Véase también: Cifrado por bloques
Seguridad del cifrado contra ataques conocidos
Cifrado Versión del Protocolo
SSL 2.0 SSL 3.0
[note 1]​[note 2]​[note 3]​ 		TLS 1.0
[note 1]​[note 3]​ 		TLS 1.1
[note 1]​ 		TLS 1.2
[note 1]​
AES CBC[note 4]​ — — depende Seguro Seguro
AES GCM[11]​[note 5]​ — — — — Seguro
AES CCM[12]​[note 5]​ — — — — Seguro
Camellia CBC[13]​[note 4]​ — — depende Seguro Seguro
Camellia GCM[14]​[note 5]​ — — — — Seguro
SEED CBC[15]​[note 4]​ — — depende Seguro Seguro
ChaCha20+Poly1305[16]​[note 5]​ — — — — Seguro
IDEA CBC[note 4]​[note 6]​ Inseguro depende depende Seguro —
3DES CBC[note 4]​[note 7]​ Inseguro depende depende depende depende
DES CBC[note 4]​[note 6]​ Inseguro Inseguro Inseguro Inseguro —
RC2 CBC[note 4]​[note 6]​ Inseguro Inseguro Inseguro Inseguro —
RC4[note 8]​ Inseguro Inseguro Inseguro Inseguro Inseguro
Notas
  1. ↑ a b c d RFC 5746 debe estar implementado para solucionar una falla en la renegociación que de otra forma rompe este protocolo.
  2. ↑ Si las librerías implementan las mejoras listadas en el RFC 5746, esto violaría la especificación SSL 3.0, la que la IETF no puede cambiar a diferencia de TLS. Afortunadamente, la mayoría de las librarías actuales implementan las mejoras y no se preocupan por la violación que esto causa.
  3. ↑ a b elataque BEAST rompe todos los bloques cifrados (CBC ciphers) usados en SSL 3.0 y TLS 1.0 a menos de que sea mitigado por el cliente. a noviembre del 2013, Apple ha activado la mitigación por defecto solo para Safari 7 para Mac OS X 10.9, resultando en que tanto Safari for iOS, para Windows, y para Mac OS X 10.8 y anteriores todavía son teóricamente vulnerables al ataque BEAST en estas plataformas. - ver #Navegadores
  4. ↑ a b c d e f g El cifrado CBC puede ser atacado con el Ataque Trece con suerte si la librería no está escrita cuidadosamente para eliminar el timing de canales laterales.
  5. ↑ a b c d AEAD cifrado (como GCM y CCM) puede ser usado solo en TLS 1.2.
  6. ↑ a b c IDEA, DES, and RC2 CBC have been removed from TLS 1.2.
  7. ↑ 3DES provee solamente 108 o 112 bits de seguridad, lo cual es menos que el mínimo recomendado de 128 bits.[17]​
  8. ↑ los ataques RC4 debilitan o rompen el RC4 usado en SSL/TLS

Navegadores

Todos los navegadores importantes soportan TLS:

Soporte de TLS en navegadores
Navegador Plataforma TLS 1.0 TLS 1.1 TLS 1.2
Chrome 0–22 Linux, Mac OS X, Windows (XP, Vista, 7, 8).[notas 1]​[18]​[19]​[notas 2]​ Sí No No
Chrome 22–29 Linux, Mac OS X, Windows (XP, Vista, 7, 8)[notas 1]​[notas 2]​ Sí Sí No
Chrome 30- Linux, Mac OS X, Windows (XP, Vista, 7, 8)[notas 1]​[notas 2]​ Sí Sí Sí
Firefox 2– Linux, Mac OS X, Windows (XP, Vista, 7, 8[notas 2]​ Sí[20]​ No[21]​ No[22]​
Firefox 27- Linux, Mac OS X, Windows (XP, Vista, 7, 8)[notas 1]​[notas 2]​ Sí Sí Sí
IE 1–7 Mac OS X, Windows (XP, Vista, 7).[notas 3]​[23]​[24]​ Sí No No
IE 8 Windows (XP, Vista)[notas 3]​ Sí No No
IE 8–9 Windows 7[notas 3]​ Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
IE 9 Windows Vista[notas 3]​ Sí No No
IE 10 Windows (7, 8)[notas 3]​ Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
IE 11 Windows (7, 8.1)[notas 3]​ Sí Sí Sí
Opera 10– Linux, Mac OS X, Windows[notas 4]​[25]​ Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
Safari 5–6 Mac OS X, Windows (XP, Vista, 7)[notas 5]​[notas 6]​[26]​[27]​ Sí No No
Safari 7 Mac OS X 10.9[notas 5]​ Sí Sí Sí
Mobile Safari/UIWebView iOS 5.0+[notas 7]​[28]​[29]​[30]​ Sí Sí Sí
Notas
  1. ↑ a b c d El navegador Google Chrome (y Chromium) soportan TLS 1.0 y TLS 1.1 desde la versión 22 (se agregó, luego se bajó desde la versión 21). TLS 1.2 no es compatible
  2. ↑ a b c d e Utiliza la implementación TLS proporcionada por NSS. A noviembre de 2012, NSS soporta TLS 1.0 y 1.1, pero no 1.2.[actualizar]
  3. ↑ a b c d e f IE utiliza la implementación TLS del sistema operativo Microsoft Windows proporcionada por el proveedor soporte de seguridad SChannel. TLS 1.1 y 1.2 están deshabilitadas por defecto
  4. ↑ Hasta Presto 2.2, que aparece en Opera 10, Opera añade soporte para TLS 1.2 después de soportar previamente 1.0 y 1.1.
  5. ↑ a b Safari utiliza la implementación del sistema operativo Mac OS X, Windows (XP, Vista, 7) con versión desconocida
  6. ↑ Safari 5 es la última versión disponible para Windows.
  7. ↑ Mobile Safari y software de terceros que utilizan el sistema UIWebView biblioteca utiliza el sistema operativo iOS aplicación, que admite TLS 1.2 Desde de iOS 5.0.

Bibliotecas

SSL y TLS han sido implementados ampliamente en varios proyectos de software abierto y libre. Los programadores pueden usar las librerías PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS o GnuTLS para tener funcionalidad SSL/TLS.

  • Microsoft Windows incluye una implementación de SSL y TLS como parte de su paquete Secure Channel.
  • OS X incluye una implementación de SSL y TLS como parte de su paquete Secure Transport.
  • Los programadores de Delphi pueden usar una librería llamada Indy.
  • OpenSSL es una implementación libre. Tiene una licencia BSD con algunas extensiones.
  • GnuTLS es una implementación libre, con licencia LGPL.
  • Zodiac TLS/SSL: es una implementación para Smalltalk con licencia MIT.
  • cryptlib es librería criptográfica potable de software abierto (que incluye una implementación de SSL/TLS).
  • JSSE: una implementación Java incluida en el Java Runtime Environment que soporta TLS 1.1 y 1.2 desde Java 7, aunque está por defecto deshabilitada para el cliente y habilitada en el servidor.
  • MatrixSSL: una implementación con licencia dual.
  • Network Security Services (NSS): es una librería open source validada para FIPS 140.
  • PolarSSL es una implementación SSL/TLS muy pequeña para dispositivos embebidos que está diseñada para uso fácil.
  • CyaSSL es una librería SSL/TLS embebida con fuerte foco en velocidad y tamaño.

Un ensayo presentado en la conferencia ACM 2012 de seguridad de computadores y comunicaciones[31]​ mostró que muchas aplicaciones utilizaban estas librerías incorrectamente, llevando a vulnerabilidad. Los autores hacían notar que "la causa principal de la mayoría de estas vulnerabilidad es el terrible diseño de las APIs para las librerías subyacentes. En vez de expresar propiedades de seguridad alto nivel para túneles de red tales como confidencialidad y autenticación, estas APIs exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores frecuentemente usan las APIs de SSL incorrectamente, malinterpretando y malentendiendo los posibles parámetros, opciones, efectos colaterales y valores de retorno."

Otros usos

Otra aplicación con creciente uso de TLS es SMTP. TLS es también el método estándar para proteger la señalización de aplicaciones con Session Initiation Protocol (SIP). TLS se puede utilizar para proveer autenticación y cifrado a la señalización asociada con VoIP y otras aplicaciones basadas en SIP.

Aunque un número creciente de productos clientes y servidores pueden proporcionar SSL de forma nativa, muchos aún no lo permiten. En estos casos, un usuario podría querer usar una aplicación SSL independiente como Stunnel para proporcionar cifrado. No obstante, el Internet Engineering Task Force recomendó en 1997 que los protocolos de aplicación ofrecieran una forma de actualizar a TLS a partir de una conexión sin cifrado (plaintext), en vez de usar un puerto diferente para cifrar las comunicaciones – esto evitaría el uso de envolturas (wrappers) como Stunnel.

SSL también puede ser usado para tunelizar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.

Seguridad

SSL 2.0

SSL 2.0 tiene una variedad de fallas:[32]​

  • Claves criptográficas idénticas se utilizan para la autenticación de mensajes y el cifrado.
  • SSL 2.0 tiene una construcción MAC débil que utiliza la función hash MD5 con un prefijo secreto, por lo que es vulnerable a los ataques de extensión de longitud.
  • SSL 2.0 no tiene ningún tipo de protección para el handshake, es decir, un ataque man-in-the-middle que se rebaje a este protocolo puede pasar desapercibido.
  • SSL 2.0 utiliza el cierre de la conexión TCP para indicar el final de los datos. Esto significa que los ataques de truncamiento son posibles: el atacante simplemente forja un TCP FIN, dejando el receptor inconsciente de un fin ilegítimo de mensaje de datos (SSL 3.0 soluciona este problema al tener una alerta de cierre explícita).
  • SSL 2.0 asume un solo servicio y un certificado de dominio fijo, que choca con una función estándar de hosting virtual en los servidores Web. Esto significa que la mayoría de los sitios web están prácticamente afectados por el uso de SSL.


SSL 2.0 está desactivado por defecto, a partir de: Internet Explorer 7,[33]​ Mozilla Firefox 2,[34]​ Opera 9.5 ,[35]​ y Safari. Después de que se envía un "ClientHello" TLS, si Mozilla Firefox comprueba que el servidor no puede completar el handshake, intentará volver a caer a la utilización de SSL 3.0 con un SSL 3.0 "ClientHello" en formato SSL 2.0 para maximizar la probabilidad de éxito del handshake con los servidores más antiguos.[36]​ Permitir SSL 2.0 (y sistemas de cifrado débiles de 40 y 56 bits), ha sido completamente eliminado de Opera desde la versión 10[37]​[38]​

SSL 3.0

SSL 3.0 mejoró SSL 2.0 mediante la adición de cifrado SHA-1 y soporte para autenticación de certificados.

Desde el punto de vista de seguridad, SSL 3.0 debería considerarse menos deseable que TLS 1.0. Las suites de cifrado de SSL 3.0 tienen un proceso de derivación de claves débiles, la mitad de la llave maestra que se establece es totalmente dependiente de la función hash MD5, que no es resistente a los choques y, por lo tanto, no es considerado seguro. Bajo TLS 1.0, la llave maestra que se establece depende tanto MD5 y SHA-1 por lo que su proceso de derivación no está actualmente considerado débil. Es por esta razón que las implementaciones SSL 3.0 no pueden ser validados bajo FIPS 140-2.[39]​

Hay algunos ataques contra la implementación en lugar del propio protocolo:[40]​ En las implementaciones anteriores, algunas entidades emisoras[41]​ no establecieron explícitamente basicConstraintsCA=False para los nodos hoja. Como resultado, estos nodos hoja podían firmar certificados piratas. Además, algunos programas de (incluyendo IE6 y Konqueror) no comprobó este campo para nada. Esto puede ser explotado en ataques man-in-the-middle a todas las conexiones posibles SSL. Algunas implementaciones (incluyendo versiones anteriores de la API de cifrado de Microsoft, Network Security Services y GnuTLS) dejan de leer los caracteres que siguen al carácter nulo en el campo del nombre del certificado, lo que puede ser explotado para engañar al cliente en la lectura del certificado como si fuera originado en el sitio auténtico. (Por ejemplo, PayPal.com\0.badguy.com sería confundido como proveniente del sitio PayPal.com en lugar de badguy.com). Los navegadores implementaron mecanismos de degradación del protocolo a una versión anterior en SSL/TLS por razones de compatibilidad. La protección ofrecida por los protocolos SSL/TLS contra un downgrade a una versión anterior de un ataque man-in-the-middle activo puede ser inutilizados por tales mecanismos.[42]​

TLS

TLS tiene una variedad de medidas de seguridad:

  • Protección contra una degradación del protocolo a una versión anterior (menos segura) o un conjunto de cifrado más débil.
  • Numeración de los registros de aplicación posteriores con un número de secuencia y el uso de este número de secuencia en los códigos de autenticación de mensajes (MAC).
  • Usando un resumen de mensaje mejorado con una clave (por lo que sólo una llave-sostenedor puede comprobar el MAC). La construcción HMAC utilizado por la mayoría de las suites de cifrado TLS se especifica en el RFC 2104 (SSL 3.0 utiliza un MAC basado en hash diferente).
  • El mensaje que finaliza el protocolo de enlace ("Finalizar") envía un hash de todos los mensajes intercambiados handshake vistos por ambas partes.
  • La función pseudoaleatoria divide los datos de entrada en un medio y procesa cada uno con un algoritmo de hash diferente (MD5 y SHA-1), luego les hace OR exclusivo juntos para crear el MAC. Esto proporciona protección incluso si uno de estos algoritmos resulta ser vulnerable.

Ataques contra SSL/TLS

Los ataques más significativos se mencionan más abajo:

Ataque de Renegociación

Una vulnerabilidad del procedimiento de renegociación fue descubierto en agosto de 2009, que puede conducir a ataques de inyección de texto plano contra SSL 3.0 y todas las versiones actuales de TLS. Por ejemplo, permite a un atacante que puede secuestrar una conexión https para empalmar sus propias peticiones en el inicio de la conversación que el cliente tiene con el servidor web. El atacante no puede realmente descifrar la comunicación cliente-servidor, por lo que es diferente de un típico ataque man-in-the-middle. Una solución a corto plazo es que los servidores de Internet dejen de permitir la renegociación, que normalmente no requerirá otros cambios a menos que se utilice la autenticación de certificados de cliente. Para corregir la vulnerabilidad, una extensión de la indicación de renegociación fue propuesta para TLS. Se requerirá que el cliente y el servidor incluyan y verifiquen información acerca de los apretones de manos anteriores en cualquier renegociación de apretón de manos.[43]​ Esta extensión se ha convertido en una norma propuesta y se le ha asignado el número de RFC 5746. El RFC ha sido implementado por varias bibliotecas.[44]​[45]​[46]​

Ataques de reversión de Versiones

Hay modificaciones a los protocolos originales, como False Start[47]​ (aprobada y habilitada por Google Chrome[48]​) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversión de versiones para TLS[49]​ o para permitir que las modificaciones de la lista de conjunto de cifrado enviada por el cliente al servidor (un atacante puede ser capaz de influir en la selección de la suite de cifrado en un intento de rebajar la intensidad de juego de cifrado, ya sea para usar un algoritmo de cifrado simétrico más débil o de un intercambio de clave más débil[50]​). Se ha demostrado en la conferencia sobre seguridad informática y de comunicaciones de la Association for Computing Machinery (ACM) que la extensión False Start está en riesgo bajo ciertas circunstancias, lo que podría permitir a un atacante recuperar las claves de cifrado en línea y acceder a los datos cifrados.[51]​


Ataque BEAST

El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una “prueba de concepto“ llamada BEAST ("Browser Exploit Against SSL/TLS") usando un applet Java para violar restricciones de políticas de mismo origen, por una vulnerabilidad de CBC largamente conocida de TLS 1.0.[52]​[53]​ Exploits prácticos de esta vulnerabilidad no se conocían, la cual fue descubierta originalmente por Phillip Rogaway[54]​ en 2002.

Mozilla actualizó las versiones de desarrollo de sus librerías NSS para mitigar ataques de tipo BEAST. NSS es utilizado por Mozilla Firefox y por Google Chrome para su implementación de SSL. Algunos servidores web que tienen una implementación quebrada de la especificación SSL puede que dejen de funcionar como resultado de esto.[55]​

Microsoft emitió el boletín de seguridad MS12-006 el 12 de enero de 2012, que corrigió la vulnerabilidad BEAST al cambiar la forma en que el componente de Windows Secure Channel (SChannel) transmite los paquetes cifrados.[56]​ Por su parte, Apple habilitó por defecto la protección contra BEAST en la versión OS X 10.9 Mavericks.[57]​

El ataque BEAST también se puede prevenir eliminando todos los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es ampliamente soportado por la mayoría de los sitios web.[58]​[59]​ Los usuarios de Windows 7 y de Windows Server 2008 R2 pueden permitir el uso de TLS 1.1 y 1.2, pero esta contramedida fallará si no es soportado también por el otro extremo de la conexión, y caerá a TLS 1.0.

Ataques CRIME y BREACH

Artículos principales: CRIME y BREACH (ataque).

Los autores del ataque BEAST también son los creadores del ataque CRIME, que usa compresión de datos para adivinar.[60]​[61]​ Cuando se utiliza para recuperar el contenido de la cookie de autenticación secreta, permite a un atacante realizar un secuestro de sesión en una sesión web autenticada.

Soporte en sitios web

A febrero de 2014, Trustworthy Internet Movement estima que la proporción de sitios web que son vulnerable a ataques TLS.[6]​

Encuesta de las vulnerabilidades de TLS de los sitios web más populares
Ataques Securidad
Inseguro Depende Seguro Otro
Ataque
de Renegociación 		6.2% (−0.1%)
soporta renegociación insegura 		1.5% (+0.1%)
soporta ambos 		84.6% (+0.4%)
soporta renegociación segura 		7.8% (−0.2%)
sin soporte
Ataques RC4 36.1% (−0.1%)
permite cifrados RC4 usado con navegadores modernos 		55.8% (−0.2%)
soporta algunas RC4 cifrados 		8.0% (+0.2%)
sin soporte 		—
Ataque BEAST 69.6% (±0.0%)
vulnerable 		— — —
Ataque CRIME 14.3% (−0.8%)
vulnerable 		— — —

Soporte para servidores virtuales por nombre

Desde el punto de vista del protocolo de aplicaciones, TLS pertenece a una capa baja, aunque el modelo TCP/IP es muy grueso para mostrarlo. Esto significa que el handshake es usualmente (excepto en el caso STARTTLS) llevado a cabo antes de que el protocolo de aplicación pueda comenzar. La funcionalidad de servidor virtual basado en nombres es provista por la capa de aplicación, donde todos los servidores virtuales alojados en una misma máquina comparten el mismo certificado. Esto es un problema, ya que el servidor debe seleccionar y mandar el certificado inmediatamente después del mensaje de ClientHello. Este es un gran problema en los ambientes de alojamiento, ya que implica que todos los clientes en un mismo servidor deben compartir el certificado o se debe utilizar una IP distinta para cada uno de ellos. Hay dos formas conocidas de evitar esto, provistas por X.509:

  • Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado wildcard. Además de que podría ser un problema la selección amplia de host ame, no hay acuerdo en cómo emparejar certificados wildcard. Se aplican reglas diferentes dependiendo del protocolo de aplicación o del software usado.[62]​
  • Agregar cada host virtual en la extensión subjectAltName. El problema mayor de esto es que el certificado necesita ser remitido cada vez que se agrega un nuevo servidor.

En orden a proveer el nombre del servidor, la RFC 4366 Transport Layer Security (TLS) Extensions permiten al cliente incluir una extensión de Indicación de nombre de servidor (Server Name Indication o SNI) en el mensaje extendido ClientHello. Esta extensión inmediatamente le da pistas al servidor respecto de cuál nombre es al que el cliente se quiere conectar, por lo que el servidor puede seleccionar el certificado apropiado para enviar al cliente.

Estándares

La versión actual aprobada de TLS es la 1.2, la que se especifica en:

  • RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.

El estándar actual reemplaza a las versiones más antiguas, las que son consideradas obsoletas:

  • RFC 2246: “The TLS Protocol Version 1.0”.
  • RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.

así como el nunca estandarizado SSL 3.0:

  • RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.

Otros RFC posteriores extendieron TLS.

Las extensions a TLS 1.0 incluyen:

  • RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Especifica una extensión a los servicios IMAP, POP3 y ACAP que permiten a cliente y servidor usar seguridad en la capa de transporte para entregar comunicaciones privadas y autenticadas sobre Internet.
  • RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Las familias de cifrados de 40-bit definidas en este memo aparecen sólo para propósitos de documentación del hecho de que esas familias de códigos de cifrado han sido ya asignadas.
  • RFC 2817: "Upgrading to TLS Within HTTP/1.1", explica cómo usar el mecanismo Upgrade en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente. Esto permite al tráfico HTTP inseguro y seguro compartir el mismo puerto conocido (en este caso, http: en el 80 en vez de https: en el 443).
  • RFC 2818: "HTTP Over TLS", diferencia tráfico seguro de tráfico inseguro mediante el uso de un 'puerto de servidor' diferente.
  • RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Especifca una extensión al servicio SMTP que permiten a cliente y servidor SMTP usar seguridad en la capa de transporte para entregar comunicaciones privadas y autenticadas sobre Internet.
  • RFC 3268: "AES Ciphersuites for TLS". Añade la familia de cifrado AES a los cifrados simétricos previamente existentes.
  • RFC 3546: "Transport Layer Security (TLS) Extensions", añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.
  • RFC 3749: “Transport Layer Security Protocol Compression Methods”, especifica el marco para los métodos de compresión y para el método DEFLATE.
  • RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
  • RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
  • RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
  • RFC 4217: “Securing FTP with TLS”.
  • RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticación basada en claves previamente compartidas.

Las extensions a TLS 1.1 incluyen:

  • RFC 4347: “Datagram Transport Layer Security” especifica una variante de TLS que funciona sobre protocolos de datagramas (tales como UDP).
  • RFC 4366: “Transport Layer Security (TLS) Extensions” describe tanto un set de extensiones específicas y un mecanismo de extensiones genéricas.
  • RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
  • RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
  • RFC 4680: “TLS Handshake Message for Supplemental Data”.
  • RFC 4681: “TLS User Mapping Extension”.
  • RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.
  • RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Define las cihpersuites TLS-SRP.
  • RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsoleta después del RFC 6091.

Las extensions a TLS 1.2 incluyen:

  • RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.
  • RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.
  • RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.
  • RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.
  • RFC 6209: “Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)”.

Las encapsulaciones de TLS incluyen:

  • RFC 5216: "The EAP-TLS Authentication Protocol"

Véase también

Referencias

  • David Wagner and Bruce Schneier, Analysis of the SSL 3.0 Protocol, The second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp29–40.
  1. ↑ Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994
  2. ↑ «THE SSL PROTOCOL». Netscape Corporation. 2007. Archivado desde el original el 14 de junio de 1997. 
  3. ↑ Rescorla 2001
  4. ↑ Dierks, T. and E. Rescorla (abril de 2006). «The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346». 
  5. ↑ RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“
  6. ↑ a b c Al 03 de enero de 2014. «SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites». Consultado el 8 de enero de 2014. 
  7. ↑ ivanr. «RC4 in TLS is Broken: Now What?». Qualsys Security Labs. Consultado el 30 de julio de 2013. 
  8. ↑ «RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2». Internet Engineering Task Force. Consultado el 9 de septiembre de 2013. 
  9. ↑ P. Eronen, Ed. «RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)». Internet Engineering Task Force. Consultado el 9 de septiembre de 2013. 
  10. ↑ Gothard, Peter. «Google updates SSL certificates to 2048-bit encryption». Computing. Incisive Media. Consultado el 9 de septiembre de 2013. 
  11. ↑ RFC 5288
  12. ↑ RFC 6655
  13. ↑ RFC 5932
  14. ↑ RFC 6367
  15. ↑ RFC 4162
  16. ↑ draft-agl-tls-chacha20poly1305-04
  17. ↑ Qualys SSL Labs. «SSL/TLS Deployment Best Practices». Consultado el 19 de noviembre de 2013. 
  18. ↑ Google (29 de mayo de 2012). «Dev Channel Update». Consultado el 14 de enero de 2013. 
  19. ↑ Google (21 de agosto de 2012). «Stable Channel Update». Consultado el 14 de enero de 2013. 
  20. ↑ «Security in Firefox 2». 6 de agosto de 2008. Consultado el 14 de enero de 2013. 
  21. ↑ «Bug 733647 - Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default». 6 de marzo de 2012. Consultado el 14 de enero de 2013. 
  22. ↑ «Bug 480514 - Implement support for TLS 1.2 (RFC 5246)». 17 de marzo de 2010. Consultado el 14 de enero de 2013. 
  23. ↑ Microsoft (5 de septiembre de 2012). «Secure Channel». Consultado el 14 de enero de 2013. 
  24. ↑ Microsoft (27 de febrero de 2009). «MS-TLSP Appendix A». Consultado el 14 de enero de 2013. 
  25. ↑ Yngve Nysæter Pettersen (25 de febrero de 2009). «New in Opera Presto 2.2: TLS 1.2 Support». Archivado desde el original el 4 de marzo de 2009. Consultado el 14 de enero de 2013. 
  26. ↑ Adrian, Dimcev. «Common browsers/libraries/servers and the associated cipher suites implemented». TLS Cipher Suites Project. 
  27. ↑ Apple (10 de junio de 2009). «Features». Consultado el 14 de enero de 2013. 
  28. ↑ Apple (14 de octubre de 2011). «Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues». Consultado el 14 de enero de 2013. 
  29. ↑ Liebowitz, Matt (13 de octubre de 2011). «Apple issues huge software security patches». NBCNews.com. Consultado el 14 de enero de 2013. 
  30. ↑ MWR Info Security (16 de abril de 2012). «Adventures with iOS UIWebviews». Consultado el 14 de enero de 2013. , section "HTTPS (SSL/TLS)"
  31. ↑ Georgiev, Martin and Iyengar, Subodh and Jana, Suman and Anubhai, Rishita and Boneh, Dan and Shmatikov, Vitaly (2012). «The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security». pp. 38-49. ISBN 978-1-4503-1651-4. 
  32. ↑ Joris Claessens, Valentin Dem, Danny De Cock, Bart Preneel, Joos Vandewalle (2002). «On the Security of Today's Online Electronic Banking Systems». Computers & Security 21 (3): 253-265. doi:10.1016/S0167-4048(02)00312-7. 
  33. ↑ Lawrence, Eric (22 de octubre de 2005). «IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2». MSDN Blogs. Consultado el 25 de noviembre de 2007. 
  34. ↑ «Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers». Mozilla Corporation. Consultado el 25 de noviembre de 2007. 
  35. ↑ "Opera 9.5 for Windows Changelog" at Opera.com: "Disabled SSL v2 and weak ciphers."
  36. ↑ «Firefox still sends SSLv2 handshake even though the protocol is disabled». 11 de septiembre de 2008. 
  37. ↑ "Opera 10 for Windows changelog" en Opera.com: "Removed support for SSL v2 and weak ciphers"
  38. ↑ Pettersen, Yngve (30 de abril de 2007). «10 years of SSL in Opera — Implementer's notes». Opera Software. Archivado desde el original el 6 de mayo de 2007. Consultado el 25 de noviembre de 2007. 
  39. ↑ National Institute of Standards and Technology (diciembre de 2010). «Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program». 
  40. ↑ Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las referencias llamadas DanGoodin
  41. ↑ Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las referencias llamadas combinator
  42. ↑ Dimcev, Adrian. «SSL/TLS version rollbacks and browsers». Consultado el 9 de marzo de 2011. 
  43. ↑ Eric Rescorla (5 de noviembre de 2009). «Understanding the TLS Renegotiation Attack». Educated Guesswork. Consultado el 27 de noviembre de 2009. 
  44. ↑ «SSL_CTX_set_options SECURE_RENEGOTIATION». OpenSSL Docs. 25 de febrero de 2010. Consultado el 18 de noviembre de 2010. 
  45. ↑ «GnuTLS 2.10.0 released». GnuTLS release notes. 25 de junio de 2010. Consultado el 24 de julio de 2011. 
  46. ↑ «NSS 3.12.6 release notes». NSS release notes. 3 de marzo de 2010. Consultado el 24 de julio de 2011. 
  47. ↑ A. Langley; N. Modadugu, B. Moeller (June de 20120). «Transport Layer Security (TLS) False Start». Internet Engineering Task Force. IETF. Consultado el 31 de julio de 2013. 
  48. ↑ Wolfgang, Gruener. «False Start: Google Proposes Faster Web, Chrome Supports It Already». Archivado desde el original el 7 de octubre de 2010. Consultado el 9 de marzo de 2011. 
  49. ↑ Brian, Smith. «Limited rollback attacks in False Start and Snap Start». Consultado el 9 de marzo de 2011. 
  50. ↑ Adrian, Dimcev. «False Start». Random SSL/TLS 101. Consultado el 9 de marzo de 2011. 
  51. ↑ Mavrogiannopoulos, Nikos and Vercautern, Frederik and Velichkov, Vesselin and Preneel, Bart (2012). A cross-protocol attack on the TLS protocol. Proceedings of the 2012 ACM conference on Computer and communications security. pp. 62-72. ISBN 978-1-4503-1651-4. 
  52. ↑ Dan Goodin (19 de septiembre de 2011). «Hackers break SSL encryption used by millions of sites». 
  53. ↑ «Y Combinator comments on the issue». 20 de septiembre de 2011. 
  54. ↑ «Security of CBC Ciphersuites in SSL/TLS». 20 de mayo de 2004. 
  55. ↑ Brian Smith (30 de septiembre de 2011). «(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)». 
  56. ↑ «Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)». 10 de enero de 2012. 
  57. ↑ Ristic, Ivan (31 de octubre de 2013). «Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks». Security Labs (en inglés). Consultado el 1 de febrero de 2014. 
  58. ↑ «Safest ciphers to use with the BEAST? (TLS 1.0 exploit)». 24 de septiembre de 2011. 
  59. ↑ «First solutions for SSL/TLS vulnerability». 26 de septiembre de 2011. 
  60. ↑ Dan Goodin (13 de septiembre de 2012). «Crack in Internet's foundation of trust allows HTTPS session hijacking». Ars Technica. Consultado el 31 de julio de 2013. 
  61. ↑ Dennis Fisher (13 de septiembre de 2012). «CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions». ThreatPost. Consultado el 13 de septiembre de 2012. 
  62. ↑ «Named-based SSL virtual hosts: how to tackle the problem» (PDF). Consultado el 17 de mayo de 2012. 

Enlaces externos

Obtenido de «https://es.wikipedia.org/w/index.php?title=Seguridad_de_la_capa_de_transporte&oldid=77933552»