 Básicamente, la conversa de la próxima vez es sobre deployar TLS 1.3 y es por Filippo Valzoldo y Nick Sullivan y el TLS 1.3. Le damos la bienvenida, Filippo. Hola, vamos a hablar de TLS 1.3, que es la más nueva versión de TLS, que es sobre seguridad, en la capa de seguridad. Ustedes seguramente conocen sobre las páginas seguras en el browser. TLS es un protocolo transparente para aplicaciones arbitrarias en la red. Se utiliza entre servidores grandes para comunicarse entre ellos o entre nodos. En los últimos 20 años ha estado evolucionando para permitir que se comuniquen clientes y servidores de la red. Estamos hablando sobre el handshake, que se amplifica la fotografía pública y las datos que vienen de servidor para client o de client para servidor, esta es la manera que funciona. El client empieza diciendo client hello al servidor y enviando los parámetros que están soportados. El servidor le recibe y envió un otro mensaje. Claro, vamos a usar esta cifra suite. Y aquí es mi quiche para utilizar en nuestro contrato. Y aquí hay un certificado que está firmado por autoridad que dice que yo soy lo que soy. Aquí hay un certificado que yo quiero que utilices para nuestra conversación. Clienta lo recibe y genera su otra parte del clave de Diffie Hellman. Y dice ahora, está bien, y esto es el final del handshake. El servidor lo recibe y... Ahora podemos enviar los datos de la aplicación del cliente al servidor, al cliente y al revés. Tenemos que hacer dos comunicaciones entre el cliente y el servidor para poder hacer cualquier cosa. Antes que podamos mover ningún bytes en la aplicación. En algunos dispositivos, en algunas zonas del mundo, puede llegar a ser segundos hasta que la comunicación está abierta. Cada vez el cliente y el servidor tienen que hacer dos comunicaciones entre ellos antes de que podamos mover datos. Entonces, TLS 1.0 y 1.1 no eran tan diferentes a 1.2. Estarás preguntándote por qué TLS 1.3 es tan diferente. TLS 1.3 es en realidad un rediseño muy grande, principalmente en el handshake. La principal diferencia es que el handshake ha sido reducido. Esto es como un handshake en TLS 1.3. Para hacer una predicción de cuál va a ser el cipher suite que va a ser utilizado. Entonces, preventivamente, prepara una par de claves para esa comunicación. Entonces, cuando envíe al cliente los sus algoritmos, el servidor ya responde con su par generado. Entonces, el cliente responde con su propio key share por su propio par de claves al servidor y ya pueden establecer la comunicación. Y entonces, pueden enviar al certificado y la firma del certificado y ya pueden enviar el mensaje de determinación. Y entonces, ya está listo para enviar toda la información de la aplicación. Entonces, ahora fuimos del cliente al servidor, del servidor al cliente y entonces ya podemos mover información. Entonces, para hacer una conexión HTTPS, no tenemos por qué esperar a cuatro comunicaciones entre el cliente y el servidor, sino que en dos comunicaciones lo tenemos ahorrando la notencia. Ahora, esta es la parte bonita, esta es la parte en que se conectan el servidor y el cliente, aparte en que comunican sus claves. Después de recibir la clave, va a haber una petición para utilizar un segundo algoritmo para revisar esta clave. Y esto es lo que hace diferente que sea el handshake diferente de lo que teníamos en 1.2. Ahora les he estado mintiendo con esto, porque esto no siempre son dos conexiones de ida y vuelta. Algunas de ellas les llamamos resumption, que quiere decir que ya habían ocurrido en el pasado. La idea de hacer esto es que el handshake sea más rápido. Para hacerla así, así es como luce. Este es el antiguo TLS 1.2. Aquí envía un nuevo ticket de sesión. Un ticket de sesión es un bloque encriptado que el cliente tendrá que guardar. Está afirmado por una clave que solo el servidor conoce. Así, la siguiente vez que el cliente hace una conexión, cuando el cliente envía el hello, envía el ticket de sesión, y entonces el servidor puede recuperar el material, la key material, y con un solo intercambio de mensajes puede establecer la conexión. Ahora el servidor tiene claves compartidas y el cliente tiene las claves anteriores. Esto es lo que pasa a día de hoy con la mayor parte de las conexiones modernas. En el caso de TLS 1.3 resumption, la conexión no es muy diferente. Comparten un ticket de sesión con PSQ, que recibe el ticket de sesión, el set de cripto, y el mensaje final. El problema con la resumption es que si un atacante controla el ticket de sesión, puede desencriptar un atacante en el futuro, recuperar el ticket de sesión del hello client, y usarlo para desencriptar el resto de la comunicación. Y entonces alguien podría estar haciendo desencriptación pasiva solo teniendo el ticket de sesión. Y estaría muy bien si no necesitáramos utilizar esto, y hay papers muy interesantes que quitan esto. En vez de esto, lo que TLS 1.3 nos permite hacer es usar Diff Hellman para proteger el ticket de sesión. En TLS 1.3 lo que puedes hacer es enviar el ticket de sesión y tu parte de la clave, tu quiser, y entonces el servidor responde con su quiser, y entonces tenemos Forward Secrecy para recuperar las sesiones. Y entonces ahora parece igual que una conexión de 1.3. La única diferencia es que no hay certificado porque no necesitamos validar de nuevo con el certificado porque están resumiendo una conexión que ya conocen. Si el servidor puede desencriptar el ticket de sesión significa que esa es una conexión que ya conoce. Hay otra fiatura que ha sido introducida con la nueva fiatura es que se pueden hacer intercambios con cero conexiones. Las resanciones de TLS 1.2 pueden ser como mínimo una conexión con TLS 3 se pueden hacer con cero. La idea es encriptar los primeros datos antes de enviarlos al servidor. Hay que recordar que este es un servidor al que se había conectado ya antes, previamente el cliente. La sesión, el key share y después una de los datos preliminares que van a ser utilizados para hacer esta prueba. El servidor lo recibe, desencripta la ticket de sesión y los datos preliminares y entonces es que continúa con el proceso previo que es hacer el handshake con las llaves. Lo que ocurre aquí es que podemos enviar ya de una vez datos de la aplicación desde el inicio. Los handshakes 0RTT son casi imposibles de ser removidos. Ahora lo que estábamos haciendo para mejorar el 1.0, el TLS 1.0 no nos va a ayudar en este caso, porque los datos preliminares solo están encriptados con una llave. Y aquí es donde un hacker podría entrar y desencriptar el ticket de sesión y después utilizar esa misma llave para desencriptar los datos preliminares que siguen. Para ello no necesita estar haciéndolo en línea, puede ser con una grabación de una sesión previa, siempre y cuando los tickets de sesión correspondan. Por ello, esto nos sirve si estamos utilizando un TLS 1.2, una recapitalación. En TLS 1.2 se crecía hacia adelante. Eso quiere decir que las conexiones de 1.2 siempre las puedes enviar con secrecía más adelante. El problema es cuando empezamos a pensar en el ticket de sesión lo que podría pasar cuando lo envías o lo reenvías hacia una siguiente conexión. Porque en cada una de estos pasos se puede grabar y tomar ese ticket de sesión para después rectificar el ticket de sesión. Dile, decía que hay dos problemas. El segundo es, en caso de que tengas algunos datos en el paquete de datos preliminares que está en el barco de datos preliminares que te dejas, y te digas que te dejas. Pero en el caso de que tengas algunos datos preliminares, y que te dejas de que tengas eliminar es que tenga, por ejemplo, cookies. Se envía una petición al servidor, y esto ya implica una transacción. Si un atacante quiere que se haga esto en repetidas ocasiones, a pesar de que esto ocurre en varias en repetidas ocasiones, si existe una cookie que haya sido introducida por un atacante, entonces en alguna de esas peticiones se puede posteriormente reconstruir la conexión con los mensajes que ya se habían visto previamente. Pero, por ejemplo, como Kalfra, estás viajando a diversos centros alrededor del mundo, este puede ser un caso, por ejemplo, en caso de que en diferentes partes del mundo, de diferentes máquinas, se estén enviando las mismas peticiones. Y, en ese caso, el servidor solo dice, automáticamente, sí, es verdad, tengo el ticket de sesión, he visto esta petición previamente y procede con el proceso y simplemente desencripta los datos que prosiguen. Desde cuando tengo este ticket? El servidor mira esta información y si no conforme a lo que has visto antes, eso significa que, por ejemplo, si el atacante quiere usar los mismos datos que ya fueron utilizados antes, no puedo, pero solamente si el ataque es muy rápido, se puede re-rejectar. Y estos datos se pueden ser aceptados o rejitados. Y solamente el servidor es que decide si los mensajes están aceptados o rejitados. Si lo coge, entonces se da cuenta de que va a ser capaz de procesarlo y darse cuenta de que no es una conexión que puede recoger. Si el servidor espera para el mensaje de finalización, cuando el cliente llega ahí, significa que también el early data no fue rejitado, porque ese mensaje finalizó todo el handshake. Cuando el cliente llega ahí, significa que también el early data no fue rejitado, porque ese mensaje finalizó todo el handshake. Cuando el cliente responde con el mensaje de final, se da cuenta de que no ha sido un reply attack, porque los mensajes están todos atalos entre sí a través del mensaje final. Entonces, tiene que hacer un buffer donde tiene un hueco para hacer un... donde alguien puede tener un hueco para hacer un ataque. Es el máximo de early data que el cliente puede enviar. Si vemos a alguien enviando más de eso, entonces es un atacero. Y cuando un cliente está enviando más datos de los que caben el buffer, entonces es un ataque. En ese caso, lo único que tenemos que hacer es enviar información a los clientes. Si vemos a alguien enviando más de eso, entonces es un ataque. Y si vemos a alguien enviando más de eso, entonces es un ataque. En el que si un cliente está enviando más datos de los que caben el buffer, enviar información diciendo que estos datos y que envía esta aplicación podrían ser grabados y podrían ser utilizados posteriormente. Esto es, si existen maneras de evitar que estos replays que estos grabaciones generen huecos para los ataques de los hackers, en particular cuando se tienen datos que se repitan entre aplicaciones. Todo eso está muy bien con algunos otros protocolos, pero ¿qué pasa con HTTP? Lo que dice es, pide la petición y ver lo que tiene que responder el servidor. ¿Por qué? Porque incluso si fueran grabados y reproducidos de nuevo, no pasa nada. El problema es, puedes poner un servidor en internet que dice manda tu dinero en un protocolo PHP, HTTP, y el asunto es, puede existir otro servidor que haga la misma petición y simplemente pides el dinero dos veces. ¿Qué se puede hacer en estos casos? Bueno, si quieres ver el video, puedes hacer en estos casos. Bueno, hay que encontrar compromisos. Esto ya depende de la aplicación, es específico para cada aplicación. El asunto es, esto es lo que hace Google, por ejemplo, ya que ellos diseñan las aplicaciones y ellos pueden ver en qué casos se pueden permitir estas repeticiones y en qué casos no. Es Zweeping, asumption, wanted thing, to hope for some middle ground. Something we might decide to do is to only allow getting to the... T Dakota slash, approximately. Nosotros estamos todavía trabajando en ver cómo incluir esto en una aplicación. Así que si tienes una aplicación que va a ser interesante, que puede ser muy vulnerable, tengo malas noticias. Está demostrado que los navegadores a día de hoy pueden hacer un replay sin necesidad de TLS3, así que el mundo no va a ser peor que lo que ya asiste ahora. Los criptógrafos están de nuevo haciendo los protocolos de seguridad para los próximos 50 años. Con más seguridad en la que necesitamos, ¿verdad? Te puedo asegurar que uno de los grandes cambios aún más importantes que el de los roundtrapes es reducir la complejidad que introduce. Gracias, Bipu. En TLS3.0 estamos buscando contacto con las personas que están en vueltas con TLSO, que han estado en vueltas en toda la complejidad y beneficios de los protocolos previos. Por ejemplo, en TLS1.2. Desde los tiempos de SSL, este es el protocolo, la manera en que hemos funcionado estos protocolos de seguridad. La idea es encriptar con la clave pública del servidor, enviarlo al servidor y el servidor con la clave privada, entonces recuperar el mensaje propiamente dicho. El asunto que es obvio aquí, que es evidente, es que si la clave privada se pierde, incluso años después se puede encriptar una conversación completa. Esto es un proceso que es relativamente burdo. Lo que nos sorprende o lo que ha sorprendido a las personas que leen la lista de correos de TLS, es lo siguiente. Este es un correo de Andrew Kennedy. Esto es lo que dice que la deprecación de RSA en el intercambio de TLS1.3 puede causar significantes problemas para las instituciones financieras. Casi cualquiera que está ejecutando TLS internamente y tiene significado. Esto suena algo crítico para algunos, ¿no? Entonces, uno de los lugares de iluminación es Kenny, que dijo que mi respuesta a esa preocupación es no. La explicación, estamos intentando construir algo más seguro. Entonces, después de esto, la gente del sector de la financiera vinieron a la mesa de estándares. Y nos enseñaron cómo tenían un montón de switches y un montón de piezas que hablaban todas las telés entre ellos. Después de esto, Matt Green les enseñó cómo hacer Diffie-Headman correctly y terminó la discusión entre estos. Sin necesidad de añadir una pieza insegura en el estado. No hagáis esto, básicamente. Matamos RSA, ¿y entonces qué más matamos? Un montón de primitivas que se utilizaban en TLS 1.1 y antes como RSA4, 310, MDA5, SHA1, ASCBC, RSA1.5, desde 1998 está roto, compresión, renegociación, lo reemplazamos por un intercambio de claves ligero. Todas estas vulnerabilidades que puede que reconozcas, así que suena bien. Toda la filosofía para TLS 1.3 en muchos lugares. Puede ser que algunos de los autores de estas publicaciones están aquí en la sala. Ahora los mecanismos que usamos son mucho más simples. TLS 1.2 es algo muy interesante. La conversación está protegida por el mensaje de fin de mensaje. Algunos ataques que podían utilizarlos. La razón es porque los F-sweets no están firmados por la clave. Esto fue cambiado en la versión reciente, 1.3, lo que más ha cambiado. Nos hemos conseguido algunas nuevas opciones diferentes. Hay una lista más corta de los algoritmos que pueden ser utilizados. Y el hecho de que tenemos menos opciones de métodos que podemos utilizar para la inscripción significa que vamos a tener menos ataques. Cuando usted se configura su servidor TLS, antes era una menú muy larga, ahora es algo muy corta. Usted puede mirar en Washack, por ejemplo. Todo le parece muy sencillo, muy fácil. TLS 1.3 ha sido un error de diseño, ya hemos hablado de las diferencias entre 1.2 y 1.3. El asunto es que un TLS 1.2 es todavía más problemático. Los tickets de sesión son los que controlan toda la sesión y el tráfico de la colección. Ya hablamos previamente del peligro de que un atacante pueda obtener sesiones de ticket de sesión a través de conexiones repetidas. Ahora en 1.3 es aún peor. Si obtienen un ticket de sesión, se pueden desencriptar también las sesiones previas desde el inicio de la cadena de mensajes. El asunto con los mensajes encadenados hacia delante es que no podías ir hacia atrás. En 1.3 se generan claves en cada eslabón de la cadena para cada sesión y para hacer que cada eslabón de la cadena hacer una conexión segura. De esta manera es que se puede evitar que se desencripte la sesión completa. Otro asunto con TLS 1.2 es... 1.2 envía el mensaje original sin encriptar, incluyendo el nuevo ticket de sesión. Al principio de cada conexión, incluido para cosas que no teníamos, vamos a tener las claves efímeras para esa conexión encritadas en esa conexión. Si tenemos un adversario pasivo que espía todas las conexiones, puede obtener las tickets de sesión al principio de cada conexión de TLS. 1.3 resuelve este problema y este tipo de ataques son completamente imposibles. La única cosa que se puede desencriptar y desencriptar después del hecho es... la información encritada. Ya, de entrada es más seguro, o al menos eso esperamos. ¿Y cómo podemos saber eso? ¿Por qué los requerimientos de seguridad han sido formalizados de esta manera? La academia de Oxford, entre otros, hay algunos papers que están analizando los requerimientos de seguridad formales. Pero, bueno, ¿quién es el que las personas que desarrollan TLS 1.3? Bueno, es la IETF, que es un grupo de voluntarios que se juntan tres veces al año. Y, bueno, ellos básicamente definen los protocolos que se van a utilizar. Esto es un tweet de TLS 1.3, donde se estaban pidiendo como lo que se deseaba de este protocolo. Y, bueno, se empezaron a diseñar documentos que se conocen como RFC, en donde se empezaban a dar los detalles de los protocolos que van a ser diseñados. En algún momento se llegó al draft 0, que es el punto de partida que se analiza y se acepta o se rechaza. Estamos hablando de hace más de tres años, en 2014, y el borrador que tenemos ahora es un borrador que yo considero que es prácticamente final. Ahora, el asunto es que durante todo este periodo, durante estos años en el ámbito de seguridad, hemos visto tantos cambios que ahora tenemos que reevaluar si esto sigue siendo actual. A raíz de las cosas que han pasado durante el desarrollo de este protocolo de seguridad. Nosotros confiamos, esperamos en que vaya a ser algo compacto, pero, bueno, estamos hablando de aproximadamente 80 páginas. Queremos que no sea una cosa terrible de leer, que sea algo preciso. Bueno, ¿y cómo es que se escribe realmente? Bueno, pues te vas a casa, llegas a casa, y entonces envías una petición para escribir en... Y te escribes en la lista de correo, después de haber subido tu texto. ¿Qué fue lo que hiciste? ¿Qué fue lo que añadiste? La lista de correo todavía sigue abierta. Hay muchas personas que han estado contribuyendo a todos los borradores durante mucho tiempo, años, y bueno, básicamente con esta manera podemos ver quién, qué personas han contribuido cuando y en qué medida ha desarrollado los documentos. Por ejemplo, borrador 9 tenía estos diagramas muy complicados de algunos árboles, de lo que se tendría que hacer con diferentes llaves. Esto está inspirado en el protocolo Qwik, que se puede consultar en paper OPTLS. Entonces, esto es lo que vemos aquí o lo que estábamos viendo, eres una parte de este diagrama muy complicado, y eso también es una parte de ese algoritmo que es bastante complicado. Y esto ha tomado una gran cantidad de trabajo, empezar con un protocolo muy grande, con un documento muy grande, y tratar de simplificarlo y de hacer un poco más concreto. El asunto es, aquí tenemos que aplicar nombres. Si alguien ha estado siguiendo toda la historia de esto, el asunto es que en las primeras versiones tenemos muy pocas iteraciones. Hay muchas opciones para tener nombres. ¿Quién cree en la audiencia que es esto se debería llamar 1.3? ¿Por qué no llamarle 1? Bueno, aparentemente hay en la audiencia más personas que piensan que esto debería ser la segunda versión. ¿Quién es de ustedes piensan que esto se debería llamar versión 4.0? ¿Por qué no ponemos ya de una vez en 2017? O Millenium o TLS-07. Muy bien. Oh, Vista. Te podemos poner TLS Vista. Esto es un Google Trans. En el mundo no se le llama TLS. No es como la gente le llama a este protocolo. La gente no le llama generalmente TLS, le llama SSL. Bueno, esta no es la única forma que hicimos. Ha habido también algunas consultas en Twitter. Y este asunto de las versiones, bueno, en realidad las versiones, y si ustedes lo ven sobre el asunto cableado, las versiones no coinciden. Esto tiene que ver con el número de borrador en el que vamos y vamos al borrador 4, por ejemplo. Es una implica que estemos en esa versión. El asunto es que en muchos servidores, si ustedes envían una petición para conectarse con 3.4, el servidor simplemente se desconecta y no lo acepta. Lo rechazó. Desde luego hay una solución que sería hacer una revisión sobre la versión de los protocolos de petición. Si esta supera 3.3, bueno, simplemente regresar un mensaje que diga, bueno, la máxima que tenemos aquí es 3.3. Y esto es precisamente lo que decíamos hace unos minutos sobre la diferencia entre tener una gran seguridad o tener una gran complejidad y es la decisión que tenemos que sopesar en cada momento. El asunto es, bueno, la intolerancia a las versiones, bueno, tenemos que manejarlas del lado de los servidores, los servidores tienen que ser capaces de responder cuando no conocen la versión de que les está haciendo la petición. Se nos termina el tiempo, pero bueno, vamos a hablar ahora sobre cómo se fueron desarrollando los estándares. En parte fue esto en el hackato 90, de 95 al abril 2016. En ese caso se tuvo un gran logro que fue la versión 1.3. En ese caso construimos a partir de la nada una versión completa de 1.3. Para poder llegar a una versión que esté más cercana a la comercial, nos dimos que echar un vistazo a las librerías que teníamos hasta ese punto. Las librerías a las que estuve, tenemos acceso, están inscritas en el lenguaje KO, en la librería estándar de KO. Viene con un aviso de que no uses nada para lo, para, para cuál, no lo uses esta librería para nada que sea bueno o justo. Estamos trabajando en enviar esto al desarrollo original y la gente de Go fueron majos en suficientemente como para abrirnos una rama de desarrollo donde estamos trabajando. Aunque utilicemos Go de ployear, es bastante difícil. La primera versión de ployear a Trist fue la versión 13 del borrador. Usamos yields muy oscuros para poder soportar diferentes versiones del borrador a la misma vez. Tenemos ramas de test que se dedican a testar todos nuestros cómics contra diferentes versiones. Puede que ya lo estés utilizando sin darte cuenta, Chrome Beta tiene implementado más o menos el 50%. Esto es como nuestros gráficos parecen a lo largo del tiempo. Ahora mismo estamos alrededor de las 700 peticiones por segundo. Todas maneras como ya dijimos, la definición es una cosa viva, el código está funcionando aunque tenga un warning. Muchas gracias y si tienen alguna pregunta. Gracias, tenemos bastante tiempo. La primera pregunta la tenemos del internet. La primera pregunta desde el internet es si la decisión de que el protocolo cero se va a ser manejado por las aplicaciones, se pregunta si esto fue una buena decisión. La siguiente pregunta desde el micrófono 1. ¿Tienes algunos números sobre cómo estos mejoras de performance se parecen? Depende mucho de cómo son los round trips. Si vives en San Francisco con una fibra rápida, no es mucha mejora, pero si vives en un país con peores conexiones, puede ser del orden de medio segundo. No hemos recolectado números formalmente. Otro mejora que ha sido añadida en TLS 1.3 es que el certificado del cliente está encriptado. Entonces, en caso de una entidad de SPIA, no puede relacionar tu identidad de un sitio a otro con el mismo cliente. Los grupos fijos de Diffie Hillman no eran un problema con el logjam attack. Esto era un problema de que el mismo grupo de Diffie Hillman estaba compartido entre muchos servidores como, por ejemplo, Apache. Ahora se usa Diffie Hillman con 200,000 bits. Con la larga de 2,48 es el mínimo, que también está suficiente para la mayoría de los casos. Otra pregunta. Disculpa, gracias para esta charla. Una otra característica que quería ser matada era SNI. Esta es la segunda cuestión sobre el mismo asunto. SNI es el parámetro que dice el servidor a qué sitio web a site queremos dar acceso. Por ejemplo, aquí. Después de conectar al servidor, le dijo que quiero conectar a google.com. El problema aquí es que el problema aquí es la misma que con el secreto adelante. Porque usted no tiene nada para utilizar para el criptaje. Por como clave. El servidor no sabe el certificado y la clave. Entonces, tenemos que hacer como dos. Por ejemplo, tenemos propuestas de utilizar multiplexado para hacer esto. Primero, establecer una conexión y después con una segunda utilizar paquetes para codificar los eslabones intermedios. Siguiente pregunta. Tu mencionaste que había algunas modificaciones entre TLS-1 y TLS-1.3. ¿Qué software es el que se ha utilizado para esto? Tamarin es el software que se ha utilizado para esto. ProScript TLS, M-A-T-L-S y NQ-S-B-T-L-S de Cambridge. Esto es básicamente el software que se ha utilizado para esto. Siguiente pregunta. Muchas gracias por su charla tan informativa. Básicamente, esto es sobre qué podría ir mal. Entonces mi pregunta es que hay muchas pequeñas compañías pequeñas que podrían obtener estos certificados mal dañados. Yo soy bastante escéptico del impacto de SPIQ. Y bueno, hemos estado viendo una explosión de papers de investigación acerca de un gran porcentaje de cómo podría ir esto mal con un gran tráfico. Para ser honesto, no tengo una respuesta concreta a tu pregunta. El asunto no se trata tanto de que estas pequeñas compañías no vayan a implementarte TLS. Si no, la ventaja de la que se pueden valer es decirles que TLS es mucho más rápido y eso puede servir de incentivo para que siguen efectivamente lo implementen. Ahora bien, esto es una decisión que se hizo por la comunidad completa a partir de la lista de correo y en realidad se está haciendo bastante conservativo, conservador con los cálculos. No puedo estar seguro de que esto realmente vaya a funcionar. Lo único que puedo decir es que espero que sí efectivamente se funcione. La siguiente pregunta viene del Internet. ¿Cuáles son las principales incompatibilidades en la implementación que han encontrado hasta ahora? Durante el desarrollo de los borradores, algunas serán acerca de la intolerancia a las versiones, especialmente en Farwalls. En algunas páginas grandes, por ejemplo PayPal, durante el proceso de comprensión, estuvimos revisando bastantes de estas incompatibilidades. En algunas partes, durante la implementación del desayuno, el desarrollo de los borradores, el desarrollo de los borradores, el desarrollo de los borradores, estoy muy feliz de poder decir que la implementación real de 1.3 no tiene este tipo de problemas. Tengo dos preguntas muy rápidas. Si almacenas datos en el servidor, no es un poco peligroso. ¿Y qué pasa con los load balancers? No es un poco peligroso, no es un poco peligroso, no es un poco peligroso, no es un poco peligroso, ¿Y qué pasa con los load balancers? O cuando tienes un montón de servidores, que la conexión puede ir a varios sitios. Este puede ser uno de los problemas para deployar la sesión Tickets en la realidad. TLS 1.3 permite que envíes múltiples tickets de sesión en una conexión. Como puede haber muchos y van a estar encriptados, cada servidor puede mirar el que conoce sin necesidad de compartir ninguna información entre ellos. Pero tickets de sesión entre diferentes servidores no pueden ser traceados por un observador pasivo. Entonces puedes mirar cómo los clientes rotan entre los diferentes servidores y elegir cómo balancear, entre tener que compartir información o enviar múltiples sesiones de tickets de sesiones. ¿Y la última pregunta? Si entendió correctamente, estás enviando números aleatorios no existentes. ¿Cuál es el resultado del mundo real con estos tests? ¿Cuántas cosas se rompen? Esperaríamos que todo funcionara bien porque los clientes ya lo implementan, pero en el momento en el que Google encendió el soporte de Grease, había conexiones que estaban terminando en TLS 1.3. Todo es una conexión en TLS 1.3, así que esto puede romper conexiones en el mundo real. Muchas gracias.