b'\n_START_ARTICLE_\nTransport Layer Security\n_START_SECTION_\nAPI de Secure Network Programming\n_START_PARAGRAPH_\nLos primeros esfuerzos de investigaci\xc3\xb3n hacia la seguridad de la capa de transporte incluyeron la interfaz de programaci\xc3\xb3n de aplicaciones (API, por su sigla en ingl\xc3\xa9s) de Secure Network Programming (SNP), la que en 1993 explor\xc3\xb3 la posibilidad de tener una API de capa de transporte segura similar a los sockets Berkeley, para facilitar la retroadaptaci\xc3\xb3n de las aplicaciones de red preexistentes con medidas de seguridad.\xe2\x80\x8b\n_START_SECTION_\nSSL 3.0\n_START_PARAGRAPH_\nEl protocolo SSL fue desarrollado originalmente por Netscape.\xe2\x80\x8b La versi\xc3\xb3n 1.0 nunca se entreg\xc3\xb3 p\xc3\xbablicamente; la versi\xc3\xb3n 2.0 se present\xc3\xb3 en febrero de 1995 pero "conten\xc3\xada una cantidad de fallas de seguridad que al final llevaron al dise\xc3\xb1o de la versi\xc3\xb3n SSL 3.0".\xe2\x80\x8b Dicha versi\xc3\xb3n, presentada en 1996, fue un redise\xc3\xb1o completo del protocolo producido por Paul Kocher, quien trabaj\xc3\xb3 con los ingenieros de Netscape Phil Karlton y Alan Freier. Las versiones m\xc3\xa1s nuevas de SSL/TLS est\xc3\xa1n basadas en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por la IETF como el hist\xc3\xb3rico RFC 6101._NEWLINE_En octubre de 2014, se detect\xc3\xb3 una nueva vulnerabilidad sobre el protocolo SSL en su versi\xc3\xb3n 3.0, la Vulnerabilidad de Poodle.\n_START_SECTION_\nTLS 1.0\n_START_PARAGRAPH_\nTLS 1.0 fue definido en el RFC 2246 en enero de 1999 y es una actualizaci\xc3\xb3n de SSL versi\xc3\xb3n 3.0. Como dice el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dram\xc3\xa1ticas, 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\xc3\xb3n puede conectarse en SSL 3.0, debilitando la seguridad.\n_START_SECTION_\nAplicaciones y adopci\xc3\xb3n\n_START_PARAGRAPH_\nSSL se ejecuta en una capa entre los protocolos de aplicaci\xc3\xb3n 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).\n_START_SECTION_\nOtros usos\n_START_PARAGRAPH_\nOtra aplicaci\xc3\xb3n con creciente uso de TLS es SMTP. TLS es tambi\xc3\xa9n el m\xc3\xa9todo est\xc3\xa1ndar para proteger la se\xc3\xb1alizaci\xc3\xb3n de aplicaciones con Session Initiation Protocol (SIP). TLS se puede utilizar para proveer autenticaci\xc3\xb3n y cifrado a la se\xc3\xb1alizaci\xc3\xb3n asociada con VoIP y otras aplicaciones basadas en SIP._NEWLINE_Aunque un n\xc3\xbamero creciente de productos clientes y servidores pueden proporcionar SSL de forma nativa, muchos a\xc3\xban no lo permiten. En estos casos, un usuario podr\xc3\xada querer usar una aplicaci\xc3\xb3n SSL independiente como Stunnel para proporcionar cifrado. No obstante, el Internet Engineering Task Force recomend\xc3\xb3 en 1997 que los protocolos de aplicaci\xc3\xb3n ofrecieran una forma de actualizar a TLS a partir de una conexi\xc3\xb3n sin cifrado (plaintext), en vez de usar un puerto diferente para cifrar las comunicaciones \xe2\x80\x93 esto evitar\xc3\xada el uso de envolturas (wrappers) como Stunnel._NEWLINE_SSL tambi\xc3\xa9n puede ser usado para tunelizar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.\n_START_SECTION_\nSSL 3.0\n_START_PARAGRAPH_\nSSL 3.0 mejor\xc3\xb3 SSL 2.0 mediante la adici\xc3\xb3n de cifrado SHA-1 y soporte para autenticaci\xc3\xb3n de certificados._NEWLINE_Desde el punto de vista de seguridad, SSL 3.0 deber\xc3\xada considerarse menos deseable que TLS 1.0. Las suites de cifrado de SSL 3.0 tienen un proceso de derivaci\xc3\xb3n de claves d\xc3\xa9biles, la mitad de la llave maestra que se establece es totalmente dependiente de la funci\xc3\xb3n 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\xc3\xb3n no est\xc3\xa1 actualmente considerado d\xc3\xa9bil. Es por esta raz\xc3\xb3n que las implementaciones SSL 3.0 no pueden ser validados bajo FIPS 140-2.\xe2\x80\x8b_NEWLINE_Hay algunos ataques contra la implementaci\xc3\xb3n en lugar del propio protocolo:\xe2\x80\x8b En las implementaciones anteriores, algunas entidades emisoras\xe2\x80\x8b no establecieron expl\xc3\xadcitamente basicConstraintsCA=False para los nodos hoja. Como resultado, estos nodos hoja pod\xc3\xadan firmar certificados piratas. Adem\xc3\xa1s, algunos programas de (incluyendo IE6 y Konqueror) no comprob\xc3\xb3 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\xc3\xa1cter nulo en el campo del nombre del certificado, lo que puede ser explotado para enga\xc3\xb1ar al cliente en la lectura del certificado como si fuera originado en el sitio aut\xc3\xa9ntico. (Por ejemplo, PayPal.com\\0.badguy.com ser\xc3\xada confundido como proveniente del sitio PayPal.com en lugar de badguy.com). Los navegadores implementaron mecanismos de degradaci\xc3\xb3n del protocolo a una versi\xc3\xb3n anterior en SSL/TLS por razones de compatibilidad. La protecci\xc3\xb3n ofrecida por los protocolos SSL/TLS contra un downgrade a una versi\xc3\xb3n anterior de un ataque man-in-the-middle activo puede ser inutilizados por tales mecanismos.\xe2\x80\x8b\n_START_SECTION_\nAtaques contra SSL/TLS\n_START_PARAGRAPH_\nLos ataques m\xc3\xa1s significativos se mencionan m\xc3\xa1s abajo:\n_START_SECTION_\nAtaque de renegociaci\xc3\xb3n\n_START_PARAGRAPH_\nUna vulnerabilidad del procedimiento en el cual la renegociaci\xc3\xb3n fue descubierto en agosto de 2009, que puede conducir a ataques de inyecci\xc3\xb3n 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\xc3\xb3n https para empalmar sus propias peticiones en el inicio de la conversaci\xc3\xb3n que el cliente tiene con el servidor web. El atacante no puede realmente descifrar la comunicaci\xc3\xb3n cliente-servidor, por lo que es diferente de un t\xc3\xadpico ataque man-in-the-middle. Una soluci\xc3\xb3n a corto plazo es que los servidores de Internet dejen de permitir la renegociaci\xc3\xb3n, que normalmente no requerir\xc3\xa1 otros cambios a menos que se utilice la autenticaci\xc3\xb3n de certificados de cliente. Para corregir la vulnerabilidad, una extensi\xc3\xb3n de la indicaci\xc3\xb3n de renegociaci\xc3\xb3n fue propuesta para TLS. Se requerir\xc3\xa1 que el cliente y el servidor incluyan y verifiquen informaci\xc3\xb3n acerca de los handshake anteriores en cualquier renegociaci\xc3\xb3n de handshake.\xe2\x80\x8b Esta extensi\xc3\xb3n se ha convertido en una norma propuesta y se le ha asignado el n\xc3\xbamero de RFC 5746. El RFC ha sido implementado por varias bibliotecas.\xe2\x80\x8b\xe2\x80\x8b\xe2\x80\x8b\n_START_SECTION_\nAtaques de reversi\xc3\xb3n de versiones\n_START_PARAGRAPH_\nHay modificaciones a los protocolos originales, como False Start\xe2\x80\x8b (aprobada y habilitada por Google Chrome\xe2\x80\x8b) o Snap Start, en las que se ha reportado que han introducido limitaciones a los ataques de reversi\xc3\xb3n de versiones para TLS\xe2\x80\x8b 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\xc3\xb3n 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\xc3\xa9trico m\xc3\xa1s d\xc3\xa9bil o de un intercambio de clave m\xc3\xa1s d\xc3\xa9bil\xe2\x80\x8b). Se ha demostrado en la conferencia sobre seguridad inform\xc3\xa1tica y de comunicaciones de la Association for Computing Machinery (ACM) que la extensi\xc3\xb3n False Start est\xc3\xa1 en riesgo bajo ciertas circunstancias, lo que podr\xc3\xada permitir a un atacante recuperar las claves de cifrado en l\xc3\xadnea y acceder a los datos cifrados.\xe2\x80\x8b\n_START_SECTION_\nAtaque BEAST\n_START_PARAGRAPH_\nEl 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una \xe2\x80\x9cprueba de concepto\xe2\x80\x9c llamada BEAST ("Browser Exploit Against SSL/TLS") usando un applet Java para violar restricciones de pol\xc3\xadticas de mismo origen, por una vulnerabilidad de CBC ampliamente conocida de TLS 1.0.\xe2\x80\x8b\xe2\x80\x8b Exploits pr\xc3\xa1cticos de esta vulnerabilidad no se conoc\xc3\xadan, la cual fue descubierta originalmente por Phillip Rogaway\xe2\x80\x8b en 2002._NEWLINE_Mozilla actualiz\xc3\xb3 las versiones de desarrollo de sus librer\xc3\xadas NSS para mitigar ataques de tipo BEAST. NSS es utilizado por Mozilla Firefox y por Google Chrome para su implementaci\xc3\xb3n de SSL. Algunos servidores web que tienen una implementaci\xc3\xb3n quebrada de la especificaci\xc3\xb3n SSL puede que dejen de funcionar como resultado de esto.\xe2\x80\x8b_NEWLINE_Microsoft emiti\xc3\xb3 el bolet\xc3\xadn de seguridad MS12-006 el 12 de enero de 2012, que corrigi\xc3\xb3 la vulnerabilidad BEAST al cambiar la forma en que el componente de Windows Secure Channel (SChannel) transmite los paquetes cifrados.\xe2\x80\x8b Por su parte, Apple habilit\xc3\xb3 por defecto la protecci\xc3\xb3n contra BEAST en la versi\xc3\xb3n OS X 10.9 Mavericks.\xe2\x80\x8b_NEWLINE_El ataque BEAST tambi\xc3\xa9n 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\xc3\xada de los sitios web.\xe2\x80\x8b\xe2\x80\x8b 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\xc3\xa1 si no es soportado tambi\xc3\xa9n por el otro extremo de la conexi\xc3\xb3n, y caer\xc3\xa1 a TLS 1.0.\n_START_SECTION_\nAtaques CRIME y BREACH\n_START_PARAGRAPH_\nLos autores del ataque BEAST tambi\xc3\xa9n son los creadores del ataque CRIME, que usa compresi\xc3\xb3n de datos para adivinar.\xe2\x80\x8b\xe2\x80\x8b Cuando se utiliza para recuperar el contenido de la cookie de autenticaci\xc3\xb3n secreta, permite a un atacante realizar un secuestro de sesi\xc3\xb3n en una sesi\xc3\xb3n web autenticada.\n_START_SECTION_\nAtaques de relleno\n_START_PARAGRAPH_\nLas versiones anteriores de TLS eran vulnerables frente al ataque de relleno de or\xc3\xa1culo 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\xc3\xada trabajando en el desarrollo de soluciones para la protecci\xc3\xb3n contra esta forma de ataque._NEWLINE_Una soluci\xc3\xb3n definitiva fue lanzada como la extensi\xc3\xb3n Encrypt-then-MAC para TLS lanzado como RFC 7366.\xe2\x80\x8b\n_START_SECTION_\nAtaque POODLE\n_START_PARAGRAPH_\nEl 14 de octubre de 2014, investigadores de Google publicaron una vulnerabilidad en el dise\xc3\xb1o de SSL 3.0, lo que hace que el modo CBC de operaci\xc3\xb3n con SSL 3.0 sea vulnerable al ataque de relleno (CVE-2014-3566). Ellos llamaron a este ataque POODLE (en ingl\xc3\xa9s, Padding Oracle On Downgraded Legacy Encryption o Relleno de or\xc3\xa1culo en Degradaci\xc3\xb3n a Cifrado Obsoleto). En promedio, los atacantes solo necesitan hacer 256 peticiones SSL 3.0 para revelar un byte de mensaje cifrado.\xe2\x80\x8b\xe2\x80\x8b_NEWLINE_Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayor\xc3\xada 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\xc3\xb3n 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.\xe2\x80\x8b\xe2\x80\x8b_NEWLINE_En general, la degradaci\xc3\xb3n de la seguridad elegante por el bien de la interoperabilidad es dif\xc3\xadcil llevar a cabo de una manera que no pueda ser explotada. Este es un reto especialmente en los dominios donde la fragmentaci\xc3\xb3n es alta.\xe2\x80\x8b\n_START_SECTION_\nAtaque RC4\n_START_PARAGRAPH_\nA 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\xc3\xadan RC4, hasta que nuevos ataques divulgados en marzo de 2013 permit\xc3\xadan que RC4 en TLS fuera quebrado completamente. En 2011 se recomendaba usar la suite RC4 como una soluci\xc3\xb3n alternativa para el ataque BEAST.\xe2\x80\x8b En 2013 una vulnerabilidad fue descubierta en RC4 sugiriendo que no era una buena soluci\xc3\xb3n para BEAST.\xe2\x80\x8b Un caso de un ataque fue propuesto por Alfardan, Bernstein, Paterson, Poettering y Schuldt que utilizaba nuevos sesgos estad\xc3\xadsticos descubiertos en la tabla de clave RC4\xe2\x80\x8b para recuperar partes del texto en claro con un gran n\xc3\xbamero de cifrados TLS.\xe2\x80\x8b\xe2\x80\x8b Un ataque de sesgo de doble byte en RC4 en TLS y SSL que requiere 13 \xc3\x97 220 cifrados para romper RC4 se dio a conocer el 8 de julio de 2013, y fue descrito como "viable" en la presentaci\xc3\xb3n de acompa\xc3\xb1amiento en el 22ndo Simposio USENIX de Seguridad el 15 de agosto de 2013.\xe2\x80\x8b\xe2\x80\x8b_NEWLINE_Sin embargo, muchos navegadores modernos han sido dise\xc3\xb1ados 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\xc3\xb3n para TLS 1.0. Los sistemas de cifrado CBC que se vieron afectados por el ataque BEAST en el pasado se est\xc3\xa1n convirtiendo en una opci\xc3\xb3n m\xc3\xa1s popular para la protecci\xc3\xb3n.\xe2\x80\x8b_NEWLINE_Microsoft recomienda deshabilitar RC4 cuando sea posible.\xe2\x80\x8b\n_START_SECTION_\nAtaque de truncamiento\n_START_PARAGRAPH_\nUn ataque de truncamiento TLS bloquea las peticiones de desconexi\xc3\xb3n de la cuenta de la v\xc3\xadctima para que el usuario sin saberlo, permanezca conectado a un servicio web. Cuando se env\xc3\xada la solicitud de fin de sesi\xc3\xb3n, el atacante inyecta un mensaje TCP FIN no cifrado (no hay m\xc3\xa1s datos del remitente) para cerrar la conexi\xc3\xb3n. El servidor, por tanto, no recibe la solicitud de cierre de sesi\xc3\xb3n y no se da cuenta de la terminaci\xc3\xb3n anormal.\xe2\x80\x8b_NEWLINE_Publicado en julio de 2013,\xe2\x80\x8b el ataque provoca servicios web como Gmail y Hotmail que muestren una p\xc3\xa1gina que informa al usuario de que han salido correctamente del servicio, al tiempo que garantiza que el navegador del usuario mantiene la autorizaci\xc3\xb3n con el servicio, lo que permite a un atacante tener el acceso para tomar el control de la cuenta que ha iniciado sesi\xc3\xb3n en el usuario. El ataque no se basa en la instalaci\xc3\xb3n de malware en el ordenador de la v\xc3\xadctima; los atacantes solo necesitan ponerse entre la v\xc3\xadctima y el servidor web (por ejemplo, mediante la creaci\xc3\xb3n de un punto de acceso inal\xc3\xa1mbrico rebelde).\xe2\x80\x8b Esta vulnerabilidad tambi\xc3\xa9n requiere acceso a la computadora de la v\xc3\xadctima.\n_START_SECTION_\nFallo Heartbleed\n_START_PARAGRAPH_\nEl fallo Heartbleed es una grave vulnerabilidad en la popular librer\xc3\xada de software criptogr\xc3\xa1fica OpenSSL, que afecta a las versiones 1.0.1 a 1.0.1f. Esta debilidad permite el robo de la informaci\xc3\xb3n 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\xc3\xa9s de Internet para aplicaciones como web, correo electr\xc3\xb3nico, mensajer\xc3\xada instant\xc3\xa1nea (IM) y algunas redes privadas virtuales (VPN).\xe2\x80\x8b_NEWLINE_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\xc3\xa1fico, los nombres y las contrase\xc3\xb1as 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.\xe2\x80\x8b\n_START_SECTION_\nForward secrecy\n_START_PARAGRAPH_\nForward secrecy es una propiedad de los sistemas criptogr\xc3\xa1ficos que garantiza que una clave de sesi\xc3\xb3n derivada de un conjunto de claves p\xc3\xbablicas y privadas no se ver\xc3\xa1n comprometidas si una de las claves privadas se ve comprometida en el futuro.\xe2\x80\x8b Sin forward secrecy, si la clave privada del servidor fuera conocida, no s\xc3\xb3lo se ver\xc3\xa1n comprometidas todas las sesiones cifradas-TLS futuras mediante ese certificado del servidor, sino tambi\xc3\xa9n las sesiones anteriores que lo utilizaban (siempre por supuesto que estas sesiones pasadas fueran interceptadas y almacenadas en el momento de la transmisi\xc3\xb3n).\xe2\x80\x8b Una implementaci\xc3\xb3n de TLS puede proporcionar forward secrecy al exigir el uso de intercambio de claves Diffie-Hellman ef\xc3\xadmeras para establecer claves de sesi\xc3\xb3n, y algunas implementaciones TLS notables lo hacen exclusivamente: por ejemplo, Gmail y otros servicios de Google que utilizan HTTPS OpenSSL.\xe2\x80\x8b Sin embargo, muchos clientes y servidores que soportan TLS (incluidos los navegadores y servidores web) no est\xc3\xa1n configurados para aplicar esas restricciones.\xe2\x80\x8b\xe2\x80\x8b En la pr\xc3\xa1ctica, a menos que un servicio web utilice Diffie-Hellman para implementar forward secrecy, todo el tr\xc3\xa1fico 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.\xe2\x80\x8b_NEWLINE_Incluso cuando se implementa el intercambio de claves Diffie-Hellman, los mecanismos de gesti\xc3\xb3n de sesi\xc3\xb3n en el servidor pueden afectar el forward secrecy. El uso de tickets de sesi\xc3\xb3n TLS (una extensi\xc3\xb3n TLS) hace que la sesi\xc3\xb3n se deba proteger por AES128-CBC-SHA256 independientemente de cualquier otro par\xc3\xa1metro TLS negociados, incluyendo a los conjuntos de cifrado de forward secrecy, y las llaves de los tickets de sesi\xc3\xb3n de larga duraci\xc3\xb3n TLS estropean el intento de implementar forward secrecy.\xe2\x80\x8b\xe2\x80\x8b\xe2\x80\x8b_NEWLINE_Desde finales de 2011, Google ha proporcionado forward secrecy con TLS por omisi\xc3\xb3n para los usuarios de su servicio de Gmail, junto con Google Docs y b\xc3\xbasqueda cifrada, entre otros servicios.\xe2\x80\x8b Desde noviembre de 2013, Twitter ha proporcionado forward secrecy con TLS para los usuarios de su servicio.\xe2\x80\x8b A diciembre de 2014, el 20,0% de los sitios web habilitados para TLS est\xc3\xa1n configurados para utilizar conjuntos de cifrado que proporcionan forward secrecy a los navegadores web.\xe2\x80\x8b\n_START_SECTION_\nEvitar Triple-DES CBC\n_START_PARAGRAPH_\nAlgunos expertos recomiendan evitar Triple-DES CBC. Debido a que RC4 y Triple-DES son los \xc3\xbaltimos cifrados soportados en las bibliotecas SSL/TLS de Windows XP, hace que sea dif\xc3\xadcil soportar SSL para programas que utilicen esta biblioteca en Windows XP. Por ejemplo en el caso de Internet Explorer para Windows XP.\xe2\x80\x8b\n_START_SECTION_\nFijaci\xc3\xb3n de Certificados\n_START_PARAGRAPH_\nUna forma de detectar y bloquear muchos tipos de ataques MITM es "fijar el certificado", a veces llamado "fijaci\xc3\xb3n SSL".\xe2\x80\x8b_NEWLINE_Un cliente que hace fijaci\xc3\xb3n de certificado agrega un paso adicional para el protocolo SSL o protocolo TLS habitual: Despu\xc3\xa9s de obtener el certificado del servidor en la forma est\xc3\xa1ndar, el cliente comprueba el certificado del servidor con los datos de confianza para validaci\xc3\xb3n. Normalmente los datos de validaci\xc3\xb3n de confianza se incluye con la aplicaci\xc3\xb3n, 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\xc3\xbablica del certificado. Por ejemplo, el Chromium y Google Chrome incluyen datos de validaci\xc3\xb3n para el certificado *.google.com que detecta certificados fraudulentos en 2011. Desde entonces, Mozilla ha introducido fiajci\xc3\xb3n de certificados p\xc3\xbablicos en su navegador Firefox.\xe2\x80\x8b_NEWLINE_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.\n_START_SECTION_\nProyecto Perspectivas\n_START_PARAGRAPH_\nEl Proyecto Perspectivas\xe2\x80\x8b 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\xc3\xadfico. Como tal, Perspectivas advertir\xc3\xadan 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\xc3\xa1lido.\n_START_SECTION_\nDetalles del Protocolo\n_START_PARAGRAPH_\nEl protocolo TLS intercambia registros- los que encapsulan los datos que se intercambian en un formato espec\xc3\xadfico (ver m\xc3\xa1s abajo). Cada registro puede ser comprimido, cifrado y empaquetado con un c\xc3\xb3digo de MAC (C\xc3\xb3digo de Autenticaci\xc3\xb3n del Mensaje), todo dependiendo del estado de la conexi\xc3\xb3n. 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\xc3\xb3n 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\xc3\xb3n 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 \xc3\xbatiles transferidos en TLS y el procedimiento para establecer y supervisar la transferencia.\n_START_SECTION_\nHandshake TLS\n_START_PARAGRAPH_\nCuando se inicia la conexi\xc3\xb3n, el registro encapsula un protocolo de "control"- el protocolo de mensajer\xc3\xada de handshake (contenido de tipo 22). Este protocolo se utiliza para el intercambio de toda la informaci\xc3\xb3n requerida por las dos partes para el intercambio de los datos de las aplicaciones reales por TLS. En \xc3\xa9l se definen los mensajes de formato o que contengan esta informaci\xc3\xb3n y el orden de su intercambio. Estos pueden variar en funci\xc3\xb3n de las demandas del cliente y del servidor, es decir, existen varios procedimientos posibles para establecer la conexi\xc3\xb3n. Este intercambio inicial resulta en una conexi\xc3\xb3n exitosa TLS (ambas partes listas para transferir datos de la aplicaci\xc3\xb3n con TLS) o un mensaje de alerta (como se especifica m\xc3\xa1s adelante).\n_START_SECTION_\nHandshake reanudado\n_START_PARAGRAPH_\nLas operaciones de clave p\xc3\xbablica (por ejemplo, RSA) son relativamente costosas en t\xc3\xa9rminos de c\xc3\xa1lculo 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\xc3\xb3n o tickets de sesi\xc3\xb3n._NEWLINE_Aparte de la ventaja de rendimiento, reanudando las sesiones tambi\xc3\xa9n se puede utilizar para inicio de sesi\xc3\xb3n \xc3\xbanico, ya que se garantiza que tanto la sesi\xc3\xb3n original, as\xc3\xad 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\xc3\xada sufrir de un ataque man-in-the-middle en el que un atacante podr\xc3\xada interceptar el contenido de las conexiones de datos secundarias.\xe2\x80\x8b\n_START_SECTION_\nTickets de sesi\xc3\xb3n\n_START_PARAGRAPH_\nEl RFC 5077 extiende TLS a trav\xc3\xa9s de la utilizaci\xc3\xb3n de tickets de sesi\xc3\xb3n, en lugar de los IDs de sesi\xc3\xb3n. Define una forma de reanudar una sesi\xc3\xb3n TLS sin necesidad de almacenar el estado espec\xc3\xadfico de la sesi\xc3\xb3n en el servidor TLS._NEWLINE_Al utilizar tickets de sesi\xc3\xb3n, el servidor TLS almacena su estado espec\xc3\xadfico de la sesi\xc3\xb3n en un ticket de sesi\xc3\xb3n y env\xc3\xada el ticket de sesi\xc3\xb3n al cliente TLS para ser almacenado. El cliente se reanuda una sesi\xc3\xb3n TLS mediante el env\xc3\xado del ticket de sesi\xc3\xb3n al servidor, y el servidor reanuda la sesi\xc3\xb3n TLS en el estado espec\xc3\xadfico de la sesi\xc3\xb3n en el ticket. El ticket de sesi\xc3\xb3n est\xc3\xa1 cifrado y autenticada por el servidor, y el servidor verifica su validez antes de utilizar su contenido._NEWLINE_Una debilidad particular de este m\xc3\xa9todo con OpenSSL es que siempre limita el cifrado y la autenticaci\xc3\xb3n de seguridad del ticket de sesi\xc3\xb3n TLS transmitido a AES128-CBC-SHA256, no importa qu\xc3\xa9 otros par\xc3\xa1metros TLS sean negociados para la sesi\xc3\xb3n actual TLS.\xe2\x80\x8b Esto significa que la informaci\xc3\xb3n de estado (el ticket de sesi\xc3\xb3n TLS) no est\xc3\xa1 tan bien protegido como la sesi\xc3\xb3n TLS misma. De particular preocupaci\xc3\xb3n es el almacenamiento de OpenSSL de las claves en un contexto de aplicaci\xc3\xb3n (SSL_CTX), es decir, que se mantiene durante la duraci\xc3\xb3n de la aplicaci\xc3\xb3n, y no permite el reingreso de informaci\xc3\xb3n de los tickets de sesi\xc3\xb3n AES128-CBC-SHA256 TLS sin reiniciar el contexto a nivel de aplicaci\xc3\xb3n OpenSSL (lo que es raro, propenso a errores y a menudo requiere intervenci\xc3\xb3n administrativa manual).\xe2\x80\x8b\xe2\x80\x8b'