Ir al contenido

Seguridad de la capa de transporte

De Wikipedia, la enciclopedia libre
Esta es una versión antigua de esta página, editada a las 17:37 15 ene 2013 por Muro de Aguas (discusión · contribs.). La dirección URL es un enlace permanente a esta versión, que puede ser diferente de la versión actual.
Este artículo o sección se está traduciendo desde otro idioma. Por esta razón, puede haber lagunas de contenidos, errores sintácticos o escritos sin traducir. Puedes colaborar con Wikipedia continuando con la traducción desde el artículo original.
Para otros usos de este término, véase TLS.

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

Descripción

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

SSL implica una serie de fases básicas:

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

Historia y desarrollo

API de Secure Network Programming

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

SSL 1.0, 2.0 y 3.0

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

TLS 1.0

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

Ataque BEAST

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

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

El ataque BEAST también se puede prevenir removiendo todo los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es ampliamente soportado la mayoría de los sitios web.[9]​[10]​ 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. Los autores del ataque BEAST también son los creadores del ataque CRIME, que usa compresión de datos para adivinar.

TLS 1.1

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

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

TLS 1.2

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

  • la combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256, con la opción de usar PRFs especificados en la cipher-suite.
  • la combinación MD5-SHA-1 en el mensaje terminado fue reemplazada por SHA-256, sin la opción de usar algoritmos de hash específicos para la cipher-suite. Sin embargo, el tamaño del has en el mensaje terminado es truncado a 96 bits.
  • la combinación MD5-SHA-1 en el elemento digitalmente firmado fue reemplazada por un has 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 encriptación autenticadas, usadas mayormente para modo Galois/Counter (GCM) y modo CCM de al encriptación con Advanced Encryption Standard (o estándar de encriptación avanzada) (AES).
  • Se agregaron definición de Extensiones de TLS y de Ciphersuites de AES.

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

Funcionamiento

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

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

El cliente envía y recibe varias estructuras handshake:

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

TLS/SSL poseen una variedad de medidas de seguridad:

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

Aplicaciones

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. Aunque pueda proporcionar seguridad a cualquier protocolo que use conexiones de confianza (tal como TCP), se usa en la mayoría de los casos 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. 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 encriptación 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.

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 handhake es usualmente (excepto en el caso STARTTLS) llevado a cabo antes de que el protocolo de aplicación pueda comenzar. La funcionalidad de servidor virtual basado en nombres es provista por la capa de aplicación, donde todos los servidores virtuales alojados en una misma máquina comparten el mismo certificado. Esto es un problema, ya que el servidor debe seleccionar y mandar el certificado inmediatamente después del mensaje de ClientHello. Este es un gran problema en los ambientes de alojamiento, ya que implica que todos los clientes en un mismo servidor deben compartir el certificado o se debe utilizar una IP distinta para cada uno de ellos. Hay dos formas conocidas de evitar esto, provistas por X.509:

  • Si todos los servidores virtuales pertenecen al mismo dominio, se puede utilizar un certificado wildcard. Además de que podría ser un problema la selección amplia de host ame, no hay acuerdo en cómo emparejar certificados wildcard. Se aplican reglas diferentes dependiendo del protocolo de aplicación o del software usado.[13]​
  • 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 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.

Implementaciones

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

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)[a][f] Sí Sí No No No No
Chrome 22– Linux, Mac OS X, Windows (XP, Vista, 7, 8)[a][f] Sí Sí Sí Sí No No
Firefox 2– Linux, Mac OS X, Windows (XP, Vista, 7, 8)[b][f] Sí Sí[15]​ No No[16]​ No No[17]​
IE 1–7 Mac OS X, Windows (XP, Vista, 7)[c][c] Sí Sí No No No No
IE 8 Windows (XP, Vista)[c] Sí Sí No No No No
IE 8–9 Windows 7[c] Sí Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
IE 9 Windows Vista[c] Sí Sí No No No No
IE 10 Windows (7, 8)[c] Sí Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
Opera 10– Linux, Mac OS X, Windows[d] Sí Sí Sí, deshabilitada por defecto Sí, deshabilitada por defecto
Safari 5– Mac OS X, Windows (XP, Vista, 7)[e] Sí Sí
Mobile Safari/UIWebView iOS 5.0+[g] Sí Sí Sí Sí Sí Sí

Notas:

a) 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.[18]​[19]​

b) A noviembre de 2012, Firefox sólo es compatible con TLS 1.0.

c) 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.[20]​[21]​

d) 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. [22]​ TLS 1.1 y 1.2 están deshabilitadas por defecto.

e) Safari utiliza la implementación del sistema operativo Mac OS X, Windows (XP, Vista, 7)[23]​ con versión desconocida,[24]​ Safari 5 es la última versión disponible para Windows.

f) Utiliza la implementación TLS proporcionada por NSS. A noviembre de 2012, NSS soporta TLS 1.0 y 1.1, pero no 1.2.

g) 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.[25]​[26]​[27]​

Estándares

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

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

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

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

así como el nunca estandarizado SSL 3.0:

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

Otros RFC posteriores extendieron TLS.

Las extensions a TLS 1.0 incluyen:

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

Las extensions a TLS 1.1 incluyen:

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

Las extensions a TLS 1.2 incluyen:

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

Las encapsulaciones de TLS incluyen:

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

Véase también

Referencias

  • David Wagner and Bruce Schneier, Analysis of the SSL 3.0 Protocol, The second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp29–40.
  1. ↑ Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994
  2. ↑ «THE SSL PROTOCOL». Netscape Corporation. 2007. Archivado desde el original el 14 June 1997. 
  3. ↑ Rescorla 2001
  4. ↑ Dan Goodin (19 de septiembre de 2011). «Hackers break SSL encryption used by millions of sites». 
  5. ↑ «Y Combinator comments on the issue». 20 de septiembre de 2011. 
  6. ↑ «Security of CBC Ciphersuites in SSL/TLS». 20 de mayo de 2004. 
  7. ↑ Brian Smith (30 de septiembre de 2011). «(CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)». 
  8. ↑ «Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584)». 10 de enero de 2012. 
  9. ↑ «Safest ciphers to use with the BEAST? (TLS 1.0 exploit)». 24 de septiembre de 2011. 
  10. ↑ «First solutions for SSL/TLS vulnerability». 26 de septiembre de 2011. 
  11. ↑ Dierks, T. and E. Rescorla (April 2006). «The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346». 
  12. ↑ RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“
  13. ↑ «Named-based SSL virtual hosts: how to tackle the problem» (PDF). Consultado el 17 de mayo de 2012. 
  14. ↑ Georgiev, Martin and Iyengar, Subodh and Jana, Suman and Anubhai, Rishita and Boneh, Dan and Shmatikov, Vitaly (2012). «The most dangerous code in the world: validating SSL certificates in non-browser software. Proceedings of the 2012 ACM conference on Computer and communications security». pp. 38-49. ISBN 978-1-4503-1651-4. 
  15. ↑ «Security in Firefox 2». 6 de agosto de 2008. Consultado el 14 de enero de 2013. 
  16. ↑ «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. 
  17. ↑ «Bug 480514 - Implement support for TLS 1.2 (RFC 5246)». 17 de marzo de 2010. Consultado el 14 de enero de 2013. 
  18. ↑ Google (29 de mayo de 2012). «Dev Channel Update». Consultado el 14 de enero de 2013. 
  19. ↑ Google (21 de agosto de 2012). «Stable Channel Update». Consultado el 14 de enero de 2013. 
  20. ↑ Microsoft (5 de septiembre de 2012). «Secure Channel». Consultado el 14 de enero de 2013. 
  21. ↑ Microsoft (27 de febrero de 2009). «MS-TLSP Appendix A». Consultado el 14 de enero de 2013. 
  22. ↑ Yngve Nysæter Pettersen (25 de febrero de 2009). «New in Opera Presto 2.2: TLS 1.2 Support». Consultado el 14 de enero de 2013. 
  23. ↑ Adrian, Dimcev. «Common browsers/libraries/servers and the associated cipher suites implemented». TLS Cipher Suites Project. 
  24. ↑ Apple (10 de junio de 2009). «Features». Consultado el 14 de enero de 2013. 
  25. ↑ Apple (14 de octubre de 2011). «Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues». Consultado el 14 de enero de 2013. 
  26. ↑ Liebowitz, Matt (13 de octubre de 2011). «Apple issues huge software security patches». NBCNews.com. Consultado el 14 de enero de 2013. 
  27. ↑ MWR Info Security (16 de abril de 2012). «Adventures with iOS UIWebviews». Consultado el 14 de enero de 2013. , section "HTTPS (SSL/TLS)"

Enlaces externos

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