TRANSPORT LAYER SECURITY (TLS) Transport Layer Security (TLS) y su predecesor, Secure Sockets Layer (SSL), son protocolos

criptogrficos que proporcionan comunicaciones de seguridad en el Internet . [1] TLS y SSL cifrar los segmentos de conexiones de red por encima de la capa de transporte , utilizando criptografa simtrica de la vida privada y una clave de mensaje cdigo de autenticacin para la fiabilidad del mensaje. Varias versiones de los protocolos estn en uso generalizado en aplicaciones como navegacin web , correo electrnico , fax por Internet , mensajera instantnea y voz sobre IP (VoIP) . TLS es un IETF de normas de protocolo, ltima actualizacin en el RFC 5246 y se basa en el protocolo SSL especificaciones anteriores desarrollado por Netscape Corporation El protocolo TLS permite / servidor de aplicaciones de cliente para comunicarse a travs de una red de una forma diseada para prevenir escuchas ilegales y la manipulacin . Un cliente TLS y el servidor negocian una conexin de estado mediante un apretn de manos procedimiento. [3] Durante este apretn de manos, el cliente y el servidor de acuerdo sobre los distintos parmetros utilizados para establecer la conexin de la seguridad. El apretn de manos se inicia cuando un cliente se conecta a un servidor habilitados para TLS solicitar una conexin segura y presenta una lista de los conjuntos de cifrado ( cifrado y funciones de hash ). De esta lista, el servidor elige el ms fuerte de cifrado y la funcin hash que tambin apoya y notifica al cliente de la decisin. El servidor devuelve su identificacin en la forma de un certificado digital . El certificado contiene usualmente el nombre del servidor, la confianza entidad emisora de certificados (CA) y el servidor de clave de cifrado pblica . El cliente puede comunicarse con el servidor que emiti el certificado (la CA de confianza que el anterior) y confirmar que el certificado es vlido antes de continuar. Con el fin de generar las claves de sesin utilizado para la conexin segura, el cliente encripta un nmero aleatorio con la clave pblica del servidor y enva el resultado al servidor. Slo el servidor debe ser capaz de descifrar, con su clave privada. A partir del nmero al azar, las dos partes generar material clave para el cifrado y descifrado. Con esto concluye el apretn de manos y comienza la conexin segura, que se cifra y descifra con el material de clave hasta que la conexin se cierra. Si alguno de los pasos anteriores no, el protocolo de enlace TLS falla y la conexin no se crea.

[ editar ] Historia y desarrollo [ editar ] Secure Network API de programacin Los primeros esfuerzos de investigacin hacia la capa de seguridad de transporte incluido el seguro de redes de programacin (SNP) de interfaz de programacin de aplicaciones (API), que en 1993 explor el enfoque de tener una capa de transporte segura API muy parecidas a tomas de Berkeley , para facilitar la adaptacin preexistentes aplicaciones de red con las medidas de seguridad. [4] [ editar ] SSL 1.0, 2.0 y 3.0 El protocolo SSL fue desarrollado originalmente por Netscape . La versin 1.0 nunca fue lanzado al pblico; la versin 2.0 fue lanzado en febrero de 1995, pero "contena una serie de fallos de seguridad que en ltima instancia, condujo al diseo de la versin SSL 3.0" (Rescorla, 2001). SSL versin 3.0 fue lanzado en 1996 . [ editar ] TLS 1.0 (SSL 3.1) TLS 1.0 fue definido por la RFC 2246 en enero de 1999 como una actualizacin a la versin 3.0 de SSL. Como se indica en el RFC, "las diferencias entre este protocolo y SSL 3.0 no son espectaculares, pero son lo suficientemente significativos que TLS 1.0 y SSL 3.0 no interoperar". TLS 1.0 incluye un medio por el cual una implementacin TLS se puede degradar la conexin a SSL 3.0. [ editar ] TLS 1.1 (SSL 3.2) TLS 1.1 se define en el RFC 4346 en abril de 2006. [5] Se trata de una actualizacin desde la versin 1.0 de TLS. diferencias significativas en esta versin incluyen: proteccin adicional contra el bloque de encadenamiento de cifrado (CBC) ataques. La implcita vector de inicializacin (IV) fue reemplazado con un explcito IV. Cambio en el manejo de errores de relleno . Apoyo a la IANA registro de parmetros. [ editar ] TLS 1.2 (SSL 3.3) TLS 1.2 se define en el RFC 5246 en agosto de 2008. Se basa en los principios de TLS 1.1. Las principales diferencias son: El MD5 - SHA-1 en combinacin de la funcin pseudoaleatoria (PRF) fue reemplazado por SHA-256 , con una opcin para usar cifrado de bao especificado PRF.

El MD5-SHA-1 en combinacin con el hash mensaje final fue sustituido con SHA256, con una opcin para usar algoritmos de conjunto de cifrado especfico de hash. El MD5-SHA-1 en la combinacin con firma digital elemento fue sustituido por un nico hash negociado durante apretn de manos, por defecto es SHA-1. Mejora en la dcada de los clientes y la capacidad del servidor para especificar algoritmos hash y firma que aceptar. Ampliacin de apoyo a sistemas de cifrado autenticado, utilizado principalmente para Galois / Counter Mode (GCM) y el modo de MCP de Advanced Encryption Standard de cifrado. TLS y las extensiones de definicin estndar de cifrado avanzado conjuntos de cifrado se han aadido. [ editar ] Aplicaciones En el diseo de aplicaciones, TLS se implementa normalmente en la parte superior de cualquiera de la capa de transporte protocolos, encapsulando los protocolos especficos de aplicacin como HTTP , FTP , SMTP , NNTP y XMPP . Histricamente se ha utilizado principalmente con protocolos de transporte confiables, tales como el Protocolo de Control de Transmisin (TCP). Sin embargo, tambin se ha implementado con el transporte de protocolos orientados a datagramas, como el Protocolo de datagramas de usuario (UDP) y el de datagramas de Protocolo de control de congestin (DCCP), el uso que se ha normalizado de forma independiente utilizando el trmino de datagramas de Transport Layer Security (DTLS). Un uso prominente de TLS es para asegurar la World Wide Web realizado por el trfico HTTP para formar HTTPS . aplicaciones ms importantes son el comercio electrnico y gestin de activos . Cada vez ms, el Simple Mail Transfer Protocol (SMTP) tambin est protegido por TLS ( RFC 3207 ). Estas aplicaciones utilizan certificados de clave pblica para verificar la identidad de los extremos. TLS tambin se puede utilizar para hacer un tnel de una red de toda la pila para crear una VPN , como es el caso de OpenVPN . Muchos proveedores ahora se casan de cifrado TLS y capacidades de autenticacin de la autorizacin. [ cita requerida ] Tambin ha sido el desarrollo de manera espectacular desde finales de 1990 en la creacin de la tecnologa de cliente fuera del navegador para habilitar el soporte para aplicaciones de servidor de cliente. Cuando se compara contra el tradicional IPsec VPN tecnologas, TLS tiene algunas ventajas inherentes en el firewall y NAT transversal que hacen que sea ms fcil de administrar para el acceso remoto a grandes poblaciones [ cita requerida ]. TLS es un mtodo estndar para proteger Session Initiation Protocol (SIP) de sealizacin de la aplicacin. [ cita requerida ] TLS se puede utilizar para proporcionar la autenticacin y el cifrado de la SIP de sealizacin asociadas con VoIP y otras aplicaciones basadas en SIP. [ editar ]

Seguridad TLS / SSL tienen una variedad de medidas de seguridad: Proteccin contra una rebaja del protocolo a una anterior (menos seguro) versin o una suite de cifrado ms dbil. Numeracin de los registros posteriores de aplicaciones con un nmero de secuencia y el uso de este nmero de secuencia en la autenticacin de los cdigos de mensajes (MAC). El uso de un resumen de mensaje mejorado con una clave (por lo que slo una clave-titular puede comprobar el MAC). El HMAC de construccin utilizados por la mayora de conjuntos de cifrado TLS se especifica en el RFC 2104 (SSL 3.0 utiliza un diferente basado en MAC hash). El mensaje que termina el apretn de manos ("final") enva un hash de todos los mensajes intercambiados apretn de manos visto por ambas partes. El pseudo- funcin de los datos de entrada se divide por la mitad y los procesos de cada uno de ellos con un algoritmo de hash diferentes ( MD5 y SHA-1 ), a continuacin, XORs juntos para crear el MAC. Esto proporciona una proteccin an si uno de estos algoritmos se encuentra para ser vulnerables. [ cita requerida ] TLS solamente. SSL 3.0 mejorado SSL 2.0 mediante la adicin de sistemas de cifrado SHA-1 y un apoyo para la autenticacin de certificado. Desde el punto de vista de seguridad, SSL 3.0 deben ser considerados menos deseables que TLS 1.0. El cifrado SSL 3.0 suites tienen un proceso de derivacin de claves dbiles, la mitad de la clave maestra que se establece es totalmente dependiente de la funcin hash MD5, que no es resistente a las colisiones y, por tanto, no se considera seguro. Bajo TLS 1.0, la clave maestra que se establece depende tanto de MD5 y SHA-1 por lo que su proceso de derivacin Actualmente no se considera dbil. Es por esta razn que las implementaciones de SSL 3.0 no se puede validar en FIPS 140-2. [6] Existe una vulnerabilidad del procedimiento de renegociacin fue descubierto en agosto de 2009, que puede conducir a ataques de inyeccin de texto contra SSL 3.0 y todas las versiones actuales de TLS. Por ejemplo, permite a un atacante que puede secuestrar una conexin https para empalmar sus propias peticiones en el comienzo de la conversacin que el cliente con el servidor web. El atacante no puede descifrar realmente el servidor de comunicacin con el cliente, por lo que es diferente de un tpico -en-el-ataque medio hombre . Una solucin a corto plazo es para los servidores web para dejar de permitir la renegociacin, que normalmente no se requieren cambios a menos que la autenticacin de certificados de cliente se utiliza. Para corregir la vulnerabilidad, una extensin de la indicacin renegociacin fue propuesta para TLS. Se requiere que el cliente y el servidor de incluir y verificar la informacin de apretones de manos anteriores en cualquier renegociacin apretones de manos. [7] Cuando un usuario no presta atencin a su navegador indicacin de que la sesin es segura (por lo general un icono de candado), la vulnerabilidad puede se convirti en un hombre-en-el-ataque media verdad [8] . Esta extensin se ha convertido en una norma propuesta y se le ha

asignado el nmero de RFC 5746 . El RFC se ha implementado en los ltimos OpenSSL [9] y otras bibliotecas [ cita requerida ]. Hay algunos ataques en contra de la aplicacin en lugar del propio protocolo: [10] La mayora de entidades emisoras de certificados no se establece explcitamente basicConstraints CA = FALSO para los nodos de la hoja y una gran cantidad de navegadores y otras implementaciones de SSL (incluyendo IE6) no marque el campo. Esto puede ser explotado para el ataque "man-in-the-middle en todas las posibles conexiones SSL. Algunas implementaciones (incluyendo versiones anteriores de Microsoft API de cifrado , los servicios de seguridad de redes y GnuTLS ) dejar de leer los caracteres que siguen el carcter nulo en el campo del nombre del certificado, que puede ser explotado para engaar al cliente en la lectura del certificado como si fuera que vino desde el sitio autntico, por ejemplo, paypal.com \ 0.badguy.com sera un error como el sitio de paypal.com en lugar de badguy.com. SSL 2.0 es defectuoso en una variedad de formas: [ cita requerida ] Idntico claves criptogrficas se usan para la autenticacin y el cifrado de mensajes. SSL 2.0 tiene una dbil construccin de MAC que utiliza la funcin hash MD5 con un prefijo secreto, que lo hace vulnerable a los ataques de extensin de longitud. SSL 2.0 no tiene ningn tipo de proteccin para el apretn de manos, es decir, un hombre-en-el-medio ataque rebaja puede pasar desapercibido. SSL 2.0 utiliza la estrecha conexin TCP para indicar el final de los datos. Esto significa que los ataques de truncamiento son posibles: el atacante simplemente forja un FIN TCP, dejando el receptor desconocen de un fin ilegtimo de mensaje de datos (SSL 3.0 soluciona este problema al tener una alerta de cierre explcito). SSL 2.0 supone un servicio nico y un certificado de dominio fijo, lo que choca con la caracterstica estndar de alojamiento virtual de servidores Web. Esto significa que la mayora de sitios web son prcticamente deterioro del uso de SSL. TLS / SNI corrige esto, pero no est implementado en los servidores web por el momento. SSL 2.0 est deshabilitado de forma predeterminada en Internet Explorer 7 , [11] Mozilla Firefox 2 y Firefox 3, [12] y Safari . Despus de que enva una ClientHello TLS, si Mozilla Firefox encuentra que el servidor no puede completar el apretn de manos, se intentar recurrir al uso de SSL 3.0 con un SSL 3.0 ClientHello en SSL 2.0 de formato para maximizar la probabilidad de xito apretn de manos con los servidores ms antiguos . [13] Soporte para SSL 2.0 (y dbiles de 40 bits y 56 bits de cifrado) se ha eliminado completamente de la Opera de la versin 9.5. [14]