fbpx
Wikipedia

Seguridad de la capa de transporte

Agosto 04, 2021

Este artículo o sección necesita ser wikificado, por favor, edítalo para que cumpla con las convenciones de estilo.
Este aviso fue puesto el 17 de febrero de 2018.
Para otros usos de este término, véase TLS.

Seguridad de la capa de transporte (en inglés: Transport Layer Security o TLS) y su antecesor Secure Sockets Layer (SSL; en español capa de puertos seguros) son protocolos criptográficos, que proporcionan comunicaciones seguras por una red, comúnmente Internet.[1]​

Seguridad de la capa de transporte
Familia Internet
Función Seguridad en la capa de transporte
Última versión 1.3
Ubicación en la pila de protocolos
Estándares
RFC 8446, RFC 5705, RFC 6066, otros
[editar datos en Wikidata]

Se usan certificados X.509 y por lo tanto criptografía asimétrica para autentificar a la contraparte con quien se están comunicando,[2]​ y para intercambiar una llave simétrica. Esta sesión es luego usada para cifrar el flujo de datos entre las partes. Esto permite la confidencialidad del dato/mensaje, códigos de autenticación de mensajes para integridad y como un producto lateral, autenticación del mensaje. Varias versiones del protocolo están en aplicaciones ampliamente utilizadas como navegación web, correo electrónico, fax por Internet, mensajería instantánea y voz-sobre-IP (VoIP). Una propiedad importante en este contexto es forward secrecy, para que la clave de corta vida de la sesión no pueda ser descubierta a partir de la clave asimétrica de largo plazo.[3]​

TLS es un protocolo de Internet Engineering Task Force (IETF), definido por primera vez en 1999 y actualizado en el RFC 5246 (agosto de 2008) y en RFC 6176 (marzo de 2011). Se basa en las especificaciones previas de SSL (1994, 1995, 1996) desarrolladas por Netscape Communications[4]​ para agregar el protocolo HTTPS a su navegador Netscape Navigator. Su última versión, TLS 1.3, fue definida en agosto de 2018.[5]​

Descripción

SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, solo 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

Protocolo Publicación
SSL 1.0 No publicado
SSL 2.0 1995
SSL 3.0 1996
TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 2018

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.[6]​

SSL 3.0

El protocolo SSL fue desarrollado originalmente por Netscape.[7]​ 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".[8]​ 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. En octubre de 2014, se detectó una nueva vulnerabilidad sobre el protocolo SSL en su versión 3.0, la Vulnerabilidad de Poodle.

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 suficientemente significativas como para 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 de 2006.[9]​ 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 originalmente en el RFC 5246 en agosto del 2008. Se basa en una especificación posterior 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 las PRF especificadas 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 (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.

TLS 1.3

TLS 1.3 fue definido en el RFC 8446 en agosto de 2018. Está basado en la anterior especificación TLS 1.2. Las principales diferencias con TLS 1.2 incluyen:

  • Un modo 0-RTT
  • Retiro de la hora GMT.
  • Fusiona soporte de ECC del RFC 4492 pero sin curvas explícitas.
  • Retira el campo de longitud innecesaria de la entrada de AD a cifras AEAD.
  • Cambiar el nombre de {Cliente, Servidor} KeyExchange a {Cliente, Servidor} KeyShare
  • Añade un HelloRetryRequest explícita para rechazar el del cliente
  • Handshake revisado a fin de proporcionar el modo 1-RTT.
  • Retiro de grupos DHE personalizados.
  • Eliminado el soporte para la compresión.
  • Eliminado el soporte para el intercambio de claves RSA estática y DH.
  • Eliminado el soporte para sistemas de cifrado no AEAD.

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. Este 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.[10]​
  • 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.

Intercambio de claves

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 cifren 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),[2]​ y PSK (TLS_PSK).[11]​

El método de acuerdo de claves TLS_DH_anon no verifica el servidor o el usuario y por lo tanto rara vez se utiliza puesto que es vulnerable a un ataque de suplantación de identidad. Solo 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 del cifrado TLS que proporciona a sus usuarios.[12]​

Autenticación e Intercambio/acuerdo de claves
Algoritmo SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Estatus
RSA Sí Sí Sí Sí Sí Definido para TLS 1.2 en RFCs
DH-RSA No Sí Sí Sí Sí
DHE-RSA (forward secrecy)
ECDH-RSA No No Sí Sí Sí
ECDHE-RSA (forward secrecy)
DH-DSS No Sí Sí Sí Sí
DHE-DSS (forward secrecy)
ECDH-ECDSA No No Sí Sí Sí
ECDHE-ECDSA (forward secrecy)
DH-ANON (inseguro) No No Sí Sí Sí
ECDH-ANON (inseguro) No No Sí Sí Sí
GOST R 34.10-94 / 34.10-2001[13]​ No No Sí Sí Sí Propuesto en borradores RFC

Cifrado

Véase también: Cifrado por bloques
Seguridad del cifrado contra ataques conocidos
Cifrado Versión del Protocolo Estado
Tipo Algoritmo Fortaleza nominal (bits) 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]​ 		TLS 1.3>[14]​
Cifrado por bloques AES GCM[15]​[note 4]​ 256, 128 N/D N/D N/D N/D Seguro Seguro Definido para TLS 1.2 en RFCs
AES CCM[16]​[note 4]​ N/D N/D N/D N/D Seguro Seguro
AES CBC[note 5]​ N/D N/D depende depende depende N/D
Camellia GCM[17]​[note 4]​ 256, 128 N/D N/D N/D N/D Seguro N/D
Camellia CBC[18]​[note 5]​ N/D N/D depende depende depende N/D
ARIA GCM 256, 128 N/D N/D N/D N/D Seguro N/D
ARIA CBC N/D N/D depende depende depende N/D
SEED CBC[19]​[note 5]​ 128 N/D N/D depende de las mitigaciones depende de las mitigaciones depende de las mitigaciones N/D
3DES EDE CBC

[note 5]​

[note 6]​

112[note 7]​ Inseguro Inseguro Inseguro Inseguro Inseguro N/D
GOST 28147-89 CNT[13]​[note 6]​ 256 N/D N/D Inseguro Inseguro Inseguro N/D Definido en IETF RFC 4357
IDEA CBC[note 5]​[note 6]​[note 8]​ 128 Inseguro Inseguro Inseguro Inseguro N/D N/D Retirado de TLS 1.2
DES CBC[note 5]​[note 6]​[note 8]​ 56 Inseguro Inseguro Inseguro Inseguro N/D N/D
40[note 9]​ Inseguro Inseguro Inseguro N/D N/D N/D Prohibidas en TLS 1.1 y posteriores
RC2 CBC[note 5]​[note 6]​ 40[note 9]​ Inseguro Inseguro Inseguro N/D N/D N/D
Cifrador de flujo ChaCha20+Poly1305[24]​[note 4]​ 256 N/D N/D N/D N/D Seguro Seguro Definido para TLS 1.2 en RFCs
RC4[note 10]​ 128 Inseguro Inseguro Inseguro Inseguro Inseguro N/D Prohibido para todas las versiones de TLS en RFC 7465
40 Inseguro Inseguro Inseguro N/D N/D N/D
Ninguno Nulo[note 11]​ – N/D Inseguro Inseguro Inseguro Inseguro N/D Definido para TLS 1.2 en los RFCs
Notas
  1. ↑ 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 librerías actuales implementan las mejoras y no se preocupan por la violación que esto causa.
  3. ↑ el ataque 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.
     
    Este artículo o sección se encuentra desactualizado.
    La información suministrada ha quedado obsoleta o es insuficiente.
    Uso de esta plantilla: {{sust:Desactualizado|tema del artículo}}
    A noviembre de 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. ↑ AEAD cifrado (como GCM y CCM) puede ser usado solo en TLS 1.2.
  5. ↑ 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.
  6. ↑ El ataque Sweet32 rompe cifrados de bloque con bloques de tamaño de 64 bits.[20]​
  7. 3DES provee solamente 108 o 112 bits de seguridad,[21]​ lo cual es menos que el mínimo recomendado de 128 bits.[22]​
  8. ↑ IDEA y DES fueron removidas de TLS 1.2.[23]​
  9. ↑ El cifrado de 40 bits fue diseñado para operar con claves reducidas y así cumplir con regulaciones de EE.UU. respecto de la exportación de software criptográfico. Estas combinaciones están prohibidas en TLS 1.1 y posteriores.
  10. los ataques RC4 debilitan o rompen el RC4 usado en SSL/TLS
  11. solo Autenticación, sin encriptación.

Integridad de datos

Se utiliza código de autenticación de mensaje (MAC, por message authentication code en inglés) para asegurar la integridad de los datos. HMAC se usa para el modo CBC de cifrado de bloques y cifrado de streams. AEAD es usado para el cifrado autenticado tales como los modos GCM y CCM.

Integridad de Datos
Algoritmo SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Estatus
HMAC-MD5 Sí Sí Sí Sí Sí Definido para TLS 1.2 en RFCs
HMAC-SHA1 No Sí Sí Sí Sí
HMAC-SHA256/384 No No No No Sí
AEAD No No No No Sí
GOST 28147-89 IMIT[13]​ No No Sí Sí Sí Propuesto en borradores de RFC
GOST R 34.11-94[13]​ No No Sí Sí Sí

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

 
Este artículo o sección se encuentra desactualizado.
La información suministrada ha quedado obsoleta o es insuficiente.
Uso de esta plantilla: {{sust:Desactualizado|tema del artículo}}

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[25]​ 		Seguridad[25]​[26]​
SSL 2.0 16.6% (-2.8%) Inseguro
SSL 3.0[n 1]​ 60.6% (-37.4%) Inseguro[27]​
TLS 1.0 99.5% (±0.2%) Depende del cifrado y de la mitigación de BEAST en el cliente[n 2]​[n 3]​[n 4]​[n 5]​
TLS 1.1 45.4% (+3.4%) Depende del cifrado[n 2]​[n 3]​[n 4]​[n 5]​
TLS 1.2 48.1% (+3.8%) Depende del cifrado[n 2]​[n 3]​[n 4]​[n 5]​
Notas
  1. 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. ↑ ver seguridad del cifrado web en la tabla de más abajo
  3. ↑ varios ataques a RC4 debilitan o rompen el RC4 usado en SSL/TLS
  4. ↑ 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 parcheado con el RFC 5746 cuando la compresión HTTP está habilitada.
  5. ↑ RFC 5746 debe estar implementado en orden a resolver un defecto en la renegociación que de otra forma podría romper el protocolo.

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]​[28]​[29]​[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í[30]​ No[31]​ No[32]​
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]​[33]​[34]​ 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]​[35]​ Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
Safari 5–6 Mac OS X, Windows (XP, Vista, 7)[notas 5]​[notas 6]​[36]​[37]​ Sí No No
Safari 7 Mac OS X 10.9[notas 5]​ Sí Sí Sí
Mobile Safari/UIWebView iOS 5.0+[notas 7]​[38]​[39]​[40]​ Sí Sí Sí
Notas
  1. ↑ 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. ↑ 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. ↑ 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. ↑ 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[41]​ 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 API exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones. Como consecuencia, los desarrolladores frecuentemente usan las API 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:[42]​

  • 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,[43]​ Mozilla Firefox 2,[44]​ Opera 9.5,[45]​ 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.[46]​ 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[47]​[48]​

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.[49]​

Hay algunos ataques contra la implementación en lugar del propio protocolo:[50]​ En las implementaciones anteriores, algunas entidades emisoras[51]​ 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 posibles conexiones 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.[52]​

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 en el cual la 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 handshake anteriores en cualquier renegociación de handshake.[53]​ 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.[54]​[55]​[56]​

Ataques de reversión de versiones

Hay modificaciones a los protocolos originales, como False Start[57]​ (aprobada y habilitada por Google Chrome[58]​) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversión de versiones para TLS[59]​ 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[60]​). 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.[61]​

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 ampliamente conocida de TLS 1.0.[50]​[51]​ Exploits prácticos de esta vulnerabilidad no se conocían, la cual fue descubierta originalmente por Phillip Rogaway[62]​ 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.[63]​

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.[64]​ Por su parte, Apple habilitó por defecto la protección contra BEAST en la versión OS X 10.9 Mavericks.[65]​

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.[66]​[67]​ 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.[68]​[69]​ 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.

Ataques de relleno

Las versiones anteriores de TLS eran vulnerables frente al ataque de relleno de oráculo descubierto en 2002. Una nueva variante, llamada Ataque Trece con suerte, fue publicada en 2013. Hasta febrero de 2013, los implementadores de TLS estaban todavía trabajando en el desarrollo de soluciones para la protección contra esta forma de ataque.

Una solución definitiva fue lanzada como la extensión Encrypt-then-MAC para TLS lanzado como RFC 7366.[70]​

Ataque POODLE

Artículo principal: Ataque POODLE

El 14 de octubre de 2014, investigadores de Google publicaron una vulnerabilidad en el diseño de SSL 3.0, lo que hace que el modo CBC de operación con SSL 3.0 sea vulnerable al ataque de relleno (CVE-2014-3566). Ellos llamaron a este ataque POODLE (en inglés, Padding Oracle On Downgraded Legacy Encryption o Relleno de oráculo en Degradación a Cifrado Obsoleto). En promedio, los atacantes solo necesitan hacer 256 peticiones SSL 3.0 para revelar un byte de mensaje cifrado.[27]​[71]​

Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admite TLS 1.0 y superiores, todos los principales navegadores rebajan voluntariamente a SSL 3.0 si los handshake con las nuevas versiones de TLS fallan a menos que proporcionan la opción para un usuario o administrador para deshabilitar SSL 3.0 y el usuario o el administrador lo haga. Por lo tanto, el hombre-en-el-medio primero debe llevar a cabo un ataque de rollback y luego aprovechar esta vulnerabilidad.[27]​[71]​

En general, la degradación de la seguridad elegante por el bien de la interoperabilidad es difícil llevar a cabo de una manera que no pueda ser explotada. Este es un reto especialmente en los dominios donde la fragmentación es alta.[72]​

Ataque RC4

A pesar de ataques existentes sobre RC4 que lo rompen, las suites de cifrado basadas en RC4 en SSL y TLS fueron consideradas seguros en un momento debido a la forma en que el sistema de cifrado se utilizaba en estos protocolos derrotaba a los ataques que rompían RC4, hasta que nuevos ataques divulgados en marzo de 2013 permitían que RC4 en TLS fuera quebrado completamente. En 2011 se recomendaba usar la suite RC4 como una solución alternativa para el ataque BEAST.[73]​ En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena solución para BEAST.[26]​ Un caso de un ataque fue propuesto por Alfardan, Bernstein, Paterson, Poettering y Schuldt que utilizaba nuevos sesgos estadísticos descubiertos en la tabla de clave RC4[74]​ para recuperar partes del texto en claro con un gran número de cifrados TLS.[75]​[76]​ Un ataque de sesgo de doble byte en RC4 en TLS y SSL que requiere 13 × 220 cifrados para romper RC4 se dio a conocer el 8 de julio de 2013, y fue descrito como "viable" en la presentación de acompañamiento en el 22ndo Simposio USENIX de Seguridad el 15 de agosto de 2013.[77]​[78]​

Sin embargo, muchos navegadores modernos han sido diseñados para derrotar los ataques BEAST (excepto Safari para Mac OS X 10.7 o versiones anteriores, para iOS 6 o anterior, y para Windows; ver navegadores). Como resultado, RC4 ya no es la mejor opción para TLS 1.0. Los sistemas de cifrado CBC que se vieron afectados por el ataque BEAST en el pasado se están convirtiendo en una opción más popular para la protección.[22]​

Microsoft recomienda deshabilitar RC4 cuando sea posible.[79]​

Ataque de truncamiento

Un ataque de truncamiento TLS bloquea las peticiones de desconexión de la cuenta de la víctima para que el usuario sin saberlo, permanezca conectado a un servicio web. Cuando se envía la solicitud de fin de sesión, el atacante inyecta un mensaje TCP FIN no cifrado (no hay más datos del remitente) para cerrar la conexión. El servidor, por tanto, no recibe la solicitud de cierre de sesión y no se da cuenta de la terminación anormal.[80]​

Publicado en julio de 2013,[81]​ el ataque provoca servicios web como Gmail y Hotmail que muestren una página que informa al usuario de que han salido correctamente del servicio, al tiempo que garantiza que el navegador del usuario mantiene la autorización con el servicio, lo que permite a un atacante tener el acceso para tomar el control de la cuenta que ha iniciado sesión en el usuario. El ataque no se basa en la instalación de malware en el ordenador de la víctima; los atacantes solo necesitan ponerse entre la víctima y el servidor web (por ejemplo, mediante la creación de un punto de acceso inalámbrico rebelde).[80]​ Esta vulnerabilidad también requiere acceso a la computadora de la víctima.

Fallo Heartbleed

Artículo principal: Heartbleed

El fallo Heartbleed es una grave vulnerabilidad en la popular librería de software criptográfica OpenSSL, que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad permite el robo de la información protegida, en condiciones normales, por el cifrado SSL / TLS que se utiliza para asegurar las cargas de datos. SSL / TLS proporciona seguridad de las comunicaciones y la privacidad a través de Internet para aplicaciones como web, correo electrónico, mensajería instantánea (IM) y algunas redes privadas virtuales (VPN).[82]​

El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL. Esto compromete las claves secretas utilizadas para identificar los proveedores de servicios y para cifrar el tráfico, los nombres y las contraseñas de los usuarios y el contenido real. Esto permite a los atacantes espiar las comunicaciones, robar datos directamente de los servicios y de los usuarios y suplantar servicios y a los usuarios.[83]​

Estudio de sitios web

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

Estudio de las vulnerabilidades de TLS de los sitios web más populares
Ataques Seguridad
Inseguro Depende Seguro Otro
Ataque
de Renegociación 		— 3.7% (−0.2%)
soporta renegociación insegura 		1.2% (±0.0%)
soporta ambos 		90.0% (+0.5%)
soporta renegociación segura 		5.1% (−0.3%)
sin soporte
Ataque RC4 1.3% (−0.1%)
permite sólo cifrados RC4 		26.6% (−0.7%)
permite cifrados RC4 usado con navegadores modernos 		53.2% (−0.7%)
soporta algunos cifrados RC4 		20.2% (+1.4%)
sin soporte 		—
Ataque BEAST
(mitigado en el lado del cliente con navegadores modernos) 		— 77.4% (+0.6%)
vulnerable 		— — —
Ataque CRIME — 7.2% (−0.4%)
vulnerable 		— — —
Heartbleed — 0.3% (−0.1%)
vulnerable 		— — —
Ataque de inyección ChangeCipherSpec — 3.3% (−0.4%)
vulnerable y explotable 		15.5% (−1.1%)
vulnerable, no explotable 		80.1% (+1.3%)
no vulnerable 		1.0% (+0.1%)
desconocido
POODLE contra TLS
(POODLE Original contra SSL 3.0 no está incluido) 		— 10.1%
vulnerable y explotable 		— 88.4%
no vulnerable 		1.6%
desconocido

Forward secrecy

Artículo principal: Perfect forward secrecy

Forward secrecy es una propiedad de los sistemas criptográficos que garantiza que una clave de sesión derivada de un conjunto de claves públicas y privadas no se verán comprometidas si una de las claves privadas se ve comprometida en el futuro.[84]​ Sin forward secrecy, si la clave privada del servidor fuera conocida, no sólo se verán comprometidas todas las sesiones cifradas-TLS futuras mediante ese certificado del servidor, sino también las sesiones anteriores que lo utilizaban (siempre por supuesto que estas sesiones pasadas fueran interceptadas y almacenadas en el momento de la transmisión).[85]​ Una implementación de TLS puede proporcionar forward secrecy al exigir el uso de intercambio de claves Diffie-Hellman efímeras para establecer claves de sesión, y algunas implementaciones TLS notables lo hacen exclusivamente: por ejemplo, Gmail y otros servicios de Google que utilizan HTTPS OpenSSL.[86]​ Sin embargo, muchos clientes y servidores que soportan TLS (incluidos los navegadores y servidores web) no están configurados para aplicar esas restricciones.[87]​[88]​ En la práctica, a menos que un servicio web utilice Diffie-Hellman para implementar forward secrecy, todo el tráfico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene la clave maestra del servidor (privado); por ejemplo, por medio de una orden judicial.[89]​

Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gestión de sesión en el servidor pueden afectar el forward secrecy. El uso de tickets de sesión TLS (una extensión TLS) hace que la sesión se deba proteger por AES128-CBC-SHA256 independientemente de cualquier otro parámetro TLS negociados, incluyendo a los conjuntos de cifrado de forward secrecy, y las llaves de los tickets de sesión de larga duración TLS estropean el intento de implementar forward secrecy.[90]​[91]​[92]​

Desde finales de 2011, Google ha proporcionado forward secrecy con TLS por omisión para los usuarios de su servicio de Gmail, junto con Google Docs y búsqueda cifrada, entre otros servicios.[93]​ Desde noviembre de 2013, Twitter ha proporcionado forward secrecy con TLS para los usuarios de su servicio.[94]​ A diciembre de 2014, el 20,0% de los sitios web habilitados para TLS están configurados para utilizar conjuntos de cifrado que proporcionan forward secrecy a los navegadores web.[25]​

Evitar Triple-DES CBC

Algunos expertos recomiendan evitar Triple-DES CBC. Debido a que RC4 y Triple-DES son los últimos cifrados soportados en las bibliotecas SSL/TLS de Windows XP, hace que sea difícil soportar SSL para programas que utilicen esta biblioteca en Windows XP. Por ejemplo en el caso de Internet Explorer para Windows XP.[22]​

Hacer frente a los ataques MITM

Artículo principal: Ataque Man-in-the-middle

Fijación de Certificados

Una forma de detectar y bloquear muchos tipos de ataques MITM es "fijar el certificado", a veces llamado "fijación SSL".[95]​

Un cliente que hace fijación de certificado agrega un paso adicional para el protocolo SSL o protocolo TLS habitual: Después de obtener el certificado del servidor en la forma estándar, el cliente comprueba el certificado del servidor con los datos de confianza para validación. Normalmente los datos de validación de confianza se incluye con la aplicación, en la forma de una copia de confianza de dicho certificado, o un hash de confianza o huella digital del certificado o la clave pública del certificado. Por ejemplo, el Chromium y Google Chrome incluyen datos de validación para el certificado *.google.com que detecta certificados fraudulentos en 2011. Desde entonces, Mozilla ha introducido fijación de certificados públicos en su navegador Firefox.[96]​

En otros sistemas que el cliente espera que la primera vez que obtenga el certificado de un servidor es de confianza y la almacena; durante las sesiones posteriores con ese servidor, el cliente comprueba el certificado del servidor contra el certificado almacenado para protegerse de los ataques MITM posteriores.

Proyecto Perspectivas

El Proyecto Perspectivas[97]​ opera notarios de red que los clientes pueden usar para detectar si el certificado de un sitio ha cambiado. Por su naturaleza, los ataques man-in-the-middle colocan al atacante entre el destino y un solo objetivo específico. Como tal, Perspectivas advertirían al objetivo de que el certificado entregado al navegador web no coincide con el certificado visto desde otras perspectivas - las perspectivas de otros usuarios en diferentes momentos y lugares. El uso de notarios de red desde una multitud de perspectivas hace posible que un objetivo detecte un ataque incluso si un certificado parece ser completamente válido.

Detalles del Protocolo

El protocolo TLS intercambia registros- los que encapsulan los datos que se intercambian en un formato específico (ver más abajo). Cada registro puede ser comprimido, cifrado y empaquetado con un código de MAC (Código de Autenticación del Mensaje), todo dependiendo del estado de la conexión. Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados, un campo de longitud y un campo de versión TLS. Los datos encapsulados pueden ser mensajes de control o de procedimiento de la propia TLS, o simplemente los datos de las aplicaciones que necesitan ser transferidos por TLS. Las especificaciones (suite de cifrado, claves, etc.) necesarios para el intercambio de datos de la aplicación por TLS, se han acordado en el "handshake TLS" entre el cliente que solicita los datos y el servidor que responde a las solicitudes. Por tanto, el protocolo define tanto la estructura de cargas útiles transferidos en TLS y el procedimiento para establecer y supervisar la transferencia.

Handshake TLS

Cuando se inicia la conexión, el registro encapsula un protocolo de "control"- el protocolo de mensajería de handshake (contenido de tipo 22). Este protocolo se utiliza para el intercambio de toda la información requerida por las dos partes para el intercambio de los datos de las aplicaciones reales por TLS. En él se definen los mensajes de formato o que contengan esta información y el orden de su intercambio. Estos pueden variar en función de las demandas del cliente y del servidor, es decir, existen varios procedimientos posibles para establecer la conexión. Este intercambio inicial resulta en una conexión exitosa TLS (ambas partes listas para transferir datos de la aplicación con TLS) o un mensaje de alerta (como se especifica más adelante).

Handshake básico

A continuación, un ejemplo simple de conexión, que ilustra un handshake en el que el servidor (pero no el cliente) es autenticado por su certificado:

  1. Fase de negociación:
    • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, una lista de conjuntos de cifrado sugeridas y métodos de compresión sugeridos. Si el cliente está intentando realizar un handshake reanudado, puede enviar un ID de sesión.
    • El servidor responde con un mensaje ServerHello, que contiene la versión del protocolo elegido, un número aleatorio, CipherSuite y método de compresión de las opciones ofrecidas por el cliente. Para confirmar o permitir handshake reanudado el servidor puede enviar un ID de sesión. La versión del protocolo elegido debe ser el más alto que tanto el soporte de cliente y servidor. Por ejemplo, si el cliente es compatible con la versión 1.1 y el servidor es compatible con la versión 1.2, la versión 1.1 se debe seleccionar; 1.0 no se debe seleccionar.
    • El servidor envía su mensaje de certificado (dependiendo de la suite de cifrado seleccionado, esto puede ser omitido por el servidor).[98]​
    • El servidor envía su mensaje ServerKeyExchange (en función del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se envía a todos los conjuntos de cifrado DHE y DH_anon.[2]​
    • El servidor envía un mensaje ServerHelloDone, lo que indica que terminó con la negociación del handshake.
    • El cliente responde con un mensaje ClientKeyExchange, que puede contener una PreMasterSecret, la clave pública, o nada. (Una vez más, esto depende de la cifra seleccionada.) Esta PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
    • El cliente y el servidor a continuación utilizan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado el "secreto principal" (master secret). Todos los demás datos clave para esta conexión se deriva de este secreto principal (y los valores aleatorios generados tanto por cliente y por servidor), que se pasan a través de una función pseudoaleatoria cuidadosamente diseñado.
  2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si los parámetros de cifrado estaban presentes en el certificado del servidor)." El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro con el tipo de contenido 20.
    • Por último, el cliente envía un mensaje autenticado y cifrado de Finished (terminado), que contiene un hash y MAC sobre los mensajes de handshake anteriores.
    • El servidor intentará descifrar el mensaje Finished del cliente y verificar el hash y MAC. Si el descifrado o verificación falla, el handshake se considera que ha fracasado y la conexión debe ser derribada.
  3. Por último, el servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrado, si el cifrado se negoció)."
    • El servidor envía su mensaje Finished autenticado y cifrado.
    • El cliente realiza el mismo descifrado y verificación.
  4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activada, con el tipo de contenido de 23. Los mensajes de aplicación intercambiados entre el cliente y el servidor también serán autenticados y opcionalmente cifrados exactamente igual que en su mensaje final. De lo contrario, el tipo de contenido contestará 25 y el cliente no va será autenticado.

Handshake TLS autenticado por el cliente

El siguiente ejemplo completo muestra un cliente siendo autenticado (además del servidor como el de más arriba) a través de TLS mediante certificados intercambiados entre ambos interlocutores.

  1. Fase de Negociación:
    • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, una lista de conjuntos de cifrado sugeridos y métodos de compresión.
    • El servidor responde con un mensaje ServerHello, que contiene la versión elegida del protocolo, un número al azar, una suite de cifrado y el método de compresión de las opciones ofrecidas por el cliente. El servidor también puede enviar un identificador de sesión como parte del mensaje para realizar un handshake reanudado.
    • El servidor envía su mensaje de certificados (dependiendo de la suite de cifrado seleccionado, esto puede ser omitido por el servidor).[98]​
    • El servidor envía su mensaje ServerKeyExchange (en función del conjunto de cifrado seleccionado, esto puede ser omitido por el servidor). Este mensaje se envía a todos los conjuntos de cifrado DHE y DH_anon.[2]​
    • El servidor solicita un certificado desde el cliente, de modo que la conexión pueda ser mutuamente autenticada, utilizando un mensaje CertificateRequest.
    • El servidor envía un mensaje ServerHelloDone, lo que indica que terminó con la negociación handshake.
    • El cliente responde con un mensaje de certificado, que contiene el certificado del cliente.
    • El cliente envía un mensaje ClientKeyExchange, que puede contener un PreMasterSecret, clave pública, o nada. (Una vez más, esto depende del cifrado seleccionado.) Esta PreMasterSecret se cifra utilizando la clave pública del certificado del servidor.
    • El cliente envía un mensaje CertificateVerify, que es una firma en los mensajes de reconocimiento anteriores utilizando la clave privada del certificado del cliente. Esta firma puede ser verificada utilizando la clave pública del certificado del cliente. Esto permite al servidor saber que el cliente tiene acceso a la clave privada del certificado y por lo tanto posee el certificado.
    • El cliente y el servidor a continuación, utilizan los números aleatorios y PreMasterSecret para calcular un secreto común, llamado el "secreto principal". Todos los demás datos clave para esta conexión se derivan de este secreto maestro (y los valores aleatorios cliente-y generados por el servidor), que se pasa a través de una función pseudoaleatoria cuidadosamente diseñada.
  2. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)." El ChangeCipherSpec es en sí mismo un protocolo a nivel de registro y es tipo 20 y no 22.
    • Por último, el cliente envía un mensaje cifrado de Finished, que contiene un hash y MAC sobre los mensajes de handshake anteriores.
    • El servidor intentará descifrar el mensaje final del cliente y verificar el hash y MAC. Si el descifrado o verificación falla, el handshake se considera que ha fracasado y la conexión debe ser derribada.
  3. Por último, el servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
    • El servidor envía su propio mensaje cifrado de Finished.
    • El cliente realiza el mismo descifrado y verificación.
  4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activado, con el tipo de contenido 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también serán cifrados exactamente igual que en su mensaje Finished.

Handshake reanudado

Las operaciones de clave pública (por ejemplo, RSA) son relativamente costosas en términos de cálculo computacional. TLS proporciona un acceso directo seguro en el mecanismo de handshake para evitar estas operaciones: reanudar sesiones. Las sesiones reanudadas se implementan utilizando los identificadores (IDs) de sesión o tickets de sesión.

Aparte de la ventaja de rendimiento, reanudando las sesiones también se puede utilizar para inicio de sesión único, ya que se garantiza que tanto la sesión original, así como cualquier sesiones reanudada se originan desde el mismo cliente. Esto es de particular importancia para el FTP sobre el protocolo TLS/SSL, ya que de lo contrario podría sufrir de un ataque man-in-the-middle en el que un atacante podría interceptar el contenido de las conexiones de datos secundarias.[99]​

IDs de sesión

En un handshake normal completo, el servidor envía un ID de sesión como parte del mensaje ServerHello. El cliente asocia este ID de sesión con la dirección IP del servidor y el puerto TCP, para que cuando el cliente se conecte de nuevo a ese servidor, puede utilizar el ID de sesión para acortar el handshake. En el servidor, el ID de sesión se asigna a los parámetros criptográficos negociados anteriormente, específicamente el "secreto maestro". Ambas partes deben tener el mismo "secreto maestro" o el handshake reanudado fallará (esto evita que un espía utilice un ID de sesión). Los datos aleatorios en los mensajes ClientHello y ServerHello prácticamente garantizan que las claves de conexión generadas serán diferentes de la conexión anterior. En las RFC, este tipo de handshake se llama un protocolo de enlace abreviado. También se describe en la literatura como un reinicio de handshake.

  1. Fase de Negociación:
    • Un cliente envía un mensaje ClientHello especificando la versión más alta de protocolo TLS que soporta, un número al azar, una lista de conjuntos de cifrado sugeridos y métodos de compresión. Incluye en el mensaje el ID de sesión de la conexión TLS previa.
    • El servidor responde con un mensaje ServerHello, que contiene la versión elegida del protocolo, un número al azar, una suite de cifrado y el método de compresión de las opciones ofrecidas por el cliente. Si el servidor reconoce el ID de sesión, responde con la misma ID de sesión. El cliente usa esto para reconocer que se está llevando a cabo una sesión reanudada. Si el servidor no reconoce el ID de sesión enviado por el cliente, responde con un valor diferente para la ID de sesión, lo cual le dice al cliente que no se llevará a cabo una reanudación de sesión. En este punto, tanto el cliente como el servidor tienen el "secreto maestro" y datos aleatorios para generar la clave usada para esta conexión.
  2. El servidor envía un ChangeCipherSpec, diciéndole al cliente, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
    • Por último, el servidor envía un mensaje cifrado de Finished, que contiene un hash y MAC sobre los mensajes de handshake anteriores.
    • El cliente realiza el mismo descifrado y verificación.
  3. El cliente ahora envía un registro ChangeCipherSpec, esencialmente diciendo al servidor, "Todo lo que yo te diga de ahora en adelante será autenticado (y cifrada si el cifrado se negoció)."
    • El cliente envía su propio mensaje cifrado de Finished.
    • El servidor intentará descifrar el mensaje final del cliente y verificar el hash y MAC.
  4. Fase de aplicación: en este punto, el "handshake" está completado y el protocolo de aplicación está activado, con el tipo de contenido 23. Los mensajes de la aplicación intercambiados entre el cliente y el servidor también serán cifrados exactamente igual que en su mensaje Finished.
Tickets de sesión

El RFC 5077 extiende TLS a través de la utilización de tickets de sesión, en lugar de los IDs de sesión. Define una forma de reanudar una sesión TLS sin necesidad de almacenar el estado específico de la sesión en el servidor TLS.

Al utilizar tickets de sesión, el servidor TLS almacena su estado específico de la sesión en un ticket de sesión y envía el ticket de sesión al cliente TLS para ser almacenado. El cliente se reanuda una sesión TLS mediante el envío del ticket de sesión al servidor, y el servidor reanuda la sesión TLS en el estado específico de la sesión en el ticket. El ticket de sesión está cifrado y autenticada por el servidor, y el servidor verifica su validez antes de utilizar su contenido.

Una debilidad particular de este método con OpenSSL es que siempre limita el cifrado y la autenticación de seguridad del ticket de sesión TLS transmitido a AES128-CBC-SHA256, no importa qué otros parámetros TLS sean negociados para la sesión actual TLS.[91]​ Esto significa que la información de estado (el ticket de sesión TLS) no está tan bien protegido como la sesión TLS misma. De particular preocupación es el almacenamiento de OpenSSL de las claves en un contexto de aplicación (SSL_CTX), es decir, que se mantiene durante la duración de la aplicación, y no permite el reingreso de información de los tickets de sesión AES128-CBC-SHA256 TLS sin reiniciar el contexto a nivel de aplicación OpenSSL (lo que es raro, propenso a errores y a menudo requiere intervención administrativa manual).[92]​[90]​

Registro TLS

Este es el formato general para todos los registros TLS.

+ Byte +0 Byte +1 Byte +2 Byte +3
Byte
0 		Tipo de Contenido  
Bytes
1..4 		Versión Largo
(Major) (Minor) (bits 15..8) (bits 7..0)
Bytes
5..(m-1) 		Mensaje(s) del Protocolo
Bytes
m..(p-1) 		MAC (opcional)
Bytes
p..(q-1) 		Relleno (cifrados de bloque solamente)
Tipo de Contenido
Este campo identifica el Tipo de Capa de Registro del Protocolo contenido en este registro.
Tipos de Contenido
Hex Dec Tipo
0x14 20 ChangeCipherSpec
0x15 21 Alerta
0x16 22 Handshake
0x17 23 Aplicación
0x18 24 Heartbeat
Versión
Este campo identifica la versión mayor y menor de TLS para el mensaje contenido. Para un mensaje ClientHello, esto no tiene por qué ser la versión más alta admitida por el cliente.
Versiones
Versión
Mayor		 Versión
Menor		 Tipo de Versión
3 0 SSL 3.0
3 1 TLS 1.0
3 2 TLS 1.1
3 3 TLS 1.2
Longitud
La longitud del mensaje del Protocolo (s), MAC y Relleno, que no exceda de 214 bytes (16 KiB).
Protocolo del Mensaje
Uno o más mensajes identificados por el campo Protocolo. Tenga en cuenta que este campo puede ser cifrado dependiendo del estado de la conexión.
MAC y Relleno
Un código de autenticación de mensaje calculado sobre el mensaje del Protocolo, con el material clave adicional incluido. Tenga en cuenta que este campo puede ser codificado, o no incluidos en su totalidad, dependiendo del estado de la conexión.
No MAC o relleno pueden estar presentes al final de los registros TLS antes de todos los algoritmos de cifrado y parámetros han sido negociados y handshaked y luego confirmado por el envío de un registro CipherStateChange (ver más abajo) para la señalización de estos parámetros tendrán efecto en todos los registros adicionales enviados por el misma pares.

Protocolo de handshake

La mayoría de los mensajes intercambiados durante la configuración de la sesión TLS se basan en este registro, a menos que un error o advertencia se produzca y necesite ser señalado por un registro de protocolo de alerta (ver más abajo), o el modo de cifrado de la sesión es modificado por otro récord (véase el protocolo ChangeCipherSpec abajo).

+ Byte +0 Byte +1 Byte +2 Byte +3
Byte
0 		22  
Bytes
1..4 		Versión Largo
(Mayor) (Menor) (bits 15..8) (bits 7..0)
Bytes
5..8 		Tipo de Mensaje Largo de los datos del mensaje de handshake
(bits 23..16) (bits 15..8) (bits 7..0)
Bytes
9..(n-1) 		Datos del mensaje de handshake
Bytes
n..(n+3) 		Tipo de Mensaje Largo de los datos del mensaje de handshake
(bits 23..16) (bits 15..8) (bits 7..0)
Bytes
(n+4).. 		Datos del mensaje de handshake
Tipo de Mensaje
Este campo identifica el tipo de mensaje del handshake.
Message Types
Código Descripción
0 HelloRequest
1 ClientHello
2 ServerHello
4 NewSessionTicket
11 Certificate
12 ServerKeyExchange
13 CertificateRequest
14 ServerHelloDone
15 CertificateVerify
16 ClientKeyExchange
20 Finished
Longitud de datos de mensajes de handshake
Este es un campo de 3 bytes que indica la longitud de los datos de handshake, no incluyendo la cabecera.

Tenga en cuenta que varios mensajes de handshake se pueden combinar dentro de un registro.

Protocolo de alertas

Este registro no debería enviarse normalmente durante los intercambios de protocolo de enlace o de aplicación normales. Sin embargo, este mensaje puede ser enviado en cualquier momento durante el handshake y hasta el cierre de la sesión. Si esto se utiliza para señalar un error fatal, la sesión se cerrará inmediatamente después de enviar este registro, por lo que este registro se utiliza para dar la razón de este cierre. Si el nivel de alerta se marca como una advertencia, el equipo remoto puede decidir cerrar la sesión si decide que la sesión no es lo suficientemente confiable para sus necesidades (antes de hacerlo, el remoto también puede enviar su propia señal).

+ Byte +0 Byte +1 Byte +2 Byte +3
Byte
0 		21  
Bytes
1..4 		Versión Largo
(Mayor) (Menor) 0 2
Bytes
5..6 		Nivel Descripción  
Bytes
7..(p-1) 		MAC (opcional)
Bytes
p..(q-1) 		Relleno (solo en cifrado de bloques)
Nivel
Este campo identifica el nivel de alerta. Si el nivel es fatal, el remitente debe cerrar la sesión inmediatamente. De lo contrario, el destinatario puede decidir terminar la sesión, mediante el envío de su propia alerta fatal y cierre de la sesión misma inmediatamente después de enviarlo. El uso de registros de alerta es opcional, sin embargo si no se encuentra antes del cierre de sesión, la sesión puede reanudarse automáticamente (con sus handshake).
El cierre normal de la sesión después de la terminación de la aplicación transportada debe ser alertado preferiblemente con al menos el tipo de alerta Close notify (con un nivel de aviso sencillo) para evitar que la nueva sesión pueda ser reanudada. La señalización explícita del cierre normal de una sesión segura antes de cerrar de manera efectiva su capa de transporte es útil para prevenir o detectar los ataques (como los intentos de truncar los datos transportados de forma segura, si es que intrínsecamente no tiene una longitud predeterminada o duración que el destinatario de los datos puede esperar).
Tipos de Nivel de Alerta
Código Tipo de Nivel Estado de Conexión
1 advertencia la conexión o la seguridad puede ser inestable.
2 fatal la conexión o la seguridad puede estar comprometida, o un error irrecuperable ha ocurrido.
Descripción
Este campo identifica cual tipo de alerta está siendo enviada.
Descripción de tipos de Alertas
Código Descripción Tipos del Nivel Notas
0 Notificación de Cierre advertencia/fatal
10 Mensaje Inesperado fatal
20 Mal registro MAC fatal Posiblemente una mala implementación de SSL, o la carga útil ha sido modificada con i.e. regla FTP de un firewall en un servidor FTPS.
21 Falla en Descifrado fatal solo TLS, reservado
22 Desbordamiento de Registro fatal solo TLS
30 Falla de Descompresión fatal
40 Falla de handshake fatal
41 Sin certificado advertencia/fatal Solo SSL 3.0, reservado
42 Certificado malo advertencia/fatal
43 Certificado no soportado advertencia/fatal por ej. el certificado tiene habilitado solo uso como autenticación de servidor y se presenta como certificado de cliente
44 Certificado revocado advertencia/fatal
45 Certificado expirado advertencia/fatal Revisar certificado del servidor expirado también revisar que algún certificado presentado en la cadena ha expirado
46 Certificado desconocido advertencia/fatal
47 parámetro ilegal fatal
48 CA (Autoridad de certificación) desconocida fatal solo TLS
49 Acceso denegado fatal solo TLS – por ej. no se ha presentado un certificado de cliente (TLS: mensaje de certificado en blanco o SSLv3: alerta de "No Certificado"), pero el servidor está configurado para requerir uno.
50 error de decodificación fatal solo TLS
51 error de descifrado advertencia/fatal solo TLS
60 Restricción de exportación fatal solo TLS, reservado
70 Versión de Protocolo fatal solo TLS
71 Seguridad Insuficiente fatal solo TLS
80 Error Interno fatal solo TLS
90 Cancelado por el Usuario fatal solo TLS
100 No renegociación advertencia solo TLS
110 Extensión No Soportada advertencia solo TLS
111 Certificado no Obtenible advertencia solo TLS
112 Nombre No Reconocido advertencia/fatal solo TLS; el Indicador de nombre del servidor del cliente especifica un host no soportado por el servidor
113 Respuesta de Mal Certificado fatal solo TLS
114 Valor de hash de Mal Certificado fatal solo TLS
115 Identidad PSK desconocida (usado en TLS-PSK y TLS-SRP) fatal solo TLS
120 Sin Protocolo de Aplicación fatal solo TLS, el ALPN del cliente ALPN no contiene ningún protocolo soportado por el servidor.

Protocolo ChangeCipherSpec

+ Byte +0 Byte +1 Byte +2 Byte +3
Byte
0 		20  
Bytes
1..4 		Versión Largo
(Mayor) (Menor) 0 1
Byte
5 		Tipo de Protocolo CCS  
Tipo de Protocolo CCS
Actualmente solo 1.

Protocolo de aplicación

+ Byte +0 Byte +1 Byte +2 Byte +3
Byte
0 		23  
Bytes
1..4 		Versión Largo
(Mayor) (Menor) (bits 15..8) (bits 7..0)
Bytes
5..(m-1) 		Datos de Aplicación
Bytes
m..(p-1) 		MAC (opcional)
Bytes
p..(q-1) 		Relleno (solo cifrado de bloques)
Largo
Largo de los datos de la aplicación (excluyendo el encabezado del protocolo e incluyendo el final de MAC y relleno)
MAC
20 bytes para el HMAC basado en SHA-1, 16 bytes para el HMAC basado en MD5.
Relleno
Largo variable; el último byte contiene el largo del relleno.

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 comodín. 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.[100]​
  • 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

TLS 1.0

Las extensiones 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.

TLS 1.1

Las extensiones 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.

TLS 1.2

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 extensiones 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)”.

TLS 1.3

  • RFC 8446,en inglés, The Transport Layer Security (TLS) Protocol Version 1.3.

Encapsulaciones

Las encapsulaciones de TLS incluyen:

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

Véase también

Referencias

  1. Dierks, T. y E. Rescorla (agosto de 2008). «The Transport Layer Security (TLS) Protocol, Version 1.2». 
  2. ↑ «RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2». Internet Engineering Task Force. Consultado el 9 de septiembre de 2013. 
  3. SSL: Intercepted today, decrypted tomorrow, Netcraft, 2013-06-25.
  4. Freier, A., P. Karlton y P. Kocher (agosto de 2011). «The Secure Sockets Layer (SSL) Protocol Version 3.0». 
  5. Kovacs, Eduard (13 de agosto de 2018). «IETF Publishes TLS 1.3 as RFC 8446». securityweek.com (en inglés). Consultado el 16 de agosto de 2018. 
  6. Woo, Thomas Y. C., Raghuram Bindignavle, Shaowen Su y Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994
  7. . Netscape Corporation. 2007. Archivado desde el original el 14 de junio de 1997. Consultado el 13 de enero de 2013. 
  8. Rescorla 2001
  9. Dierks, T. y E. Rescorla (abril de 2006). «The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346». 
  10. RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“
  11. Eronen, P. (ed.). «RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)». Internet Engineering Task Force. Consultado el 9 de septiembre de 2013. 
  12. Gothard, Peter. «Google updates SSL certificates to 2048-bit encryption». Computing. Incisive Media. Consultado el 9 de septiembre de 2013. 
  13. RFC 8446
  14. RFC 5288
  15. RFC 6655
  16. RFC 6367
  17. RFC 5932
  18. RFC 4162
  19. «On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN». 28 de octubre de 2016. desde el original el 24 de abril de 2017. Consultado el 8 de junio de 2017. 
  20. . 8 de marzo de 2007. Archivado desde el original el 6 de junio de 2014. Consultado el 3 de julio de 2014. 
  21. ↑ Qualys SSL Labs. «SSL/TLS Deployment Best Practices». desde el original el 4 de julio de 2015. Consultado el 2 de junio de 2015. 
  22. IETF RFC 5469
  23. draft-agl-tls-chacha20poly1305-04
  24. ↑ Al 6 de noviembre de 2014. . Archivado desde el original el 15 de mayo de 2017. Consultado el 11 de noviembre de 2014. 
  25. ↑ ivanr. «RC4 in TLS is Broken: Now What?». Qualsys Security Labs. Consultado el 30 de julio de 2013. 
  26. ↑ Möller, Bodo; Thai Duong y Krzysztof Kotowicz. «This POODLE Bites: Exploiting The SSL 3.0 Fallback». Consultado el 15 de octubre de 2014. 
  27. Google (29 de mayo de 2012). «Dev Channel Update». Consultado el 14 de enero de 2013. 
  28. Google (21 de agosto de 2012). «Stable Channel Update». Consultado el 14 de enero de 2013. 
  29. «Security in Firefox 2». 6 de agosto de 2008. Consultado el 14 de enero de 2013. 
  30. «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. 
  31. «Bug 480514 - Implement support for TLS 1.2 (RFC 5246)». 17 de marzo de 2010. Consultado el 14 de enero de 2013. 
  32. Microsoft (5 de septiembre de 2012). «Secure Channel». Consultado el 14 de enero de 2013. 
  33. Microsoft (27 de febrero de 2009). «MS-TLSP Appendix A». Consultado el 14 de enero de 2013. 
  34. Pettersen, Yngve Nysæter (25 de febrero de 2009). . Archivado desde el original el 4 de marzo de 2009. Consultado el 14 de enero de 2013. 
  35. Adrian, Dimcev. «Common browsers/libraries/servers and the associated cipher suites implemented». TLS Cipher Suites Project. 
  36. Apple (10 de junio de 2009). «Features». Consultado el 14 de enero de 2013. 
  37. Apple (14 de octubre de 2011). «Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues». Consultado el 14 de enero de 2013. 
  38. Liebowitz, Matt (13 de octubre de 2011). . NBCNews.com. Archivado desde el original el 28 de noviembre de 2011. Consultado el 14 de enero de 2013. 
  39. MWR Info Security (16 de abril de 2012). «Adventures with iOS UIWebviews». Consultado el 14 de enero de 2013. , section "HTTPS (SSL/TLS)"
  40. Georgiev, Martin; Iyengar, Subodh; Jana, Suman; Anubhai, Rishita; Boneh, Dan y 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. 
  41. Claessens, Joris; 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. 
  42. 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. 
  43. «Bugzilla@Mozilla — Bug 236933 – Disable SSL2 and other weak ciphers». Mozilla Corporation. Consultado el 25 de noviembre de 2007. 
  44. "Opera 9.5 for Windows Changelog" el 26 de junio de 2009 en Wayback Machine. at Opera.com: "Disabled SSL v2 and weak ciphers."
  45. «Firefox still sends SSLv2 handshake even though the protocol is disabled». 11 de septiembre de 2008. 
  46. "Opera 10 for Windows changelog" en Opera.com: "Removed support for SSL v2 and weak ciphers"
  47. Pettersen, Yngve (30 de abril de 2007). . Opera Software. Archivado desde el original el 6 de mayo de 2007. Consultado el 25 de noviembre de 2007. 
  48. National Institute of Standards and Technology (diciembre de 2010). «Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program» (en inglés). 
  49. ↑ DanGoodin (19 de septiembre de 2011). «Hackers break SSL encryption used by millions of sites». 
  50. ↑ «Y Combinator comments on the issue». 20 de septiembre de 2011. 
  51. Dimcev, Adrian. «SSL/TLS version rollbacks and browsers». Consultado el 9 de marzo de 2011. 
  52. Rescorla, Eric (5 de noviembre de 2009). «Understanding the TLS Renegotiation Attack». Educated Guesswork. Consultado el 27 de noviembre de 2009. 
  53. «SSL_CTX_set_options SECURE_RENEGOTIATION». OpenSSL Docs. 25 de febrero de 2010. Archivado desde el original el 9 de febrero de 2012. Consultado el 18 de noviembre de 2010. 
  54. «GnuTLS 2.10.0 released». GnuTLS release notes. 25 de junio de 2010. Archivado desde el original el 9 de febrero de 2012. Consultado el 24 de julio de 2011. 
  55. . NSS release notes. 3 de marzo de 2010. Archivado desde el original el 29 de junio de 2011. Consultado el 24 de julio de 2011. 
  56. Langley, A.; 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. 
  57. Wolfgang, Gruener. . Archivado desde el original el 7 de octubre de 2010. Consultado el 9 de marzo de 2011. 
  58. Brian, Smith. «Limited rollback attacks in False Start and Snap Start». Consultado el 9 de marzo de 2011. 
  59. Adrian, Dimcev. «False Start». Random SSL/TLS 101. Consultado el 9 de marzo de 2011. 
  60. Mavrogiannopoulos, Nikos; Vercautern, Frederik; Velichkov, Vesselin y 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. 
  61. «Security of CBC Ciphersuites in SSL/TLS». 20 de mayo de 2004. 
  62. Smith, Brian (30 de septiembre de 2011). «(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)». 
  63. «Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)». 10 de enero de 2012. 
  64. 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. 
  65. «Safest ciphers to use with the BEAST? (TLS 1.0 exploit)». 24 de septiembre de 2011. 
  66. «First solutions for SSL/TLS vulnerability». 26 de septiembre de 2011. 
  67. Goodin, Dan (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. 
  68. Fisher, Dennis (13 de septiembre de 2012). . ThreatPost. Archivado desde el original el 15 de septiembre de 2012. Consultado el 13 de septiembre de 2012. 
  69. Gutmann, P. (septiembre de 2014). «Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)». 
  70. ↑ Möller, Bodo (14 de octubre de 2014). «This POODLE bites: exploiting the SSL 3.0 fallback». Consultado el 15 de octubre de 2014. 
  71. Bar-El, Hagai. «Poodle flaw and IoT». Consultado el 15 de octubre de 2014. 
  72. security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault (en inglés)
  73. Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux (2011). «Discovery and Exploitation of New Biases in RC4». Lecture Notes in Computer Science 6544: 74-91. doi:10.1007/978-3-642-19574-7_5. 
  74. Green, Matthew. «Attack of the week: RC4 is kind of broken in TLS». Cryptography Engineering. Consultado el 12 de marzo de 2013. 
  75. AlFardan, Nadhem; Dan Bernstein, Kenny Paterson, Bertram Poettering y Jacob Schuldt. «On the Security of RC4 in TLS». Royal Holloway University of London. Consultado el 13 de marzo de 2013. 
  76. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 de julio de 2013). On the Security of RC4 in TLS and WPA (PDF). Consultado el 2 de septiembre de 2013. 
  77. AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 de agosto de 2013). On the Security of RC4 in TLS (PDF). 22nd USENIX Security Symposium. p. 51. Consultado el 2 de septiembre de 2013. «Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical». 
  78. Popov, Andrei (1 de octubre de 2014). «Prohibiting RC4 Cipher Suites - draft-ietf-tls-prohibiting-rc4-01». 
  79. ↑ Leyden, John (1 de agosto de 2013). «Gmail, Outlook.com and e-voting 'pwned' on stage in crypto-dodge hack». The Register. Consultado el 1 de agosto de 2013. 
  80. «BlackHat USA Briefings». Black Hat 2013. Consultado el 1 de agosto de 2013. 
  81. «Why is it called the 'Heartbleed Bug'?». 
  82. . Archivado desde el original el 5 de julio de 2014. Consultado el 25 de noviembre de 2014. 
  83. Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. (Junio de 1992). «Authentication and Authenticated Key Exchanges». Designs, Codes and Cryptography 2 (2): 107-125. doi:10.1007/BF00124891. Consultado el 11 de febrero de 2008. 
  84. . Archivado desde el original el 22 de septiembre de 2013. Consultado el 3 de enero de 2015. 
  85. «Protecting data for the long term with forward secrecy». Consultado el 5 de noviembre de 2012. 
  86. Bernat, Vincent. «SSL/TLS & Perfect Forward Secrecy». Consultado el 5 de noviembre de 2012. 
  87. «SSL Labs: Deploying Forward Secrecy». Qualys.com. 25 de junio de 2013. Consultado el 10 de julio de 2013. 
  88. Ristic, Ivan (5 de agosto de 2013). «SSL Labs: Deploying Forward Secrecy». Qualsys. Consultado el 31 de agosto de 2013. 
  89. ↑ Langley, Adam (27 de junio de 2013). «How to botch TLS forward secrecy». 
  90. ↑ Daignière, Florent. «TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL». Matta Consulting Limited. Consultado el 7 de agosto de 2013. 
  91. ↑ Daignière, Florent. «TLS "Secrets": What everyone forgot to tell you...». Matta Consulting Limited. Consultado el 7 de agosto de 2013. 
  92. «Protecting data for the long term with forward secrecy». Consultado el 7 de marzo de 2014. 
  93. Hoffman-Andrews, Jacob. «Forward Secrecy at Twitter». Twitter. Twitter. Consultado el 7 de marzo de 2014. 
  94. "Certificate Pinning" el 27 de diciembre de 2013 en Wayback Machine..
  95. "Fijación de clave pública lanzado en Firefox"
  96. Proyecto Perspectivas
  97. ↑ Estos certificados son actualmente X.509, pero el RFC 6091 también especifica el uso de certificados basados en OpenPGP.
  98. Chris (18 de febrero de 2009). «vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication». Scarybeastsecurity.blogspot.com. Consultado el 17 de mayo de 2012. 
  99. «Named-based SSL virtual hosts: how to tackle the problem» (PDF). Consultado el 17 de mayo de 2012. 

Bibliografía

  • Wagner, David y Bruce Schneier, «Analysis of the SSL 3.0 Protocol», The Second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp. 29-40.

Enlaces externos

  • Centro de información de SSL
  • (en inglés)
  • SSL: Guía de generación de CSR
  • Instructivos de instalación de Certificados SSL ordenados por plataforma
  • Test de configuración de SSL
  • Cómo generar CSR para SSL
  • Preguntas frecuentes de Certificados SSL
  •   Datos: Q206494
  •   Multimedia: SSL and TLS

Agosto 04, 2021
seguridad, capa, transporte, este, artículo, sección, necesita, wikificado, favor, edítalo, para, cumpla, convenciones, estilo, este, aviso, puesto, febrero, 2018, para, otros, usos, este, término, véase, inglés, transport, layer, security, antecesor, secure, . Este articulo o seccion necesita ser wikificado por favor editalo para que cumpla con las convenciones de estilo Este aviso fue puesto el 17 de febrero de 2018 Para otros usos de este termino vease TLS Seguridad de la capa de transporte en ingles Transport Layer Security o TLS y su antecesor Secure Sockets Layer SSL en espanol capa de puertos seguros son protocolos criptograficos que proporcionan comunicaciones seguras por una red comunmente Internet 1 Seguridad de la capa de transporteFamiliaInternetFuncionSeguridad en la capa de transporteUltima version1 3Ubicacion en la pila de protocolosAplicacion HTTPS IMAPS POP3S SMTPS Transporte TLSTCPRed IPEstandaresRFC 8446 RFC 5705 RFC 6066 otros editar datos en Wikidata Se usan certificados X 509 y por lo tanto criptografia asimetrica para autentificar a la contraparte con quien se estan comunicando 2 y para intercambiar una llave simetrica Esta sesion es luego usada para cifrar el flujo de datos entre las partes Esto permite la confidencialidad del dato mensaje codigos de autenticacion de mensajes para integridad y como un producto lateral autenticacion del mensaje Varias versiones del protocolo estan en aplicaciones ampliamente utilizadas como navegacion web correo electronico fax por Internet mensajeria instantanea y voz sobre IP VoIP Una propiedad importante en este contexto es forward secrecy para que la clave de corta vida de la sesion no pueda ser descubierta a partir de la clave asimetrica de largo plazo 3 TLS es un protocolo de Internet Engineering Task Force IETF definido por primera vez en 1999 y actualizado en el RFC 5246 agosto de 2008 y en RFC 6176 marzo de 2011 Se basa en las especificaciones previas de SSL 1994 1995 1996 desarrolladas por Netscape Communications 4 para agregar el protocolo HTTPS a su navegador Netscape Navigator Su ultima version TLS 1 3 fue definida en agosto de 2018 5 Indice 1 Descripcion 2 Historia y desarrollo 2 1 API de Secure Network Programming 2 2 SSL 3 0 2 3 TLS 1 0 2 4 TLS 1 1 2 5 TLS 1 2 2 6 TLS 1 3 3 Funcionamiento 3 1 Intercambio de claves 3 2 Cifrado 3 3 Integridad de datos 4 Aplicaciones y adopcion 4 1 Sitios web 4 2 Navegadores 4 3 Bibliotecas 4 4 Otros usos 5 Seguridad 5 1 SSL 2 0 5 2 SSL 3 0 5 3 TLS 5 4 Ataques contra SSL TLS 5 4 1 Ataque de renegociacion 5 4 2 Ataques de reversion de versiones 5 4 3 Ataque BEAST 5 4 4 Ataques CRIME y BREACH 5 4 5 Ataques de relleno 5 4 6 Ataque POODLE 5 4 7 Ataque RC4 5 4 8 Ataque de truncamiento 5 4 9 Fallo Heartbleed 5 4 10 Estudio de sitios web 5 5 Forward secrecy 5 6 Evitar Triple DES CBC 5 7 Hacer frente a los ataques MITM 5 7 1 Fijacion de Certificados 5 7 2 Proyecto Perspectivas 6 Detalles del Protocolo 6 1 Handshake TLS 6 1 1 Handshake basico 6 1 2 Handshake TLS autenticado por el cliente 6 1 3 Handshake reanudado 6 1 3 1 IDs de sesion 6 1 3 2 Tickets de sesion 6 2 Registro TLS 6 2 1 Protocolo de handshake 6 2 2 Protocolo de alertas 6 2 3 Protocolo ChangeCipherSpec 6 2 4 Protocolo de aplicacion 7 Soporte para servidores virtuales por nombre 8 Estandares 8 1 TLS 1 0 8 2 TLS 1 1 8 3 TLS 1 2 8 4 TLS 1 3 8 5 Encapsulaciones 9 Vease tambien 10 Referencias 11 Bibliografia 12 Enlaces externosDescripcion EditarSSL proporciona autenticacion y privacidad de la informacion entre extremos sobre Internet mediante el uso de criptografia Habitualmente solo el servidor es autenticado es decir se garantiza su identidad mientras que el cliente se mantiene sin autenticar SSL implica una serie de fases basicas Negociar entre las partes el algoritmo que se usara en la comunicacion Intercambio de claves publicas y autenticacion basada en certificados digitales Cifrado del trafico basado en cifrado simetrico Durante la primera fase el cliente y el servidor negocian que algoritmos criptograficos se van a usar Las implementaciones actuales proporcionan las siguientes opciones Para criptografia de clave publica RSA Diffie Hellman DSA Digital Signature Algorithm o Fortezza Para cifrado simetrico RC2 RC4 IDEA International Data Encryption Algorithm DES Data Encryption Standard Triple DES y AES Advanced Encryption Standard Con funciones hash MD5 o de la familia SHA Historia y desarrollo EditarProtocolo PublicacionSSL 1 0 No publicadoSSL 2 0 1995SSL 3 0 1996TLS 1 0 1999TLS 1 1 2006TLS 1 2 2008TLS 1 3 2018API de Secure Network Programming Editar Los primeros esfuerzos de investigacion hacia la seguridad de la capa de transporte incluyeron la interfaz de programacion de aplicaciones API por su sigla en ingles de Secure Network Programming SNP la que en 1993 exploro la posibilidad de tener una API de capa de transporte segura similar a los sockets Berkeley para facilitar la retroadaptacion de las aplicaciones de red preexistentes con medidas de seguridad 6 SSL 3 0 Editar El protocolo SSL fue desarrollado originalmente por Netscape 7 La version 1 0 nunca se entrego publicamente la version 2 0 se presento en febrero de 1995 pero contenia una cantidad de fallas de seguridad que al final llevaron al diseno de la version SSL 3 0 8 Dicha version presentada en 1996 fue un rediseno completo del protocolo producido por Paul Kocher quien trabajo con los ingenieros de Netscape Phil Karlton y Alan Freier Las versiones mas nuevas de SSL TLS estan basadas en SSL 3 0 El borrador de 1996 de SSL 3 0 fue publicado por la IETF como el historico RFC 6101 En octubre de 2014 se detecto una nueva vulnerabilidad sobre el protocolo SSL en su version 3 0 la Vulnerabilidad de Poodle TLS 1 0 Editar TLS 1 0 fue definido en el RFC 2246 en enero de 1999 y es una actualizacion de SSL version 3 0 Como dice el RFC las diferencias entre este protocolo y SSL 3 0 no son dramaticas pero son suficientemente significativas como para impedir la interoperabilidad entre TLS 1 0 y SSL 3 0 TLS 1 0 incluye una forma en la cual la implementacion puede conectarse en SSL 3 0 debilitando la seguridad TLS 1 1 Editar TLS 1 1 fue definido en el RFC 4346 en abril de 2006 9 Es una actualizacion de TLS 1 0 Las diferencias mas significativas incluyen Agrega proteccion contra ataques de CBC El vector de inicializacion IV implicito fue reemplazado por un IV explicito Cambio en el manejo de los errores de relleno Soporte para el registro de parametros de IANA TLS 1 2 Editar TLS 1 2 fue definido originalmente en el RFC 5246 en agosto del 2008 Se basa en una especificacion posterior de TLS 1 1 Las mayores diferencias son la combinacion MD5 SHA 1 en la funcion pseudoaleatoria PRF fue reemplazada por SHA 256 con la opcion de usar las PRF especificadas en la cipher suite la combinacion MD5 SHA 1 en el mensaje terminado fue reemplazada por SHA 256 sin la opcion de usar algoritmos de hash especificos para la cipher suite Sin embargo el tamano del hash en el mensaje terminado es truncado a 96 bits la combinacion 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 Expansion del soporte de cifras de cifrado autenticadas usadas mayormente para modo Galois Counter GCM y modo CCM del cifrado con Advanced Encryption Standard AES Se agregaron definicion de Extensiones de TLS y de Ciphersuites de AES TLS 1 2 fue despues redefinido en el RFC 6176 de marzo de 2011 redactando su retrocompatibilidad con SSL y TLS para que dichas sesiones jamas negocien el uso de SSL version 2 0 TLS 1 3 Editar TLS 1 3 fue definido en el RFC 8446 en agosto de 2018 Esta basado en la anterior especificacion TLS 1 2 Las principales diferencias con TLS 1 2 incluyen Un modo 0 RTT Retiro de la hora GMT Fusiona soporte de ECC del RFC 4492 pero sin curvas explicitas Retira el campo de longitud innecesaria de la entrada de AD a cifras AEAD Cambiar el nombre de Cliente Servidor KeyExchange a Cliente Servidor KeyShare Anade un HelloRetryRequest explicita para rechazar el del cliente Handshake revisado a fin de proporcionar el modo 1 RTT Retiro de grupos DHE personalizados Eliminado el soporte para la compresion Eliminado el soporte para el intercambio de claves RSA estatica y DH Eliminado el soporte para sistemas de cifrado no AEAD Funcionamiento EditarEl protocolo SSL intercambia registros opcionalmente cada registro puede ser comprimido cifrado y empaquetado con un codigo de autenticacion del mensaje MAC Cada registro tiene un campo de content type que especifica el protocolo de nivel superior que se esta usando Cuando se inicia la conexion el nivel de registro encapsula otro protocolo el protocolo handshake o protocolo de acuerdo que tiene el content type 22 El cliente envia y recibe varias estructuras handshake Envia un mensaje ClientHello especificando una lista de conjunto de cifrados metodos de compresion y la version del protocolo SSL mas alta permitida Este tambien envia bytes aleatorios que seran usados mas tarde llamados Challenge de Cliente o Reto Ademas puede incluir el identificador de la sesion Despues recibe un registro ServerHello en el que el servidor elige los parametros de conexion a partir de las opciones ofertadas con anterioridad por el cliente Cuando los parametros de la conexion son conocidos cliente y servidor intercambian certificados dependiendo de las claves publicas de cifrado seleccionadas Estos certificados son actualmente X 509 pero hay tambien un borrador especificando el uso de certificados basados en OpenPGP 10 Cliente y servidor negocian una clave secreta simetrica comun llamada master secret posiblemente usando el resultado de un intercambio Diffie Hellman o simplemente cifrando una clave secreta con una clave publica 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 traves una funcion pseudoaleatoria cuidadosamente elegida TLS SSL poseen una variedad de medidas de seguridad Numerando todos los registros y usando el numero 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 Proteccion 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 mas debiles El mensaje que finaliza el protocolo handshake Finished envia un hash de todos los datos intercambiados y vistos por ambas partes La funcion pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes MD5 y SHA despues realiza sobre ellos una operacion XOR De esta forma se protege a si mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro Intercambio de claves Editar Antes de que un cliente y el servidor pueden empezar a intercambiar informacion protegida por TLS deben intercambiar en forma segura o acordar una clave de cifrado y una clave para usar cuando se cifren los datos ver Cifrado Entre los metodos utilizados para el intercambio acuerdo de claves son las claves publicas y privadas generadas con RSA denotado TLS RSA en el protocolo de handshake TLS Diffie Hellman llamado TLS DH Diffie Hellman efimero denotado TLS DHE Diffie Hellman de Curva Eliptica denotado TLS ECDH Diffie Hellman de Curva Eliptica efimero TLS ECDHE Diffie Hellman anonimo TLS DH anon 2 y PSK TLS PSK 11 El metodo de acuerdo de claves TLS DH anon no verifica el servidor o el usuario y por lo tanto rara vez se utiliza puesto que es vulnerable a un ataque de suplantacion de identidad Solo TLS DHE y TLS ECDHE proporcionan secreto perfecto hacia adelante Los certificados de clave publica que se utilizan durante el intercambio acuerdo tambien varian en el tamano de las claves de cifrado publicas privadas utilizadas durante el intercambio y por tanto en la solidez de la seguridad que proveen En julio de 2013 Google anuncio que dejaria de utilizar claves publicas 1024 bits y cambiaria a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios 12 Autenticacion e Intercambio acuerdo de claves Algoritmo SSL 2 0 SSL 3 0 TLS 1 0 TLS 1 1 TLS 1 2 TLS 1 3 EstatusRSA Si Si Si Si Si Definido para TLS 1 2 en RFCsDH RSA No Si Si Si SiDHE RSA forward secrecy ECDH RSA No No Si Si SiECDHE RSA forward secrecy DH DSS No Si Si Si SiDHE DSS forward secrecy ECDH ECDSA No No Si Si SiECDHE ECDSA forward secrecy DH ANON inseguro No No Si Si SiECDH ANON inseguro No No Si Si SiGOST R 34 10 94 34 10 2001 13 No No Si Si Si Propuesto en borradores RFCCifrado Editar Vease tambien Cifrado por bloques Seguridad del cifrado contra ataques conocidos Cifrado Version del Protocolo EstadoTipo Algoritmo Fortaleza nominal bits 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 TLS 1 3 gt 14 Cifrado por bloques AES GCM 15 note 4 256 128 N D N D N D N D Seguro Seguro Definido para TLS 1 2 en RFCsAES CCM 16 note 4 N D N D N D N D Seguro SeguroAES CBC note 5 N D N D depende depende depende N DCamellia GCM 17 note 4 256 128 N D N D N D N D Seguro N DCamellia CBC 18 note 5 N D N D depende depende depende N DARIA GCM 256 128 N D N D N D N D Seguro N DARIA CBC N D N D depende depende depende N DSEED CBC 19 note 5 128 N D N D depende de las mitigaciones depende de las mitigaciones depende de las mitigaciones N D3DES EDE CBC note 5 note 6 112 note 7 Inseguro Inseguro Inseguro Inseguro Inseguro N DGOST 28147 89 CNT 13 note 6 256 N D N D Inseguro Inseguro Inseguro N D Definido en IETF RFC 4357IDEA CBC note 5 note 6 note 8 128 Inseguro Inseguro Inseguro Inseguro N D N D Retirado de TLS 1 2DES CBC note 5 note 6 note 8 56 Inseguro Inseguro Inseguro Inseguro N D N D40 note 9 Inseguro Inseguro Inseguro N D N D N D Prohibidas en TLS 1 1 y posterioresRC2 CBC note 5 note 6 40 note 9 Inseguro Inseguro Inseguro N D N D N DCifrador de flujo ChaCha20 Poly1305 24 note 4 256 N D N D N D N D Seguro Seguro Definido para TLS 1 2 en RFCsRC4 note 10 128 Inseguro Inseguro Inseguro Inseguro Inseguro N D Prohibido para todas las versiones de TLS en RFC 746540 Inseguro Inseguro Inseguro N D N D N DNinguno Nulo note 11 N D Inseguro Inseguro Inseguro Inseguro N D Definido para TLS 1 2 en los RFCsNotas a b c d RFC 5746 debe estar implementado para solucionar una falla en la renegociacion que de otra forma rompe este protocolo Si las librerias implementan las mejoras listadas en el RFC 5746 esto violaria la especificacion SSL 3 0 la que la IETF no puede cambiar a diferencia de TLS Afortunadamente la mayoria de las librerias actuales implementan las mejoras y no se preocupan por la violacion que esto causa a b el ataque 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 Este articulo o seccion se encuentra desactualizado La informacion suministrada ha quedado obsoleta o es insuficiente Uso de esta plantilla sust Desactualizado tema del articulo A noviembre de 2013 Apple ha activado la mitigacion 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 todavia son teoricamente vulnerables al ataque BEAST en estas plataformas ver Navegadores a b c d AEAD cifrado como GCM y CCM puede ser usado solo en TLS 1 2 a b c d e f g El cifrado CBC puede ser atacado con el Ataque Trece con suerte si la libreria no esta escrita cuidadosamente para eliminar el timing de canales laterales a b c d e El ataque Sweet32 rompe cifrados de bloque con bloques de tamano de 64 bits 20 3DES provee solamente 108 o 112 bits de seguridad 21 lo cual es menos que el minimo recomendado de 128 bits 22 a b IDEA y DES fueron removidas de TLS 1 2 23 a b El cifrado de 40 bits fue disenado para operar con claves reducidas y asi cumplir con regulaciones de EE UU respecto de la exportacion de software criptografico Estas combinaciones estan prohibidas en TLS 1 1 y posteriores los ataques RC4 debilitan o rompen el RC4 usado en SSL TLS solo Autenticacion sin encriptacion Integridad de datos Editar Se utiliza codigo de autenticacion de mensaje MAC por message authentication code en ingles para asegurar la integridad de los datos HMAC se usa para el modo CBC de cifrado de bloques y cifrado de streams AEAD es usado para el cifrado autenticado tales como los modos GCM y CCM Integridad de Datos Algoritmo SSL 2 0 SSL 3 0 TLS 1 0 TLS 1 1 TLS 1 2 TLS 1 3 EstatusHMAC MD5 Si Si Si Si Si Definido para TLS 1 2 en RFCsHMAC SHA1 No Si Si Si SiHMAC SHA256 384 No No No No SiAEAD No No No No SiGOST 28147 89 IMIT 13 No No Si Si Si Propuesto en borradores de RFCGOST R 34 11 94 13 No No Si Si SiAplicaciones y adopcion EditarSSL se ejecuta en una capa entre los protocolos de aplicacion 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 Editar Este articulo o seccion se encuentra desactualizado La informacion suministrada ha quedado obsoleta o es insuficiente Uso de esta plantilla sust Desactualizado tema del articulo Uno de los usos mas importantes es junto a HTTP para formar HTTPS HTTPS es usado para asegurar paginas World Wide Web para aplicaciones de comercio electronico utilizando certificados de clave publica para verificar la identidad de los extremos Soporte de protocolo de sitios web Version delProtocolo Soporte enSitios Web 25 Seguridad 25 26 SSL 2 0 16 6 2 8 InseguroSSL 3 0 n 1 60 6 37 4 Inseguro 27 TLS 1 0 99 5 0 2 Depende del cifrado y de la mitigacion de BEAST en el cliente n 2 n 3 n 4 n 5 TLS 1 1 45 4 3 4 Depende del cifrado n 2 n 3 n 4 n 5 TLS 1 2 48 1 3 8 Depende del cifrado n 2 n 3 n 4 n 5 Notas La falla de renegociacion insegura rompe este protocolo Si las librerias implementan las mejoras listadas en el RFC 5746 esto violaria la especificacion SSL 3 0 la que la IETF no puede cambiar a diferencia de TLS Afortunadamente la mayoria de las librarias actuales implementan las mejoras y no se preocupan por la violacion que esto causa a b c ver seguridad del cifrado web en la tabla de mas abajo a b c varios ataques a RC4 debilitan o rompen el RC4 usado en SSL TLS a b c el ataque CRIME significa que la compresion TLS no es segura y que el ataque BREACH que requiere compresion HTTP puede ser usado para vencer la seguridad tanto de TLS y de SSL 3 0 que sea parcheado con el RFC 5746 cuando la compresion HTTP esta habilitada a b c RFC 5746 debe estar implementado en orden a resolver un defecto en la renegociacion que de otra forma podria romper el protocolo Navegadores Editar Todos los navegadores importantes soportan TLS Soporte de TLS en navegadores Navegador Plataforma TLS 1 0 TLS 1 1 TLS 1 2Chrome 0 22 Linux Mac OS X Windows XP Vista 7 8 notas 1 28 29 notas 2 Si No NoChrome 22 29 Linux Mac OS X Windows XP Vista 7 8 notas 1 notas 2 Si Si NoChrome 30 Linux Mac OS X Windows XP Vista 7 8 notas 1 notas 2 Si Si SiFirefox 2 Linux Mac OS X Windows XP Vista 7 8 notas 2 Si 30 No 31 No 32 Firefox 27 Linux Mac OS X Windows XP Vista 7 8 notas 1 notas 2 Si Si SiIE 1 7 Mac OS X Windows XP Vista 7 notas 3 33 34 Si No NoIE 8 Windows XP Vista notas 3 Si No NoIE 8 9 Windows 7 notas 3 Si Si deshabilitada por defecto Si deshabilitada por defectoIE 9 Windows Vista notas 3 Si No NoIE 10 Windows 7 8 notas 3 Si Si deshabilitada por defecto Si deshabilitada por defectoIE 11 Windows 7 8 1 notas 3 Si Si SiOpera 10 Linux Mac OS X Windows notas 4 35 Si Si deshabilitada por defecto Si deshabilitada por defectoSafari 5 6 Mac OS X Windows XP Vista 7 notas 5 notas 6 36 37 Si No NoSafari 7 Mac OS X 10 9 notas 5 Si Si SiMobile Safari UIWebView iOS 5 0 notas 7 38 39 40 Si Si SiNotas a b c d El navegador Google Chrome y Chromium soportan TLS 1 0 y TLS 1 1 desde la version 22 se agrego luego se bajo desde la version 21 TLS 1 2 no es compatible a b c d e Utiliza la implementacion TLS proporcionada por NSS A noviembre de 2012 NSS soporta TLS 1 0 y 1 1 pero no 1 2 actualizar a b c d e f IE utiliza la implementacion TLS del sistema operativo Microsoft Windows proporcionada por el proveedor soporte de seguridad SChannel TLS 1 1 y 1 2 estan deshabilitadas por defecto Hasta Presto 2 2 que aparece en Opera 10 Opera anade soporte para TLS 1 2 despues de soportar previamente 1 0 y 1 1 a b Safari utiliza la implementacion del sistema operativo Mac OS X Windows XP Vista 7 con version desconocida Safari 5 es la ultima version disponible para Windows Mobile Safari y software de terceros que utilizan el sistema UIWebView biblioteca utiliza el sistema operativo iOS aplicacion que admite TLS 1 2 Desde de iOS 5 0 Bibliotecas Editar SSL y TLS han sido implementados ampliamente en varios proyectos de software abierto y libre Los programadores pueden usar las librerias PolarSSL CyaSSL OpenSSL MatrixSSL NSS o GnuTLS para tener funcionalidad SSL TLS Microsoft Windows incluye una implementacion de SSL y TLS como parte de su paquete Secure Channel OS X incluye una implementacion de SSL y TLS como parte de su paquete Secure Transport Los programadores de Delphi pueden usar una libreria llamada Indy OpenSSL es una implementacion libre Tiene una licencia BSD con algunas extensiones GnuTLS es una implementacion libre con licencia LGPL Zodiac TLS SSL es una implementacion para Smalltalk con licencia MIT cryptlib es libreria criptografica potable de software abierto que incluye una implementacion de SSL TLS JSSE una implementacion Java incluida en el Java Runtime Environment que soporta TLS 1 1 y 1 2 desde Java 7 aunque esta por defecto deshabilitada para el cliente y habilitada en el servidor MatrixSSL una implementacion con licencia dual Network Security Services NSS es una libreria open source validada para FIPS 140 PolarSSL es una implementacion SSL TLS muy pequena para dispositivos embebidos que esta disenada para uso facil CyaSSL es una libreria SSL TLS embebida con fuerte foco en velocidad y tamano Un ensayo presentado en la conferencia ACM 2012 de seguridad de computadores y comunicaciones 41 mostro que muchas aplicaciones utilizaban estas librerias incorrectamente llevando a vulnerabilidad Los autores hacian notar que la causa principal de la mayoria de estas vulnerabilidad es el terrible diseno de las APIs para las librerias subyacentes En vez de expresar propiedades de seguridad alto nivel para tuneles de red tales como confidencialidad y autenticacion estas API exponen detalles de bajo nivel del protocolo SSL a los desarrolladores de aplicaciones Como consecuencia los desarrolladores frecuentemente usan las API de SSL incorrectamente malinterpretando y malentendiendo los posibles parametros opciones efectos colaterales y valores de retorno Otros usos Editar Otra aplicacion con creciente uso de TLS es SMTP TLS es tambien el metodo estandar para proteger la senalizacion de aplicaciones con Session Initiation Protocol SIP TLS se puede utilizar para proveer autenticacion y cifrado a la senalizacion asociada con VoIP y otras aplicaciones basadas en SIP Aunque un numero creciente de productos clientes y servidores pueden proporcionar SSL de forma nativa muchos aun no lo permiten En estos casos un usuario podria querer usar una aplicacion SSL independiente como Stunnel para proporcionar cifrado No obstante el Internet Engineering Task Force recomendo en 1997 que los protocolos de aplicacion ofrecieran una forma de actualizar a TLS a partir de una conexion sin cifrado plaintext en vez de usar un puerto diferente para cifrar las comunicaciones esto evitaria el uso de envolturas wrappers como Stunnel SSL tambien puede ser usado para tunelizar una red completa y crear una red privada virtual VPN como en el caso de OpenVPN Seguridad EditarSSL 2 0 Editar SSL 2 0 tiene una variedad de fallas 42 Claves criptograficas identicas se utilizan para la autenticacion de mensajes y el cifrado SSL 2 0 tiene una construccion MAC debil que utiliza la funcion hash MD5 con un prefijo secreto por lo que es vulnerable a los ataques de extension de longitud SSL 2 0 no tiene ningun tipo de proteccion 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 conexion 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 ilegitimo de mensaje de datos SSL 3 0 soluciona este problema al tener una alerta de cierre explicita SSL 2 0 asume un solo servicio y un certificado de dominio fijo que choca con una funcion estandar de hosting virtual en los servidores Web Esto significa que la mayoria de los sitios web estan practicamente afectados por el uso de SSL SSL 2 0 esta desactivado por defecto a partir de Internet Explorer 7 43 Mozilla Firefox 2 44 Opera 9 5 45 y Safari Despues de que se envia un ClientHello TLS si Mozilla Firefox comprueba que el servidor no puede completar el handshake intentara volver a caer a la utilizacion de SSL 3 0 con un SSL 3 0 ClientHello en formato SSL 2 0 para maximizar la probabilidad de exito del handshake con los servidores mas antiguos 46 Permitir SSL 2 0 y sistemas de cifrado debiles de 40 y 56 bits ha sido completamente eliminado de Opera desde la version 10 47 48 SSL 3 0 Editar SSL 3 0 mejoro SSL 2 0 mediante la adicion de cifrado SHA 1 y soporte para autenticacion de certificados Desde el punto de vista de seguridad SSL 3 0 deberia considerarse menos deseable que TLS 1 0 Las suites de cifrado de SSL 3 0 tienen un proceso de derivacion de claves debiles la mitad de la llave maestra que se establece es totalmente dependiente de la funcion 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 derivacion no esta actualmente considerado debil Es por esta razon que las implementaciones SSL 3 0 no pueden ser validados bajo FIPS 140 2 49 Hay algunos ataques contra la implementacion en lugar del propio protocolo 50 En las implementaciones anteriores algunas entidades emisoras 51 no establecieron explicitamente basicConstraintsCA False para los nodos hoja Como resultado estos nodos hoja podian firmar certificados piratas Ademas algunos programas de incluyendo IE6 y Konqueror no comprobo este campo para nada Esto puede ser explotado en ataques man in the middle a todas las posibles conexiones 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 caracter nulo en el campo del nombre del certificado lo que puede ser explotado para enganar al cliente en la lectura del certificado como si fuera originado en el sitio autentico Por ejemplo PayPal com 0 badguy com seria confundido como proveniente del sitio PayPal com en lugar de badguy com Los navegadores implementaron mecanismos de degradacion del protocolo a una version anterior en SSL TLS por razones de compatibilidad La proteccion ofrecida por los protocolos SSL TLS contra un downgrade a una version anterior de un ataque man in the middle activo puede ser inutilizados por tales mecanismos 52 TLS Editar TLS tiene una variedad de medidas de seguridad Proteccion contra una degradacion del protocolo a una version anterior menos segura o un conjunto de cifrado mas debil Numeracion de los registros de aplicacion posteriores con un numero de secuencia y el uso de este numero de secuencia en los codigos de autenticacion de mensajes MAC Usando un resumen de mensaje mejorado con una clave por lo que solo una llave sostenedor puede comprobar el MAC La construccion HMAC utilizado por la mayoria 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 envia un hash de todos los mensajes intercambiados handshake vistos por ambas partes La funcion 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 proteccion incluso si uno de estos algoritmos resulta ser vulnerable Ataques contra SSL TLS Editar Los ataques mas significativos se mencionan mas abajo Ataque de renegociacion Editar Una vulnerabilidad del procedimiento en el cual la renegociacion fue descubierto en agosto de 2009 que puede conducir a ataques de inyeccion de texto plano contra SSL 3 0 y todas las versiones actuales de TLS Por ejemplo permite a un atacante que puede secuestrar una conexion https para empalmar sus propias peticiones en el inicio de la conversacion que el cliente tiene con el servidor web El atacante no puede realmente descifrar la comunicacion cliente servidor por lo que es diferente de un tipico ataque man in the middle Una solucion a corto plazo es que los servidores de Internet dejen de permitir la renegociacion que normalmente no requerira otros cambios a menos que se utilice la autenticacion de certificados de cliente Para corregir la vulnerabilidad una extension de la indicacion de renegociacion fue propuesta para TLS Se requerira que el cliente y el servidor incluyan y verifiquen informacion acerca de los handshake anteriores en cualquier renegociacion de handshake 53 Esta extension se ha convertido en una norma propuesta y se le ha asignado el numero de RFC 5746 El RFC ha sido implementado por varias bibliotecas 54 55 56 Ataques de reversion de versiones Editar Hay modificaciones a los protocolos originales como False Start 57 aprobada y habilitada por Google Chrome 58 o Snap Start en las que se ha reportado que han introducido limitaciones a los ataques de reversion de versiones para TLS 59 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 seleccion de la suite de cifrado en un intento de rebajar la intensidad de juego de cifrado ya sea para usar un algoritmo de cifrado simetrico mas debil o de un intercambio de clave mas debil 60 Se ha demostrado en la conferencia sobre seguridad informatica y de comunicaciones de la Association for Computing Machinery ACM que la extension False Start esta en riesgo bajo ciertas circunstancias lo que podria permitir a un atacante recuperar las claves de cifrado en linea y acceder a los datos cifrados 61 Ataque BEAST Editar 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 politicas de mismo origen por una vulnerabilidad de CBC ampliamente conocida de TLS 1 0 50 51 Exploits practicos de esta vulnerabilidad no se conocian la cual fue descubierta originalmente por Phillip Rogaway 62 en 2002 Mozilla actualizo las versiones de desarrollo de sus librerias NSS para mitigar ataques de tipo BEAST NSS es utilizado por Mozilla Firefox y por Google Chrome para su implementacion de SSL Algunos servidores web que tienen una implementacion quebrada de la especificacion SSL puede que dejen de funcionar como resultado de esto 63 Microsoft emitio el boletin de seguridad MS12 006 el 12 de enero de 2012 que corrigio la vulnerabilidad BEAST al cambiar la forma en que el componente de Windows Secure Channel SChannel transmite los paquetes cifrados 64 Por su parte Apple habilito por defecto la proteccion contra BEAST en la version OS X 10 9 Mavericks 65 El ataque BEAST tambien 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 mayoria de los sitios web 66 67 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 fallara si no es soportado tambien por el otro extremo de la conexion y caera a TLS 1 0 Ataques CRIME y BREACH Editar Articulos principales CRIMEy BREACH ataque Los autores del ataque BEAST tambien son los creadores del ataque CRIME que usa compresion de datos para adivinar 68 69 Cuando se utiliza para recuperar el contenido de la cookie de autenticacion secreta permite a un atacante realizar un secuestro de sesion en una sesion web autenticada Ataques de relleno Editar Las versiones anteriores de TLS eran vulnerables frente al ataque de relleno de oraculo descubierto en 2002 Una nueva variante llamada Ataque Trece con suerte fue publicada en 2013 Hasta febrero de 2013 los implementadores de TLS estaban todavia trabajando en el desarrollo de soluciones para la proteccion contra esta forma de ataque Una solucion definitiva fue lanzada como la extension Encrypt then MAC para TLS lanzado como RFC 7366 70 Ataque POODLE Editar Articulo principal Ataque POODLE El 14 de octubre de 2014 investigadores de Google publicaron una vulnerabilidad en el diseno de SSL 3 0 lo que hace que el modo CBC de operacion con SSL 3 0 sea vulnerable al ataque de relleno CVE 2014 3566 Ellos llamaron a este ataque POODLE en ingles Padding Oracle On Downgraded Legacy Encryption o Relleno de oraculo en Degradacion a Cifrado Obsoleto En promedio los atacantes solo necesitan hacer 256 peticiones SSL 3 0 para revelar un byte de mensaje cifrado 27 71 Aunque esta vulnerabilidad solo existe en SSL 3 0 y la mayoria de los clientes y servidores admite TLS 1 0 y superiores todos los principales navegadores rebajan voluntariamente a SSL 3 0 si los handshake con las nuevas versiones de TLS fallan a menos que proporcionan la opcion para un usuario o administrador para deshabilitar SSL 3 0 y el usuario o el administrador lo haga Por lo tanto el hombre en el medio primero debe llevar a cabo un ataque de rollback y luego aprovechar esta vulnerabilidad 27 71 En general la degradacion de la seguridad elegante por el bien de la interoperabilidad es dificil llevar a cabo de una manera que no pueda ser explotada Este es un reto especialmente en los dominios donde la fragmentacion es alta 72 Ataque RC4 Editar A pesar de ataques existentes sobre RC4 que lo rompen las suites de cifrado basadas en RC4 en SSL y TLS fueron consideradas seguros en un momento debido a la forma en que el sistema de cifrado se utilizaba en estos protocolos derrotaba a los ataques que rompian RC4 hasta que nuevos ataques divulgados en marzo de 2013 permitian que RC4 en TLS fuera quebrado completamente En 2011 se recomendaba usar la suite RC4 como una solucion alternativa para el ataque BEAST 73 En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena solucion para BEAST 26 Un caso de un ataque fue propuesto por Alfardan Bernstein Paterson Poettering y Schuldt que utilizaba nuevos sesgos estadisticos descubiertos en la tabla de clave RC4 74 para recuperar partes del texto en claro con un gran numero de cifrados TLS 75 76 Un ataque de sesgo de doble byte en RC4 en TLS y SSL que requiere 13 220 cifrados para romper RC4 se dio a conocer el 8 de julio de 2013 y fue descrito como viable en la presentacion de acompanamiento en el 22ndo Simposio USENIX de Seguridad el 15 de agosto de 2013 77 78 Sin embargo muchos navegadores modernos han sido disenados para derrotar los ataques BEAST excepto Safari para Mac OS X 10 7 o versiones anteriores para iOS 6 o anterior y para Windows ver navegadores Como resultado RC4 ya no es la mejor opcion para TLS 1 0 Los sistemas de cifrado CBC que se vieron afectados por el ataque BEAST en el pasado se estan convirtiendo en una opcion mas popular para la proteccion 22 Microsoft recomienda deshabilitar RC4 cuando sea posible 79 Ataque de truncamiento Editar Un ataque de truncamiento TLS bloquea las peticiones de desconexion de la cuenta de la victima para que el usuario sin saberlo permanezca conectado a un servicio web Cuando se envia la solicitud de fin de sesion el atacante inyecta un mensaje TCP FIN no cifrado no hay mas datos del remitente para cerrar la conexion El servidor por tanto no recibe la solicitud de cierre de sesion y no se da cuenta de la terminacion anormal 80 Publicado en julio de 2013 81 el ataque provoca servicios web como Gmail y Hotmail que muestren una pagina que informa al usuario de que han salido correctamente del servicio al tiempo que garantiza que el navegador del usuario mantiene la autorizacion con el servicio lo que permite a un atacante tener el acceso para tomar el control de la cuenta que ha iniciado sesion en el usuario El ataque no se basa en la instalacion de malware en el ordenador de la victima los atacantes solo necesitan ponerse entre la victima y el servidor web por ejemplo mediante la creacion de un punto de acceso inalambrico rebelde 80 Esta vulnerabilidad tambien requiere acceso a la computadora de la victima Fallo Heartbleed Editar Articulo principal Heartbleed El fallo Heartbleed es una grave vulnerabilidad en la popular libreria de software criptografica OpenSSL que afecta a las versiones 1 0 1 a 1 0 1f Esta debilidad permite el robo de la informacion protegida en condiciones normales por el cifrado SSL TLS que se utiliza para asegurar las cargas de datos SSL TLS proporciona seguridad de las comunicaciones y la privacidad a traves de Internet para aplicaciones como web correo electronico mensajeria instantanea IM y algunas redes privadas virtuales VPN 82 El fallo Heartbleed permite a cualquier persona en Internet leer la memoria de los sistemas protegidos por las versiones vulnerables del software OpenSSL Esto compromete las claves secretas utilizadas para identificar los proveedores de servicios y para cifrar el trafico los nombres y las contrasenas de los usuarios y el contenido real Esto permite a los atacantes espiar las comunicaciones robar datos directamente de los servicios y de los usuarios y suplantar servicios y a los usuarios 83 Estudio de sitios web Editar A diciembre de 2014 Trustworthy Internet Movement estima que la proporcion de sitios web que son vulnerable a ataques TLS 25 Estudio de las vulnerabilidades de TLS de los sitios web mas populares Ataques SeguridadInseguro Depende Seguro OtroAtaquede Renegociacion 3 7 0 2 soporta renegociacion insegura 1 2 0 0 soporta ambos 90 0 0 5 soporta renegociacion segura 5 1 0 3 sin soporteAtaque RC4 1 3 0 1 permite solo cifrados RC4 26 6 0 7 permite cifrados RC4 usado con navegadores modernos 53 2 0 7 soporta algunos cifrados RC4 20 2 1 4 sin soporte Ataque BEAST mitigado en el lado del cliente con navegadores modernos 77 4 0 6 vulnerable Ataque CRIME 7 2 0 4 vulnerable Heartbleed 0 3 0 1 vulnerable Ataque de inyeccion ChangeCipherSpec 3 3 0 4 vulnerable y explotable 15 5 1 1 vulnerable no explotable 80 1 1 3 no vulnerable 1 0 0 1 desconocidoPOODLE contra TLS POODLE Original contra SSL 3 0 no esta incluido 10 1 vulnerable y explotable 88 4 no vulnerable 1 6 desconocidoForward secrecy Editar Articulo principal Perfect forward secrecy Forward secrecy es una propiedad de los sistemas criptograficos que garantiza que una clave de sesion derivada de un conjunto de claves publicas y privadas no se veran comprometidas si una de las claves privadas se ve comprometida en el futuro 84 Sin forward secrecy si la clave privada del servidor fuera conocida no solo se veran comprometidas todas las sesiones cifradas TLS futuras mediante ese certificado del servidor sino tambien las sesiones anteriores que lo utilizaban siempre por supuesto que estas sesiones pasadas fueran interceptadas y almacenadas en el momento de la transmision 85 Una implementacion de TLS puede proporcionar forward secrecy al exigir el uso de intercambio de claves Diffie Hellman efimeras para establecer claves de sesion y algunas implementaciones TLS notables lo hacen exclusivamente por ejemplo Gmail y otros servicios de Google que utilizan HTTPS OpenSSL 86 Sin embargo muchos clientes y servidores que soportan TLS incluidos los navegadores y servidores web no estan configurados para aplicar esas restricciones 87 88 En la practica a menos que un servicio web utilice Diffie Hellman para implementar forward secrecy todo el trafico web cifrado hacia y desde ese servicio puede ser descifrado por un tercero si obtiene la clave maestra del servidor privado por ejemplo por medio de una orden judicial 89 Incluso cuando se implementa el intercambio de claves Diffie Hellman los mecanismos de gestion de sesion en el servidor pueden afectar el forward secrecy El uso de tickets de sesion TLS una extension TLS hace que la sesion se deba proteger por AES128 CBC SHA256 independientemente de cualquier otro parametro TLS negociados incluyendo a los conjuntos de cifrado de forward secrecy y las llaves de los tickets de sesion de larga duracion TLS estropean el intento de implementar forward secrecy 90 91 92 Desde finales de 2011 Google ha proporcionado forward secrecy con TLS por omision para los usuarios de su servicio de Gmail junto con Google Docs y busqueda cifrada entre otros servicios 93 Desde noviembre de 2013 Twitter ha proporcionado forward secrecy con TLS para los usuarios de su servicio 94 A diciembre de 2014 el 20 0 de los sitios web habilitados para TLS estan configurados para utilizar conjuntos de cifrado que proporcionan forward secrecy a los navegadores web 25 Evitar Triple DES CBC Editar Algunos expertos recomiendan evitar Triple DES CBC Debido a que RC4 y Triple DES son los ultimos cifrados soportados en las bibliotecas SSL TLS de Windows XP hace que sea dificil soportar SSL para programas que utilicen esta biblioteca en Windows XP Por ejemplo en el caso de Internet Explorer para Windows XP 22 Hacer frente a los ataques MITM Editar Articulo principal Ataque Man in the middle Fijacion de Certificados Editar Una forma de detectar y bloquear muchos tipos de ataques MITM es fijar el certificado a veces llamado fijacion SSL 95 Un cliente que hace fijacion de certificado agrega un paso adicional para el protocolo SSL o protocolo TLS habitual Despues de obtener el certificado del servidor en la forma estandar el cliente comprueba el certificado del servidor con los datos de confianza para validacion Normalmente los datos de validacion de confianza se incluye con la aplicacion en la forma de una copia de confianza de dicho certificado o un hash de confianza o huella digital del certificado o la clave publica del certificado Por ejemplo el Chromium y Google Chrome incluyen datos de validacion para el certificado google com que detecta certificados fraudulentos en 2011 Desde entonces Mozilla ha introducido fijacion de certificados publicos en su navegador Firefox 96 En otros sistemas que el cliente espera que la primera vez que obtenga el certificado de un servidor es de confianza y la almacena durante las sesiones posteriores con ese servidor el cliente comprueba el certificado del servidor contra el certificado almacenado para protegerse de los ataques MITM posteriores Proyecto Perspectivas Editar El Proyecto Perspectivas 97 opera notarios de red que los clientes pueden usar para detectar si el certificado de un sitio ha cambiado Por su naturaleza los ataques man in the middle colocan al atacante entre el destino y un solo objetivo especifico Como tal Perspectivas advertirian al objetivo de que el certificado entregado al navegador web no coincide con el certificado visto desde otras perspectivas las perspectivas de otros usuarios en diferentes momentos y lugares El uso de notarios de red desde una multitud de perspectivas hace posible que un objetivo detecte un ataque incluso si un certificado parece ser completamente valido Detalles del Protocolo EditarEl protocolo TLS intercambia registros los que encapsulan los datos que se intercambian en un formato especifico ver mas abajo Cada registro puede ser comprimido cifrado y empaquetado con un codigo de MAC Codigo de Autenticacion del Mensaje todo dependiendo del estado de la conexion Cada registro tiene un campo de tipo de contenido que designa el tipo de datos encapsulados un campo de longitud y un campo de version TLS Los datos encapsulados pueden ser mensajes de control o de procedimiento de la propia TLS o simplemente los datos de las aplicaciones que necesitan ser transferidos por TLS Las especificaciones suite de cifrado claves etc necesarios para el intercambio de datos de la aplicacion por TLS se han acordado en el handshake TLS entre el cliente que solicita los datos y el servidor que responde a las solicitudes Por tanto el protocolo define tanto la estructura de cargas utiles transferidos en TLS y el procedimiento para establecer y supervisar la transferencia Handshake TLS Editar Cuando se inicia la conexion el registro encapsula un protocolo de control el protocolo de mensajeria de handshake contenido de tipo 22 Este protocolo se utiliza para el intercambio de toda la informacion requerida por las dos partes para el intercambio de los datos de las aplicaciones reales por TLS En el se definen los mensajes de formato o que contengan esta informacion y el orden de su intercambio Estos pueden variar en funcion de las demandas del cliente y del servidor es decir existen varios procedimientos posibles para establecer la conexion Este intercambio inicial resulta en una conexion exitosa TLS ambas partes listas para transferir datos de la aplicacion con TLS o un mensaje de alerta como se especifica mas adelante Handshake basico Editar A continuacion un ejemplo simple de conexion que ilustra un handshake en el que el servidor pero no el cliente es autenticado por su certificado Fase de negociacion Un cliente envia un mensaje ClientHello especificando la version mas alta de protocolo TLS que soporta un numero al azar una lista de conjuntos de cifrado sugeridas y metodos de compresion sugeridos Si el cliente esta intentando realizar un handshake reanudado puede enviar un ID de sesion El servidor responde con un mensaje ServerHello que contiene la version del protocolo elegido un numero aleatorio CipherSuite y metodo de compresion de las opciones ofrecidas por el cliente Para confirmar o permitir handshake reanudado el servidor puede enviar un ID de sesion La version del protocolo elegido debe ser el mas alto que tanto el soporte de cliente y servidor Por ejemplo si el cliente es compatible con la version 1 1 y el servidor es compatible con la version 1 2 la version 1 1 se debe seleccionar 1 0 no se debe seleccionar El servidor envia su mensaje de certificado dependiendo de la suite de cifrado seleccionado esto puede ser omitido por el servidor 98 El servidor envia su mensaje ServerKeyExchange en funcion del conjunto de cifrado seleccionado esto puede ser omitido por el servidor Este mensaje se envia a todos los conjuntos de cifrado DHE y DH anon 2 El servidor envia un mensaje ServerHelloDone lo que indica que termino con la negociacion del handshake El cliente responde con un mensaje ClientKeyExchange que puede contener una PreMasterSecret la clave publica o nada Una vez mas esto depende de la cifra seleccionada Esta PreMasterSecret se cifra utilizando la clave publica del certificado del servidor El cliente y el servidor a continuacion utilizan los numeros aleatorios y PreMasterSecret para calcular un secreto comun llamado el secreto principal master secret Todos los demas datos clave para esta conexion se deriva de este secreto principal y los valores aleatorios generados tanto por cliente y por servidor que se pasan a traves de una funcion pseudoaleatoria cuidadosamente disenado El cliente ahora envia un registro ChangeCipherSpec esencialmente diciendo al servidor Todo lo que yo te diga de ahora en adelante sera autenticado y cifrada si los parametros de cifrado estaban presentes en el certificado del servidor El ChangeCipherSpec es en si mismo un protocolo a nivel de registro con el tipo de contenido 20 Por ultimo el cliente envia un mensaje autenticado y cifrado de Finished terminado que contiene un hash y MAC sobre los mensajes de handshake anteriores El servidor intentara descifrar el mensaje Finished del cliente y verificar el hash y MAC Si el descifrado o verificacion falla el handshake se considera que ha fracasado y la conexion debe ser derribada Por ultimo el servidor envia un ChangeCipherSpec diciendole al cliente Todo lo que yo te diga de ahora en adelante sera autenticado y cifrado si el cifrado se negocio El servidor envia su mensaje Finished autenticado y cifrado El cliente realiza el mismo descifrado y verificacion Fase de aplicacion en este punto el handshake esta completado y el protocolo de aplicacion esta activada con el tipo de contenido de 23 Los mensajes de aplicacion intercambiados entre el cliente y el servidor tambien seran autenticados y opcionalmente cifrados exactamente igual que en su mensaje final De lo contrario el tipo de contenido contestara 25 y el cliente no va sera autenticado Handshake TLS autenticado por el cliente Editar El siguiente ejemplo completo muestra un cliente siendo autenticado ademas del servidor como el de mas arriba a traves de TLS mediante certificados intercambiados entre ambos interlocutores Fase de Negociacion Un cliente envia un mensaje ClientHello especificando la version mas alta de protocolo TLS que soporta un numero al azar una lista de conjuntos de cifrado sugeridos y metodos de compresion El servidor responde con un mensaje ServerHello que contiene la version elegida del protocolo un numero al azar una suite de cifrado y el metodo de compresion de las opciones ofrecidas por el cliente El servidor tambien puede enviar un identificador de sesion como parte del mensaje para realizar un handshake reanudado El servidor envia su mensaje de certificados dependiendo de la suite de cifrado seleccionado esto puede ser omitido por el servidor 98 El servidor envia su mensaje ServerKeyExchange en funcion del conjunto de cifrado seleccionado esto puede ser omitido por el servidor Este mensaje se envia a todos los conjuntos de cifrado DHE y DH anon 2 El servidor solicita un certificado desde el cliente de modo que la conexion pueda ser mutuamente autenticada utilizando un mensaje CertificateRequest El servidor envia un mensaje ServerHelloDone lo que indica que termino con la negociacion handshake El cliente responde con un mensaje de certificado que contiene el certificado del cliente El cliente envia un mensaje ClientKeyExchange que puede contener un PreMasterSecret clave publica o nada Una vez mas esto depende del cifrado seleccionado Esta PreMasterSecret se cifra utilizando la clave publica del certificado del servidor El cliente envia un mensaje CertificateVerify que es una firma en los mensajes de reconocimiento anteriores utilizando la clave privada del certificado del cliente Esta firma puede ser verificada utilizando la clave publica del certificado del cliente Esto permite al servidor saber que el cliente tiene acceso a la clave privada del certificado y por lo tanto posee el certificado El cliente y el servidor a continuacion utilizan los numeros aleatorios y PreMasterSecret para calcular un secreto comun llamado el secreto principal Todos los demas datos clave para esta conexion se derivan de este secreto maestro y los valores aleatorios cliente y generados por el servidor que se pasa a traves de una funcion pseudoaleatoria cuidadosamente disenada El cliente ahora envia un registro ChangeCipherSpec esencialmente diciendo al servidor Todo lo que yo te diga de ahora en adelante sera autenticado y cifrada si el cifrado se negocio El ChangeCipherSpec es en si mismo un protocolo a nivel de registro y es tipo 20 y no 22 Por ultimo el cliente envia un mensaje cifrado de Finished que contiene un hash y MAC sobre los mensajes de handshake anteriores El servidor intentara descifrar el mensaje final del cliente y verificar el hash y MAC Si el descifrado o verificacion falla el handshake se considera que ha fracasado y la conexion debe ser derribada Por ultimo el servidor envia un ChangeCipherSpec diciendole al cliente Todo lo que yo te diga de ahora en adelante sera autenticado y cifrada si el cifrado se negocio El servidor envia su propio mensaje cifrado de Finished El cliente realiza el mismo descifrado y verificacion Fase de aplicacion en este punto el handshake esta completado y el protocolo de aplicacion esta activado con el tipo de contenido 23 Los mensajes de la aplicacion intercambiados entre el cliente y el servidor tambien seran cifrados exactamente igual que en su mensaje Finished Handshake reanudado Editar Las operaciones de clave publica por ejemplo RSA son relativamente costosas en terminos de calculo computacional TLS proporciona un acceso directo seguro en el mecanismo de handshake para evitar estas operaciones reanudar sesiones Las sesiones reanudadas se implementan utilizando los identificadores IDs de sesion o tickets de sesion Aparte de la ventaja de rendimiento reanudando las sesiones tambien se puede utilizar para inicio de sesion unico ya que se garantiza que tanto la sesion original asi como cualquier sesiones reanudada se originan desde el mismo cliente Esto es de particular importancia para el FTP sobre el protocolo TLS SSL ya que de lo contrario podria sufrir de un ataque man in the middle en el que un atacante podria interceptar el contenido de las conexiones de datos secundarias 99 IDs de sesion Editar En un handshake normal completo el servidor envia un ID de sesion como parte del mensaje ServerHello El cliente asocia este ID de sesion con la direccion IP del servidor y el puerto TCP para que cuando el cliente se conecte de nuevo a ese servidor puede utilizar el ID de sesion para acortar el handshake En el servidor el ID de sesion se asigna a los parametros criptograficos negociados anteriormente especificamente el secreto maestro Ambas partes deben tener el mismo secreto maestro o el handshake reanudado fallara esto evita que un espia utilice un ID de sesion Los datos aleatorios en los mensajes ClientHello y ServerHello practicamente garantizan que las claves de conexion generadas seran diferentes de la conexion anterior En las RFC este tipo de handshake se llama un protocolo de enlace abreviado Tambien se describe en la literatura como un reinicio de handshake Fase de Negociacion Un cliente envia un mensaje ClientHello especificando la version mas alta de protocolo TLS que soporta un numero al azar una lista de conjuntos de cifrado sugeridos y metodos de compresion Incluye en el mensaje el ID de sesion de la conexion TLS previa El servidor responde con un mensaje ServerHello que contiene la version elegida del protocolo un numero al azar una suite de cifrado y el metodo de compresion de las opciones ofrecidas por el cliente Si el servidor reconoce el ID de sesion responde con la misma ID de sesion El cliente usa esto para reconocer que se esta llevando a cabo una sesion reanudada Si el servidor no reconoce el ID de sesion enviado por el cliente responde con un valor diferente para la ID de sesion lo cual le dice al cliente que no se llevara a cabo una reanudacion de sesion En este punto tanto el cliente como el servidor tienen el secreto maestro y datos aleatorios para generar la clave usada para esta conexion El servidor envia un ChangeCipherSpec diciendole al cliente Todo lo que yo te diga de ahora en adelante sera autenticado y cifrada si el cifrado se negocio Por ultimo el servidor envia un mensaje cifrado de Finished que contiene un hash y MAC sobre los mensajes de handshake anteriores El cliente realiza el mismo descifrado y verificacion El cliente ahora envia un registro ChangeCipherSpec esencialmente diciendo al servidor Todo lo que yo te diga de ahora en adelante sera autenticado y cifrada si el cifrado se negocio El cliente envia su propio mensaje cifrado de Finished El servidor intentara descifrar el mensaje final del cliente y verificar el hash y MAC Fase de aplicacion en este punto el handshake esta completado y el protocolo de aplicacion esta activado con el tipo de contenido 23 Los mensajes de la aplicacion intercambiados entre el cliente y el servidor tambien seran cifrados exactamente igual que en su mensaje Finished Tickets de sesion Editar El RFC 5077 extiende TLS a traves de la utilizacion de tickets de sesion en lugar de los IDs de sesion Define una forma de reanudar una sesion TLS sin necesidad de almacenar el estado especifico de la sesion en el servidor TLS Al utilizar tickets de sesion el servidor TLS almacena su estado especifico de la sesion en un ticket de sesion y envia el ticket de sesion al cliente TLS para ser almacenado El cliente se reanuda una sesion TLS mediante el envio del ticket de sesion al servidor y el servidor reanuda la sesion TLS en el estado especifico de la sesion en el ticket El ticket de sesion esta cifrado y autenticada por el servidor y el servidor verifica su validez antes de utilizar su contenido Una debilidad particular de este metodo con OpenSSL es que siempre limita el cifrado y la autenticacion de seguridad del ticket de sesion TLS transmitido a AES128 CBC SHA256 no importa que otros parametros TLS sean negociados para la sesion actual TLS 91 Esto significa que la informacion de estado el ticket de sesion TLS no esta tan bien protegido como la sesion TLS misma De particular preocupacion es el almacenamiento de OpenSSL de las claves en un contexto de aplicacion SSL CTX es decir que se mantiene durante la duracion de la aplicacion y no permite el reingreso de informacion de los tickets de sesion AES128 CBC SHA256 TLS sin reiniciar el contexto a nivel de aplicacion OpenSSL lo que es raro propenso a errores y a menudo requiere intervencion administrativa manual 92 90 Registro TLS Editar Este es el formato general para todos los registros TLS Byte 0 Byte 1 Byte 2 Byte 3Byte0 Tipo de Contenido Bytes1 4 Version Largo Major Minor bits 15 8 bits 7 0 Bytes5 m 1 Mensaje s del ProtocoloBytesm p 1 MAC opcional Bytesp q 1 Relleno cifrados de bloque solamente Tipo de Contenido Este campo identifica el Tipo de Capa de Registro del Protocolo contenido en este registro Tipos de Contenido Hex Dec Tipo0x14 20 ChangeCipherSpec0x15 21 Alerta0x16 22 Handshake0x17 23 Aplicacion0x18 24 HeartbeatVersionEste campo identifica la version mayor y menor de TLS para el mensaje contenido Para un mensaje ClientHello esto no tiene por que ser la version mas alta admitida por el cliente Versiones VersionMayor VersionMenor Tipo de Version3 0 SSL 3 03 1 TLS 1 03 2 TLS 1 13 3 TLS 1 2Longitud La longitud del mensaje del Protocolo s MAC y Relleno que no exceda de 214 bytes 16 KiB Protocolo del Mensaje Uno o mas mensajes identificados por el campo Protocolo Tenga en cuenta que este campo puede ser cifrado dependiendo del estado de la conexion MAC y Relleno Un codigo de autenticacion de mensaje calculado sobre el mensaje del Protocolo con el material clave adicional incluido Tenga en cuenta que este campo puede ser codificado o no incluidos en su totalidad dependiendo del estado de la conexion No MAC o relleno pueden estar presentes al final de los registros TLS antes de todos los algoritmos de cifrado y parametros han sido negociados y handshaked y luego confirmado por el envio de un registro CipherStateChange ver mas abajo para la senalizacion de estos parametros tendran efecto en todos los registros adicionales enviados por el misma pares Protocolo de handshake Editar La mayoria de los mensajes intercambiados durante la configuracion de la sesion TLS se basan en este registro a menos que un error o advertencia se produzca y necesite ser senalado por un registro de protocolo de alerta ver mas abajo o el modo de cifrado de la sesion es modificado por otro record vease el protocolo ChangeCipherSpec abajo Byte 0 Byte 1 Byte 2 Byte 3Byte0 22 Bytes1 4 Version Largo Mayor Menor bits 15 8 bits 7 0 Bytes5 8 Tipo de Mensaje Largo de los datos del mensaje de handshake bits 23 16 bits 15 8 bits 7 0 Bytes9 n 1 Datos del mensaje de handshakeBytesn n 3 Tipo de Mensaje Largo de los datos del mensaje de handshake bits 23 16 bits 15 8 bits 7 0 Bytes n 4 Datos del mensaje de handshakeTipo de MensajeEste campo identifica el tipo de mensaje del handshake Message TypesCodigo Descripcion0 HelloRequest1 ClientHello2 ServerHello4 NewSessionTicket11 Certificate12 ServerKeyExchange13 CertificateRequest14 ServerHelloDone15 CertificateVerify16 ClientKeyExchange20 FinishedLongitud de datos de mensajes de handshake Este es un campo de 3 bytes que indica la longitud de los datos de handshake no incluyendo la cabecera Tenga en cuenta que varios mensajes de handshake se pueden combinar dentro de un registro Protocolo de alertas Editar Este registro no deberia enviarse normalmente durante los intercambios de protocolo de enlace o de aplicacion normales Sin embargo este mensaje puede ser enviado en cualquier momento durante el handshake y hasta el cierre de la sesion Si esto se utiliza para senalar un error fatal la sesion se cerrara inmediatamente despues de enviar este registro por lo que este registro se utiliza para dar la razon de este cierre Si el nivel de alerta se marca como una advertencia el equipo remoto puede decidir cerrar la sesion si decide que la sesion no es lo suficientemente confiable para sus necesidades antes de hacerlo el remoto tambien puede enviar su propia senal Byte 0 Byte 1 Byte 2 Byte 3Byte0 21 Bytes1 4 Version Largo Mayor Menor 0 2Bytes5 6 Nivel Descripcion Bytes7 p 1 MAC opcional Bytesp q 1 Relleno solo en cifrado de bloques Nivel Este campo identifica el nivel de alerta Si el nivel es fatal el remitente debe cerrar la sesion inmediatamente De lo contrario el destinatario puede decidir terminar la sesion mediante el envio de su propia alerta fatal y cierre de la sesion misma inmediatamente despues de enviarlo El uso de registros de alerta es opcional sin embargo si no se encuentra antes del cierre de sesion la sesion puede reanudarse automaticamente con sus handshake El cierre normal de la sesion despues de la terminacion de la aplicacion transportada debe ser alertado preferiblemente con al menos el tipo de alerta Close notify con un nivel de aviso sencillo para evitar que la nueva sesion pueda ser reanudada La senalizacion explicita del cierre normal de una sesion segura antes de cerrar de manera efectiva su capa de transporte es util para prevenir o detectar los ataques como los intentos de truncar los datos transportados de forma segura si es que intrinsecamente no tiene una longitud predeterminada o duracion que el destinatario de los datos puede esperar Tipos de Nivel de Alerta Codigo Tipo de Nivel Estado de Conexion1 advertencia la conexion o la seguridad puede ser inestable 2 fatal la conexion o la seguridad puede estar comprometida o un error irrecuperable ha ocurrido Descripcion Este campo identifica cual tipo de alerta esta siendo enviada Descripcion de tipos de Alertas Codigo Descripcion Tipos del Nivel Notas0 Notificacion de Cierre advertencia fatal10 Mensaje Inesperado fatal20 Mal registro MAC fatal Posiblemente una mala implementacion de SSL o la carga util ha sido modificada con i e regla FTP de un firewall en un servidor FTPS 21 Falla en Descifrado fatal solo TLS reservado22 Desbordamiento de Registro fatal solo TLS30 Falla de Descompresion fatal40 Falla de handshake fatal41 Sin certificado advertencia fatal Solo SSL 3 0 reservado42 Certificado malo advertencia fatal43 Certificado no soportado advertencia fatal por ej el certificado tiene habilitado solo uso como autenticacion de servidor y se presenta como certificado de cliente44 Certificado revocado advertencia fatal45 Certificado expirado advertencia fatal Revisar certificado del servidor expirado tambien revisar que algun certificado presentado en la cadena ha expirado46 Certificado desconocido advertencia fatal47 parametro ilegal fatal48 CA Autoridad de certificacion desconocida fatal solo TLS49 Acceso denegado fatal solo TLS por ej no se ha presentado un certificado de cliente TLS mensaje de certificado en blanco o SSLv3 alerta de No Certificado pero el servidor esta configurado para requerir uno 50 error de decodificacion fatal solo TLS51 error de descifrado advertencia fatal solo TLS60 Restriccion de exportacion fatal solo TLS reservado70 Version de Protocolo fatal solo TLS71 Seguridad Insuficiente fatal solo TLS80 Error Interno fatal solo TLS90 Cancelado por el Usuario fatal solo TLS100 No renegociacion advertencia solo TLS110 Extension No Soportada advertencia solo TLS111 Certificado no Obtenible advertencia solo TLS112 Nombre No Reconocido advertencia fatal solo TLS el Indicador de nombre del servidor del cliente especifica un host no soportado por el servidor113 Respuesta de Mal Certificado fatal solo TLS114 Valor de hash de Mal Certificado fatal solo TLS115 Identidad PSK desconocida usado en TLS PSK y TLS SRP fatal solo TLS120 Sin Protocolo de Aplicacion fatal solo TLS el ALPN del cliente ALPN no contiene ningun protocolo soportado por el servidor Protocolo ChangeCipherSpec Editar Byte 0 Byte 1 Byte 2 Byte 3Byte0 20 Bytes1 4 Version Largo Mayor Menor 0 1Byte5 Tipo de Protocolo CCS Tipo de Protocolo CCS Actualmente solo 1 Protocolo de aplicacion Editar Byte 0 Byte 1 Byte 2 Byte 3Byte0 23 Bytes1 4 Version Largo Mayor Menor bits 15 8 bits 7 0 Bytes5 m 1 Datos de AplicacionBytesm p 1 MAC opcional Bytesp q 1 Relleno solo cifrado de bloques Largo Largo de los datos de la aplicacion excluyendo el encabezado del protocolo e incluyendo el final de MAC y relleno MAC 20 bytes para el HMAC basado en SHA 1 16 bytes para el HMAC basado en MD5 Relleno Largo variable el ultimo byte contiene el largo del relleno Soporte para servidores virtuales por nombre EditarDesde 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 aplicacion pueda comenzar La funcionalidad de servidor virtual basado en nombres es provista por la capa de aplicacion donde todos los servidores virtuales alojados en una misma maquina comparten el mismo certificado Esto es un problema ya que el servidor debe seleccionar y mandar el certificado inmediatamente despues 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 comodin Ademas de que podria ser un problema la seleccion amplia de host ame no hay acuerdo en como emparejar certificados wildcard Se aplican reglas diferentes dependiendo del protocolo de aplicacion o del software usado 100 Agregar cada host virtual en la extension 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 extension de Indicacion de nombre de servidor Server Name Indication o SNI en el mensaje extendido ClientHello Esta extension inmediatamente le da pistas al servidor respecto de cual nombre es al que el cliente se quiere conectar por lo que el servidor puede seleccionar el certificado apropiado para enviar al cliente Estandares EditarTLS 1 0 Editar Las extensiones a TLS 1 0 incluyen RFC 2595 Using TLS with IMAP POP3 and ACAP Especifica una extension 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 solo para propositos de documentacion del hecho de que esas familias de codigos de cifrado han sido ya asignadas RFC 2817 Upgrading to TLS Within HTTP 1 1 explica como usar el mecanismo Upgrade en HTTP 1 1 para iniciar TLS sobre una conexion TCP existente Esto permite al trafico 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 trafico seguro de trafico inseguro mediante el uso de un puerto de servidor diferente RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security Especifca una extension 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 Anade la familia de cifrado AES a los cifrados simetricos previamente existentes RFC 3546 Transport Layer Security TLS Extensions anade un mecanismo para negociar extensiones de protocolos durante la inicializacion de sesion y define algunas extensiones RFC 3749 Transport Layer Security Protocol Compression Methods especifica el marco para los metodos de compresion y para el metodo 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 anade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticacion basada en claves previamente compartidas TLS 1 1 Editar Las extensiones 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 especificas y un mecanismo de extensiones genericas 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 despues del RFC 6091 TLS 1 2 Editar La version 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 estandar actual reemplaza a las versiones mas 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 asi como el nunca estandarizado SSL 3 0 RFC 6101 The Secure Sockets Layer SSL Protocol Version 3 0 Otros RFC posteriores extendieron TLS Las extensiones 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 TLS 1 3 Editar RFC 8446 en ingles The Transport Layer Security TLS Protocol Version 1 3 Encapsulaciones Editar Las encapsulaciones de TLS incluyen RFC 5216 The EAP TLS Authentication Protocol Vease tambien EditarDatagram Transport Layer Security HTTPS X 509 Wireless Transport Layer Security Heartbleed Network Security Services NSS Referencias Editar Dierks T y E Rescorla agosto de 2008 The Transport Layer Security TLS Protocol Version 1 2 a b c d RFC 5246 The Transport Layer Security TLS Protocol Version 1 2 Internet Engineering Task Force Consultado el 9 de septiembre de 2013 SSL Intercepted today decrypted tomorrow Netcraft 2013 06 25 Freier A P Karlton y P Kocher agosto de 2011 The Secure Sockets Layer SSL Protocol Version 3 0 Kovacs Eduard 13 de agosto de 2018 IETF Publishes TLS 1 3 as RFC 8446 securityweek com en ingles Consultado el 16 de agosto de 2018 Woo Thomas Y C Raghuram Bindignavle Shaowen Su y Simon S Lam SNP An interface for secure network programming Proceedings USENIX Summer Technical Conference June 1994 THE SSL PROTOCOL Netscape Corporation 2007 Archivado desde el original el 14 de junio de 1997 Consultado el 13 de enero de 2013 Rescorla 2001 Dierks T y E Rescorla abril de 2006 The Transport Layer Security TLS Protocol Version 1 1 RFC 4346 RFC 6091 Using OpenPGP Keys for Transport Layer Security TLS Authentication Eronen P ed RFC 4279 Pre Shared Key Ciphersuites for Transport Layer Security TLS Internet Engineering Task Force Consultado el 9 de septiembre de 2013 Gothard Peter Google updates SSL certificates to 2048 bit encryption Computing Incisive Media Consultado el 9 de septiembre de 2013 a b c d draft chudov cryptopro cptls 04 GOST 28147 89 Cipher Suites for Transport Layer Security TLS en ingles RFC 8446 RFC 5288 RFC 6655 RFC 6367 RFC 5932 RFC 4162 On the Practical In Security of 64 bit Block Ciphers Collision Attacks on HTTP over TLS and OpenVPN 28 de octubre de 2016 Archivado desde el original el 24 de abril de 2017 Consultado el 8 de junio de 2017 NIST Special Publication 800 57 Recommendation for Key Management Part 1 General Revised 8 de marzo de 2007 Archivado desde el original el 6 de junio de 2014 Consultado el 3 de julio de 2014 a b c Qualys SSL Labs SSL TLS Deployment Best Practices Archivado desde el original el 4 de julio de 2015 Consultado el 2 de junio de 2015 IETF RFC 5469 draft agl tls chacha20poly1305 04 a b c d Al 6 de noviembre de 2014 SSL Pulse Survey of the SSL Implementation of the Most Popular Web Sites Archivado desde el original el 15 de mayo de 2017 Consultado el 11 de noviembre de 2014 a b ivanr RC4 in TLS is Broken Now What Qualsys Security Labs Consultado el 30 de julio de 2013 a b c Moller Bodo Thai Duong y Krzysztof Kotowicz This POODLE Bites Exploiting The SSL 3 0 Fallback Consultado el 15 de octubre de 2014 Google 29 de mayo de 2012 Dev Channel Update Consultado el 14 de enero de 2013 Google 21 de agosto de 2012 Stable Channel Update Consultado el 14 de enero de 2013 Security in Firefox 2 6 de agosto de 2008 Consultado el 14 de enero de 2013 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 Bug 480514 Implement support for TLS 1 2 RFC 5246 17 de marzo de 2010 Consultado el 14 de enero de 2013 Microsoft 5 de septiembre de 2012 Secure Channel Consultado el 14 de enero de 2013 Microsoft 27 de febrero de 2009 MS TLSP Appendix A Consultado el 14 de enero de 2013 Pettersen Yngve Nysaeter 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 Adrian Dimcev Common browsers libraries servers and the associated cipher suites implemented TLS Cipher Suites Project Apple 10 de junio de 2009 Features Consultado el 14 de enero de 2013 Apple 14 de octubre de 2011 Technical Note TN2287 iOS 5 and TLS 1 2 Interoperability Issues Consultado el 14 de enero de 2013 Liebowitz Matt 13 de octubre de 2011 Apple issues huge software security patches NBCNews com Archivado desde el original el 28 de noviembre de 2011 Consultado el 14 de enero de 2013 MWR Info Security 16 de abril de 2012 Adventures with iOS UIWebviews Consultado el 14 de enero de 2013 section HTTPS SSL TLS Georgiev Martin Iyengar Subodh Jana Suman Anubhai Rishita Boneh Dan y 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 Claessens Joris Valentin Dem Danny De Cock Bart Preneel Joos Vandewalle 2002 On the Security of Today s Online Electronic Banking Systems Computers amp Security 21 3 253 265 doi 10 1016 S0167 4048 02 00312 7 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 Bugzilla Mozilla Bug 236933 Disable SSL2 and other weak ciphers Mozilla Corporation Consultado el 25 de noviembre de 2007 Opera 9 5 for Windows Changelog Archivado el 26 de junio de 2009 en Wayback Machine at Opera com Disabled SSL v2 and weak ciphers Firefox still sends SSLv2 handshake even though the protocol is disabled 11 de septiembre de 2008 Opera 10 for Windows changelog en Opera com Removed support for SSL v2 and weak ciphers 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 National Institute of Standards and Technology diciembre de 2010 Implementation Guidance for FIPS PUB 140 2 and the Cryptographic Module Validation Program en ingles a b DanGoodin 19 de septiembre de 2011 Hackers break SSL encryption used by millions of sites a b Y Combinator comments on the issue 20 de septiembre de 2011 Dimcev Adrian SSL TLS version rollbacks and browsers Consultado el 9 de marzo de 2011 Rescorla Eric 5 de noviembre de 2009 Understanding the TLS Renegotiation Attack Educated Guesswork Consultado el 27 de noviembre de 2009 SSL CTX set options SECURE RENEGOTIATION OpenSSL Docs 25 de febrero de 2010 Archivado desde el original el 9 de febrero de 2012 Consultado el 18 de noviembre de 2010 GnuTLS 2 10 0 released GnuTLS release notes 25 de junio de 2010 Archivado desde el original el 9 de febrero de 2012 Consultado el 24 de julio de 2011 NSS 3 12 6 release notes NSS release notes 3 de marzo de 2010 Archivado desde el original el 29 de junio de 2011 Consultado el 24 de julio de 2011 Langley A 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 La referencia utiliza el parametro obsoleto mes ayuda La referencia utiliza el parametro obsoleto coautores ayuda 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 Brian Smith Limited rollback attacks in False Start and Snap Start Consultado el 9 de marzo de 2011 Adrian Dimcev False Start Random SSL TLS 101 Consultado el 9 de marzo de 2011 Mavrogiannopoulos Nikos Vercautern Frederik Velichkov Vesselin y 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 Security of CBC Ciphersuites in SSL TLS 20 de mayo de 2004 Smith Brian 30 de septiembre de 2011 CVE 2011 3389 Rizzo Duong chosen plaintext attack BEAST on SSL TLS 1 0 facilitated by websockets 76 Vulnerability in SSL TLS Could Allow Information Disclosure 2643584 10 de enero de 2012 Ristic Ivan 31 de octubre de 2013 Apple Enabled BEAST Mitigations in OS X 10 9 Mavericks Security Labs en ingles Consultado el 1 de febrero de 2014 Safest ciphers to use with the BEAST TLS 1 0 exploit 24 de septiembre de 2011 First solutions for SSL TLS vulnerability 26 de septiembre de 2011 Goodin Dan 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 Fisher Dennis 13 de septiembre de 2012 CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions ThreatPost Archivado desde el original el 15 de septiembre de 2012 Consultado el 13 de septiembre de 2012 Gutmann P septiembre de 2014 Encrypt then MAC for Transport Layer Security TLS and Datagram Transport Layer Security DTLS a b Moller Bodo 14 de octubre de 2014 This POODLE bites exploiting the SSL 3 0 fallback Consultado el 15 de octubre de 2014 Bar El Hagai Poodle flaw and IoT Consultado el 15 de octubre de 2014 security Safest ciphers to use with the BEAST TLS 1 0 exploit I ve read that RC4 is immune Server Fault en ingles Pouyan Sepehrdad Serge Vaudenay Martin Vuagnoux 2011 Discovery and Exploitation of New Biases in RC4 Lecture Notes in Computer Science 6544 74 91 doi 10 1007 978 3 642 19574 7 5 Green Matthew Attack of the week RC4 is kind of broken in TLS Cryptography Engineering Consultado el 12 de marzo de 2013 AlFardan Nadhem Dan Bernstein Kenny Paterson Bertram Poettering y Jacob Schuldt On the Security of RC4 in TLS Royal Holloway University of London Consultado el 13 de marzo de 2013 AlFardan Nadhem J Bernstein Daniel J Paterson Kenneth G Poettering Bertram Schuldt Jacob C N 8 de julio de 2013 On the Security of RC4 in TLS and WPA PDF Consultado el 2 de septiembre de 2013 AlFardan Nadhem J Bernstein Daniel J Paterson Kenneth G Poettering Bertram Schuldt Jacob C N 15 de agosto de 2013 On the Security of RC4 in TLS PDF 22nd USENIX Security Symposium p 51 Consultado el 2 de septiembre de 2013 Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical Popov Andrei 1 de octubre de 2014 Prohibiting RC4 Cipher Suites draft ietf tls prohibiting rc4 01 a b Leyden John 1 de agosto de 2013 Gmail Outlook com and e voting pwned on stage in crypto dodge hack The Register Consultado el 1 de agosto de 2013 BlackHat USA Briefings Black Hat 2013 Consultado el 1 de agosto de 2013 Why is it called the Heartbleed Bug Heartbleed Bug vulnerability 9 April 2014 Archivado desde el original el 5 de julio de 2014 Consultado el 25 de noviembre de 2014 Diffie Whitfield van Oorschot Paul C Wiener Michael J Junio de 1992 Authentication and Authenticated Key Exchanges Designs Codes and Cryptography 2 2 107 125 doi 10 1007 BF00124891 Consultado el 11 de febrero de 2008 La referencia utiliza el parametro obsoleto coauthors ayuda Discussion on the TLS mailing list in October 2007 Archivado desde el original el 22 de septiembre de 2013 Consultado el 3 de enero de 2015 Protecting data for the long term with forward secrecy Consultado el 5 de noviembre de 2012 Bernat Vincent SSL TLS amp Perfect Forward Secrecy Consultado el 5 de noviembre de 2012 SSL Labs Deploying Forward Secrecy Qualys com 25 de junio de 2013 Consultado el 10 de julio de 2013 Ristic Ivan 5 de agosto de 2013 SSL Labs Deploying Forward Secrecy Qualsys Consultado el 31 de agosto de 2013 a b Langley Adam 27 de junio de 2013 How to botch TLS forward secrecy a b Daigniere Florent TLS Secrets Whitepaper presenting the security implications of the deployment of session tickets RFC 5077 as implemented in OpenSSL Matta Consulting Limited Consultado el 7 de agosto de 2013 a b Daigniere Florent TLS Secrets What everyone forgot to tell you Matta Consulting Limited Consultado el 7 de agosto de 2013 Protecting data for the long term with forward secrecy Consultado el 7 de marzo de 2014 Hoffman Andrews Jacob Forward Secrecy at Twitter Twitter Twitter Consultado el 7 de marzo de 2014 Certificate Pinning Archivado el 27 de diciembre de 2013 en Wayback Machine Fijacion de clave publica lanzado en Firefox Proyecto Perspectivas a b Estos certificados son actualmente X 509 pero el RFC 6091 tambien especifica el uso de certificados basados en OpenPGP Chris 18 de febrero de 2009 vsftpd 2 1 0 released Using TLS session resume for FTPS data connection authentication Scarybeastsecurity blogspot com Consultado el 17 de mayo de 2012 Named based SSL virtual hosts how to tackle the problem PDF Consultado el 17 de mayo de 2012 Bibliografia EditarWagner David y Bruce Schneier Analysis of the SSL 3 0 Protocol The Second USENIX Workshop on Electronic Commerce Proceedings USENIX Press November 1996 pp 29 40 Enlaces externos EditarCentro de informacion de SSL El grupo de trabajo de la IETF de TLS en ingles SSL Guia de generacion de CSR Problemas de seguridad existentes en SSL TLS SSL CSR generation guide Instructivos de instalacion de Certificados SSL ordenados por plataforma Test de configuracion de SSL Guia de Instalacion de SSL Como generar CSR para SSL Preguntas frecuentes de Certificados SSL Datos Q206494 Multimedia SSL and TLSObtenido de https es wikipedia org w index php title Seguridad de la capa de transporte amp oldid 137355253, wikipedia, wiki, leyendo, leer, libro, biblioteca,

español

, española, descargar, gratis, descargar gratis, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, imagen, música, canción, película, libro, juego, juegos