Curso MIT "Seguridad de sistemas informáticos". Lección 14: "SSL y HTTPS", parte 1

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3
Lección 14: "SSL y HTTPS" Parte 1 / Parte 2 / Parte 3

Ahora veremos cómo se utilizan los protocolos criptográficos para proteger las conexiones de red en Internet y cómo generalmente interactúan con los factores de la red. Antes de profundizar en los detalles, quiero recordarles que habrá una prueba el miércoles, pero no en esta audiencia, sino en Walker, en el 3er piso, durante el tiempo de conferencia habitual.



Entonces, hoy hablaremos sobre cómo Internet usa la criptografía para proteger una conexión de red, y consideraremos dos temas estrechamente relacionados.

El primero es cómo proteger criptográficamente las conexiones a una escala mayor que la que protege el sistema Kerberos, que cubrimos en la última conferencia. El segundo es cómo integrar esta protección criptográfica, proporcionada a nivel de red, en toda la aplicación, y cómo el navegador web garantiza el uso de la protección provista por el protocolo criptográfico. Estos temas están estrechamente relacionados, por lo que resulta que la protección de las comunicaciones de red es bastante fácil de proporcionar, porque la criptografía siempre funciona. Pero integrarlo en el navegador es una tarea mucho más difícil que construir un sistema en torno a la criptografía.

Antes de sumergirnos en esta discusión, quiero recordarles los elementos básicos de la criptografía que utilizaremos.

En nuestra última conferencia sobre Kerberos, utilizamos criptografía simétrica, o
cifrado y descifrado. Su significado es que tiene una clave secreta K y dos funciones. Por lo tanto, puede tomar algún dato, llamémoslo P, este es texto sin formato al que puede aplicar la función de cifrado, y esta es la función de alguna tecla K. Y si cifra este texto sin formato, obtendrá el texto cifrado C. De manera similar, tenemos hay una función de descifrado D que usa la misma clave K, como resultado de lo cual el texto cifrado C se convertirá en texto plano P. Esta es la primitiva alrededor de la cual se construyó Kerberos.



Pero resulta que hay otras primitivas que serán útiles para la discusión de hoy, y que se denominan cifrado y descifrado asimétrico. La idea aquí es tener diferentes claves para el cifrado y descifrado. Veamos por qué esto es tan útil.

Aquí hay una función E, que puede encriptar un determinado conjunto de mensajes P con una determinada clave pública pk, como resultado, para obtener el texto encriptado C.Para desencriptarlo con la función D, solo necesita especificar la clave secreta correspondiente sk y obtener el texto fuente P.



La conveniencia del cifrado asimétrico es que puede publicar una clave pública en Internet y las personas pueden cifrar mensajes por usted, pero necesita una clave secreta para descifrar sus mensajes. Hoy veremos cómo se usa esto en el protocolo. En la práctica, a menudo utilizará la criptografía de clave pública de una manera ligeramente diferente. Por ejemplo, en lugar de cifrar y descifrar mensajes, es posible que deba firmar o verificar mensajes.

Resulta que a nivel de implementación, estas son operaciones relacionadas, pero a nivel de aplicación API pueden parecer un poco diferentes. Por ejemplo, puede firmar el mensaje M con su clave secreta sk y obtener alguna firma S. Luego puede verificar este mensaje con la clave pública correspondiente pk y, como resultado, obtener un indicador lógico que indica si la firma S es correcta para el mensaje M.



Aquí hay algunas garantías relativamente intuitivas que proporcionan estas características. Si, por ejemplo, recibió esta firma y se verifica correctamente, significa que tuvo que ser generada por alguien con la clave secreta correcta. ¿Eso está claro?

Luego, intentemos descubrir cómo proteger las conexiones de red a una escala mayor que Kerberos. En Kerberos, teníamos un modelo bastante simple, donde todos los usuarios y servidores usaban algún tipo de conexión con el objeto KDC, que tenía esta tabla gigante de usuarios, servicios y sus claves. Siempre que un usuario quiera hablar con algún servidor, debe pedirle a KDC que cree el ticket que necesita en base a esta mesa gigante.



Así que esto parece un modelo bastante simple. Entonces, ¿por qué necesitamos algo más? ¿Por qué Kerberos no es lo suficientemente bueno para trabajar con sitios? ¿Por qué Internet no usa Kerberos exclusivamente para proteger todas las conexiones?

Respondiste correctamente, porque el único KDC debería confiar en todos, y esto es malo. Puede tener problemas si considera que cierta máquina es absolutamente segura.

Quizás las personas en el MIT estén dispuestas a confiar en alguien en la red local administrada por KDC, pero no todos en Internet.

Y la respuesta del segundo alumno también es correcta: es muy difícil administrar una cantidad tan enorme de claves. De hecho, puede ser muy difícil construir un KDC único que pueda administrar mil millones de claves o diez mil millones de claves para todas las personas en el mundo. Otra complicación del uso de Kerberos para todo Internet es que todos los usuarios deben tener una clave, o deben ser conocidos por KDC. Ni siquiera puede usar Kerberos en nuestro instituto para conectarse a algunos servidores si no tiene una cuenta en la base de datos de Kerberos. Si bien para toda Internet es bastante razonable esperar que cuando vayas a la computadora, no sepa en absoluto quién eres, pero te permitirá ir al sitio web de Amazon, que está protegido por criptografía.



¿Eh?

Hay varias otras cosas que espera de un protocolo criptográfico, y veremos cómo aparecen en SSL. Pero la idea clave es que esta solución es la misma para Kerberos y para SSL o TLS. Tiene razón cuando menciona que los protocolos Kerberos originales sobre los que leemos en los materiales de la conferencia se desarrollaron hace mucho tiempo. Y si queremos usarlos para la Internet moderna, entonces tendrán que cambiar algo. ¿Qué otras ideas tienes, por qué no deberíamos usar Kerberos?

Así es, hay un problema de escalado al restaurar el acceso, y posiblemente al registrar nuevos usuarios, porque tendrá que ir personalmente a alguna oficina de cuentas y obtener una cuenta allí. Que mas

Estudiante: El servidor Kerberos siempre debe estar en línea.

Profesor: sí, este es otro problema. Hemos enumerado algún tipo de problemas de administración, pero a nivel de protocolo, KDC siempre debe estar en línea, porque en realidad sirve como intermediario para cualquiera de sus interacciones con los servicios. Esto significa que cada vez que visita un nuevo sitio web, debe hablar con KDC. En primer lugar, será un cuello de botella en términos de rendimiento. Al igual que otros tipos de escalabilidad, este principio conducirá a la escalabilidad del rendimiento, mientras que los principios enumerados anteriormente solo conducen a la escalabilidad de la administración.



Entonces, ¿cómo podemos resolver este problema utilizando estos principios? La idea es usar el cifrado de clave para dejar de usar KDC.

Primero averigüemos si puede establecer una conexión segura si solo conoce algunas de las claves públicas del otro lado. Y luego veremos cómo conectamos la versión de clave pública de KDC a la autenticación de las partes en este protocolo. Si no desea usar KDC, puede hacer lo siguiente con la criptografía de clave pública: de alguna manera, descubra la clave pública del socio en el otro lado de la conexión. Entonces, en Kerberos, si quiero conectarme a un servidor de archivos, solo sé la clave pública del servidor de archivos desde algún lugar. Como estudiante de primer año, recibo una copia impresa que dice que la clave pública del servidor de archivos es tal y tal, y puedo usarla para conectarme.

Simplemente puede cifrar el mensaje para la clave pública del servidor de archivos al que desea conectarse. Pero resulta que en la práctica, estas operaciones con estas claves públicas son bastante lentas. Son varios órdenes de magnitud más lentos que las claves de cifrado simétrico. Por lo tanto, en la práctica, generalmente siempre desea abandonar el uso del cifrado público.

Por lo tanto, un protocolo típico podría verse así. Tiene A y B, quieren comunicarse y A conoce la clave pública B. Al mismo tiempo, A genera algún tipo de clave de sesión S, simplemente eligiendo un número aleatorio para ello. Entonces A está a punto de enviar la clave de sesión S B, por lo que parece Kerberos. Vamos a cifrar la clave de sesión S para B.

Si recuerdas, en Kerberos, para hacer esto, necesitábamos un KDC porque A no conocía la clave para B o no se le permitió saberlo, porque es un secreto que solo B puede saber. Pero con una clave pública, puedes hacerlo inmediatamente, solo encripte el secreto con esta clave pública de Bspk y envíe el mensaje B. Ahora B puede descifrar este mensaje y decir: Necesito usar esta clave secreta. Ahora tenemos un canal de comunicación donde todos los mensajes se cifran simplemente con esta clave secreta S.



Entonces, hay algunas características útiles en este protocolo. En primer lugar, eliminamos la necesidad de tener KDC en línea y generar una clave de sesión para nosotros. Simplemente podríamos garantizar la confidencialidad de la información transmitida si una de las partes en la conexión la genera y luego la cifra para el otro lado sin usar KDC.

Otra cosa buena es la confianza de que solo B puede leer los mensajes enviados de A a B, porque solo B puede descifrar este mensaje. Por lo tanto, B debe tener la clave privada correspondiente S.

Estudiante: ¿importa quién da esta clave: usuario o servidor?

Profesor: tal vez. Creo que depende de las propiedades que desee de este protocolo. Por lo tanto, ¿qué pasa si A comete un error o utiliza la aleatoriedad incorrecta, el servidor que envía los datos de regreso piensa: "Oh, ahora estos son los únicos datos que A verá". Es posible que esto no sea del todo correcto, por lo que debe pensarlo. Hay varios otros problemas con este protocolo.

Estudiante: ¿Puede un atacante usar una clave para enviar mensajes repetidos?

Profesor: sí, el problema puede ser que puedo enviar estos mensajes nuevamente, y parecerá que A está enviando el mensaje B nuevamente, y así sucesivamente.

Por lo tanto, generalmente la solución a este problema es que ambos lados de la conexión están involucrados en la generación de S y esto asegura que la clave que usamos sea "nueva". Porque aquí, en la figura, en realidad B no genera nada, por lo que estos mensajes de protocolo tienen el mismo aspecto cada vez.

Por lo general, sucede que un lado elige un número aleatorio como S, y luego el otro lado, B, también elige un número aleatorio, generalmente llamado nonce. Hay dos números y una clave que no está realmente seleccionada solo por un lado, es un hash que ambos lados han elegido para la interacción conjunta. Además del hash, puede usar el protocolo Diffie-Hellman, que examinamos en la última conferencia, gracias al cual obtiene privacidad primero. Esta es una matemática más complicada que simplemente dividir dos números aleatorios que han elegido estos dos lados. Pero entonces obtendrá una propiedad tan buena como la clave secreta compartida original, eliminando la necesidad de transferir la clave de descifrado al transmitir datos cifrados.

Por lo tanto, los ataques repetidos se pueden evitar de la siguiente manera. B genera nonce y luego establece la clave secreta real S ', que se utiliza para hacer hash de la clave secreta S con este nonce. Y, por supuesto, B tendría que enviar un nonce a A para averiguar qué sucede cuando ambos acuerdan la clave.



Otro problema es que no existe una autenticación real A. A sabe quién es B, o al menos sabe quién puede descifrar los datos. Pero B no tiene idea de quién está del otro lado, ya sea algún tipo de adversario que se haga pasar por otro u otra persona. ¿Cómo se puede solucionar esto en el mundo de la clave pública?

Hay varias formas de hacer esto. Una posibilidad es firmar este mensaje inicialmente, porque tenemos este buen principio de Firmar. Entonces quizás podríamos firmar esto con una clave secreta. Este signo simplemente proporciona una firma, pero presumiblemente la asigna, y también proporciona este mensaje.

Entonces B debe saber que A es una clave pública para verificar la firma. Pero si B sabe que A es una clave pública, entonces B estará bastante seguro de que A es quien envió este mensaje.



Otra cosa que puedes hacer es confiar en el cifrado. Entonces, tal vez B pueda enviar nonce a A, cifrándolo con la clave pública proporcionada por A. Y luego solo A puede descifrar nonce y generar la clave de sesión final S '. Así que hay algunos trucos que podrías hacer. Así es como funcionan actualmente los certificados de cliente en los navegadores de Internet.

Por lo tanto, A tiene una clave secreta y, por lo tanto, cuando recibe un certificado MIT personal, su navegador crea una clave secreta de larga duración y recibe un certificado. Y cada vez que envía una solicitud al servidor web, demuestra el hecho de que conoce la clave secreta de su certificado de usuario y luego establece la clave secreta S para el resto de la conexión.

Estos son problemas que se solucionan fácilmente a nivel de protocolo. Sin embargo, la base de todo lo anterior es que todas las partes conocen las claves públicas de las demás. ¿Cómo puedes encontrar la clave pública de alguien? Supongamos que quiero conectarme a un sitio web, tengo una URL a la que quiero conectarme o un nombre de host, ¿cómo puedo saber qué clave pública coincide?

Del mismo modo, si me conecto al servidor MIT para ver mis calificaciones, ¿cómo sabe el servidor cuál debería ser mi clave pública para distinguirla de la clave pública de otro estudiante de MIT?

Este es el problema principal que ha abordado el KDC. De hecho, KDC resolvió dos problemas para nosotros. Primero, generó un mensaje (Ebspk (S)), creó una clave de sesión y la cifró para el servidor. Ahora hemos solucionado esto creando criptografía de clave pública. Pero también necesitábamos hacer coincidir los nombres de las cadenas principales con las claves criptográficas de Kerberos que nos proporcionaron anteriormente.

Hay un protocolo TLC para tales cosas en el mundo HTTPS. Su significado es que continuaremos confiando en ciertos aspectos del proceso que admiten estas tablas gigantes que asignan los nombres de los participantes del proceso a las claves criptográficas. El plan es que tendremos algo llamado una autoridad de certificación, que se indica con las letras CA en todo tipo de literatura sobre seguridad de red. Esta CA también admite lógicamente la tabla, en una parte de la cual se muestran los nombres de todos los participantes, y en la otra, las claves públicas correspondientes. La principal diferencia entre este centro y Kerberos es que esta CA no tiene que estar en línea para todas las transacciones.
En Kerberos, para conectarse con alguien o encontrar la clave de otra persona, debe hablar con KDC. En cambio, en el mundo de CA, hacen esto.



Si tiene algún tipo de nombre aquí y la clave correspondiente en otra parte de la tabla, la autoridad de certificación simplemente firmará mensajes de que existen ciertas filas en esta tabla. Por lo tanto, la autoridad de certificación tendrá que tener sus propias claves públicas y privadas aquí. Utilizará una clave secreta para buscar mensajes para otros usuarios en el sistema en los que pueda confiar.

Entonces, si tiene un registro de "nombre + clave" en la base de datos de CA, CA creará un mensaje de que este nombre coincide con esta clave pública y firmará este mensaje con su clave privada de CA.



Esto le permite hacer cosas muy similares a lo que hace Kerberos, pero al mismo tiempo eliminamos la necesidad de encontrar una CA en línea para todas las transacciones. Y, en realidad, será mucho más escalable. Esto es exactamente lo que comúnmente se llama un certificado. La escalabilidad está garantizada por el hecho de que para un cliente o cualquier otra persona que use este sistema, un certificado proporcionado por una fuente no es inferior a un certificado de otra fuente. Está firmado por la clave secreta de la autoridad de certificación. Por lo tanto, puede verificar su autenticidad sin tener que ponerse en contacto con una autoridad de certificación o cualquier otra parte mencionada aquí.

Funciona asi. El servidor con el que desea hablar almacena el certificado que recibió originalmente de la autoridad de certificación. Y cada vez que te conectas a él, el servidor te dice: “OK, aquí está mi certificado. Fue firmado por esta CA. Puede verificar la firma y simplemente asegurarse de que sea mi clave pública y que sea mi nombre ".

Por otro lado, lo mismo sucede con los certificados de cliente. Cuando un usuario se conecta al servidor web, su certificado de cliente indica que su clave pública coincide con la clave secreta que se generó originalmente en el navegador. Por lo tanto, al conectarse al servidor, presentará un certificado firmado por la autoridad de certificación del MIT, que indica que su nombre de usuario corresponde a esta clave pública. , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

, -, , , , . , . «» , , .

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30 min

Curso MIT "Seguridad de los sistemas informáticos". Lección 14: "SSL y HTTPS", parte 2


La versión completa del curso está disponible aquí .

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar aquí .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?