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

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

La primera razón es que el protocolo OCSP agrega un retraso a cada solicitud que realiza. Cada vez que desee conectarse a un servidor, primero debe conectarse a OCSP, esperar que responda y luego hacer algo más. Por lo tanto, los retrasos en la conexión no contribuyen a la popularidad de este protocolo.

La segunda razón es que no desea que OCSP afecte su capacidad de navegar por la web. Suponga que el servidor OSCP está caído, y luego puede perder Internet por completo, porque el protocolo considera que, dado que no puede verificar el certificado de alguien, es posible que todos los sitios en Internet sean malos y no se le debe permitir ir allí. Pero nadie necesita esto, por lo que la mayoría de los clientes ven la no interferencia del servidor OCSP como un desarrollo positivo.



Esto es realmente malo desde el punto de vista de la seguridad. Porque si eres un atacante y quieres convencer a alguien de que tienes un certificado legal, pero en realidad este certificado ha sido revocado, todo lo que tienes que hacer es evitar que el cliente se comunique con el servidor OCSP.

El cliente dirá esto: "Estoy tratando de solicitar una verificación de certificado del sitio que necesito, pero este OCSP no parece estar cerca, así que solo voy a este sitio". Por lo tanto, usar OCSP no es un buen plan.

En la práctica, las personas intentan crear esta alternativa, porque los clientes simplemente tienden a cometer errores graves. Entonces, por ejemplo, el navegador web Chrome se entrega al cliente, que ya tiene dentro de sí una lista de certificados que Google realmente quiere revocar. Entonces, si alguien emite incorrectamente un certificado para Gmail u otro sitio importante, como Facebook o Amazon, la próxima versión de Chrome ya contendrá esta información en la lista de verificación incorporada. De esta manera, no tiene que acceder al servidor CRL y comunicarse con OCSP. Si el navegador ha verificado que el certificado ya no es válido, el cliente lo rechaza.

Estudiante: digamos que robé la clave secreta de CA, porque no todas las claves públicas están encriptadas.

Profesor: sí, esto tendrá malas consecuencias. No creo que haya ninguna solución a este problema. Por supuesto, hubo situaciones en las que los centros de certificación se vieron comprometidos, por ejemplo, en 2011 hubo dos AC comprometidas que de alguna manera emitieron certificados para Gmail, Facebook, etc. No está claro cómo sucedió esto, tal vez alguien realmente robó su clave secreta. Pero independientemente de los motivos del compromiso, estas CA se eliminaron de la lista de autoridades de certificación de confianza, que está integrada en los navegadores, por lo que ya no estaban en la próxima versión de Chrome.

De hecho, esto causó problemas a los titulares legítimos de certificados emitidos por estos centros, porque sus certificados anteriores se volvieron inválidos y tuvieron que obtener nuevos certificados. Entonces, en la práctica, todo este alboroto con los certificados es un asunto bastante confuso.

Entonces, hemos examinado el principio general de los certificados. Son mejores que Kerberos en el sentido de que ya no necesitas que este tipo esté en línea todo el tiempo. Además, son más escalables, porque puede tener varios KDC y no necesita comunicarse con ellos cada vez que establece una conexión.

Otra característica interesante de este protocolo es que, a diferencia de Kerberos, no es necesario que autentique ambos lados de la conexión. Puede conectarse al servidor web sin tener un certificado para usted, y esto sucede todo el tiempo. Si visita amazon.com, comprobará que Amazon es el sitio correcto, pero Amazon no tiene idea de quién es y no lo sabrá hasta que se autentique en el sitio. Por lo tanto, en el nivel del protocolo de cifrado no tiene un certificado, pero Amazon tiene uno.

Esto es mucho mejor que Kerberos, porque allí debe tener una entrada en su base de datos para conectarse a los servicios de Kerberos. El único inconveniente de usar este protocolo es que el servidor debe tener un certificado. Por lo tanto, no puede conectarse al servidor y decir "oye, encriptemos nuestras cosas. No tengo idea de quién eres, pero no tienes idea de quién soy, pero encriptemos de todos modos. Esto se denomina cifrado oportunista y, por supuesto, es vulnerable a los ataques de intermediarios. Puede encriptar cosas comunes con alguien, sin conocerlo, luego un atacante que se está preparando para atacar también puede encriptar sus paquetes y protegerse de espiar.

Por lo tanto, es una lástima que estos protocolos que estamos considerando aquí, SSL, TLS, no ofrezcan este tipo de cifrado oportunista. Pero así es la vida.



Estudiante: Solo tengo curiosidad. Digamos que una vez al año, crean pares de claves con nuevos nombres. ¿Por qué no intentar usar esta tecla en particular durante todo el año?

Profesor: Creo que lo hacen. Pero algo parece estar mal con este circuito. Aquí, al igual que con Kerberos, las personas comienzan utilizando un cifrado seguro, pero con el tiempo empeora cada vez más. Las computadoras son cada vez más rápidas, se están desarrollando nuevos algoritmos que descifran con éxito este cifrado. Y si a las personas no les importa mejorar la confiabilidad, los problemas crecen. Entonces, por ejemplo, sucede cuando se firma una gran cantidad de certificados.

Hay dos matices aquí. Hay un esquema de firma de clave pública. Además, dado que la clave pública cifrada tiene algunas limitaciones, al firmar un mensaje, en realidad, solo se firma el hash de este mensaje, porque es difícil firmar un mensaje gigantesco, pero es fácil firmar un hash compacto.

El problema surgió porque la gente usaba MD5 como una función hash, convirtiendo la firma de un gran mensaje en una cosa de 128 bits que estaba encriptada. Quizás MD5 era bueno hace 20 años, pero con el tiempo, la gente descubrió debilidades en él que podrían ser explotadas por un atacante.

Supongamos que en algún momento alguien realmente solicita un certificado con un hash MD5 específico, y luego analiza cuidadosamente otro mensaje que fue hash con el mismo valor MD5. Como resultado, tenía una firma de CA con hash, y luego apareció otro mensaje, o una clave diferente, o un nombre diferente, y ahora puede convencer a alguien de que está firmado con el certificado correcto. Y esto realmente está sucediendo. Por ejemplo, si pasa mucho tiempo tratando de descifrar una clave, eventualmente tendrá éxito. Si este certificado usa encriptación, se puede descifrar usando el método de fuerza bruta.

Otro ejemplo del uso fallido del cifrado es el algoritmo RSA. No hablamos sobre RSA, pero RSA es uno de estos sistemas criptográficos de clave pública que le permite cifrar y firmar mensajes. En estos días puedes gastar mucho dinero, pero al final, descifrar claves RSA de 1000 bits. Probablemente tendrá que hacer una gran cantidad de trabajo, pero esto es fácil de hacer durante todo el año. Puede pedirle a la autoridad de certificación que firme un mensaje o incluso tome la clave pública existente de alguien, intente encontrar la clave secreta adecuada para ello o piratee manualmente.
Por lo tanto, debe mantenerse al día con el atacante, debe usar claves RSA más grandes o usar un esquema de cifrado diferente.

Por ejemplo, ahora las personas no usan hashes y certificados MD5. Utilizan el algoritmo de hash criptográfico SHA-1. Durante algún tiempo proporcionó la seguridad necesaria, pero hoy es una defensa débil. Ahora Google está intentando forzar activamente a los desarrolladores web y de navegadores a abandonar el uso de SHA-1 y usar una función hash diferente, porque está bastante claro que, tal vez, después de 5 o 10 años no será difícil atacar con éxito SHA-1. Su debilidad ya ha sido probada.

Entonces, supongo, la bala mágica como tal no existe. Solo debes asegurarte de seguir desarrollándote en paralelo con los hackers. Por supuesto, el problema existe. Por lo tanto, todas las cosas de las que hablamos deben basarse en un cifrado adecuado o en el hecho de que es muy difícil de descifrar. Por lo tanto, debe elegir las opciones apropiadas. Al menos hay una fecha de vencimiento, por lo que es mejor elegir una fecha de vencimiento de 1 año, en lugar de 10 años.



Esta clave de CA crea un problema más grave, ya que no tiene una fecha de vencimiento. Por lo tanto, debe elegir configuraciones de seguridad más agresivas, por ejemplo, claves RSA de 4000 o 6000 bits, o algo más. O un esquema de cifrado diferente, o todos juntos, pero no use SHA-1 aquí.

Ahora veamos cómo integramos este protocolo en una aplicación específica, es decir, un navegador web. Si desea proporcionar comunicación de red o comunicación con sitios que usan criptografía, hay tres cosas en el navegador que debemos proteger.

Lo primero, A es la protección de datos en la red. Esto es relativamente fácil porque solo vamos a ejecutar un protocolo muy similar al que describí hasta ahora. Cifraremos todos los mensajes, los firmaremos, nos aseguraremos de que no hayan sido alterados, en general, haremos todas estas cosas maravillosas. Así es como protegeremos los datos.

Pero hay dos cosas más en el navegador web de las que realmente debemos preocuparnos. Entonces, el primero, B, es el código que se usa en el navegador, por ejemplo, JavaScript o datos importantes que se almacenan en el navegador, sus cookies o el almacenamiento local, todo esto debe estar protegido de alguna manera contra los piratas informáticos. En un segundo te diré cómo protegerlos.

El último, C, en el que a menudo no piensa, pero que puede resultar un problema real en la práctica, es proteger la interfaz de usuario. Y la razón de esto es que, en última instancia, la mayoría de los datos confidenciales que nos preocupan la protección provienen del usuario. Por lo tanto, el usuario imprime datos en algún sitio, y probablemente tenga varias pestañas de diferentes sitios abiertos simultáneamente, por lo que necesita poder distinguir con qué sitio está realmente interactuando, en cualquier momento dado.



Si ingresa accidentalmente la contraseña de Amazon en algún foro web, esto no tendrá consecuencias desastrosas, dependiendo de cuánto le importe su contraseña de Amazon, pero aún así será desagradable. Por lo tanto, realmente desea tener una buena interfaz de usuario que ayude al usuario a comprender lo que está haciendo, si imprime datos confidenciales en el sitio correcto y si algo le sucede a estos datos después de enviarlos. Así que esto resulta ser un problema bastante importante para proteger las aplicaciones web.

Entonces, hablemos de lo que hacen los navegadores modernos con estas cosas A, B y C. Como mencioné, para proteger los datos en la red, simplemente usaremos este protocolo, llamado SSL o TLS, si se utiliza el cifrado y la autenticación de datos.



Esto es muy similar a lo que discutimos e incluye autoridades de certificación, etc. Y luego, por supuesto, hay muchos más detalles. Por ejemplo, TLS es extremadamente complejo, pero no lo consideraremos desde este punto de vista. Nos centraremos en la protección del navegador, que es mucho más interesante. Debemos asegurarnos de que cualquier código o dato entregado a través de conexiones no encriptadas no sea capaz de cambiar el código y los datos recibidos de una conexión encriptada, porque nuestro modelo de amenaza es tal que un atacante a través de la red puede manipular todos los datos no encriptados.

Entonces, si tenemos algún tipo de código JavaScript no encriptado que se ejecuta en nuestro navegador, deberíamos asumir que podría haber sido manipulado por un atacante porque no estaba encriptado. No se autenticó a través de la red. Y, por lo tanto, debemos evitar su interferencia de cualquier página que se entregó a través de una conexión no cifrada.

Por lo tanto, el plan general es que para esto vamos a introducir un nuevo esquema de URL, que llamaremos HTTPS. A menudo ves esto en las URL. El nuevo esquema de URL es que ahora estas URL son simplemente diferentes de las direcciones HTTP. Entonces, si tiene una URL con este HTTPS: //, entonces tiene una fuente de origen diferente a las URL HTTP normales, porque estas últimas pasan por parches no encriptados, pasan por SSL / TLS. De esta manera, nunca confundirá este tipo de direcciones si la misma política de origen funciona correctamente.

Entonces esta es una pieza del rompecabezas. Pero también debe asegurarse de distinguir correctamente los sitios cifrados entre sí, porque por razones históricas utilizan diferentes políticas de cookies. Entonces, primero hablemos sobre cómo distinguiremos los diferentes sitios cifrados entre sí.

El plan es que el nombre de host a través de la URL debe ser el nombre en el certificado. De hecho, resulta que las autoridades de certificación van a firmar el nombre del host, que aparece en la URL como el nombre de la clave pública del servidor web. Como tal, Amazon supuestamente posee un certificado para www.amazon.com . Este es el nombre en nuestra tabla que tiene la clave pública correspondiente a su clave privada.



Esto es lo que buscará el navegador. Entonces, si recibe un certificado, si intenta conectarse u obtener la URL de foo.com , significa que el servidor representa con precisión el certificado auténtico de foo.com. De lo contrario, digamos, tratamos de contactar a un chico y contactamos a otro, porque él tiene un nombre completamente diferente en el certificado al que nos conectamos. Esto será un desajuste de certificado.

Así es como distinguiremos los diferentes sitios entre sí: llevaremos a CA a esto para ayudarnos a distinguir estos sitios unos de otros, porque las CA prometen emitir certificados solo a los miembros correctos de la red. Entonces, esto es parte de la misma política de origen, según la cual dividimos el código en partes. Como recordará, las cookies tienen una política ligeramente diferente. Son casi del mismo origen, pero no del todo, las cookies tienen un plan ligeramente diferente. Las cookies tienen una llamada bandera de seguridad, Bandera segura. La regla es que si las cookies tienen este indicador, se envían solo en respuesta a solicitudes HTTPS o junto con solicitudes HTTPS. Las cookies con y sin un indicador de seguridad se relacionan entre sí como https y solicitudes http.



Esto es un poco complicado. Sería más fácil si una cookie simplemente indicara que era una cookie para el host HTTPS, y que era una cookie para el host HTTP, y que eran completamente diferentes. Esto sería muy claro en términos de aislar sitios seguros de los inseguros. Desafortunadamente, por razones históricas, las cookies usan este extraño tipo de interacción.

Por lo tanto, si una cookie se marca como segura, solo se aplica a los sitios HTTPS, es decir, tiene el host correcto. Las cookies seguras solo se aplican a las URL de host HTTPS, mientras que las cookies inseguras se aplican a ambos tipos de URL, tanto para https como para http, por lo que en solo un segundo esto se convertirá en una fuente de problemas para nosotros.

Y el último toque que los navegadores web pusieron para tratar de ayudarnos a este respecto es el aspecto de la interfaz de usuario en el que van a ingresar algún tipo de icono de candado para que los usuarios puedan verlo. Por lo tanto, debe prestar atención al icono de candado en la barra de direcciones del navegador y la URL para averiguar en qué sitio se encuentra realmente.

Los desarrolladores de navegadores web esperan que se comporte de esta manera: una vez que acceda a un sitio web, primero mire la URL y asegúrese de que este sea el nombre del host con el que desea hablar, y luego encontrará el icono de candado y Entiendo que todo está bien. Este es un aspecto de la interfaz de usuario del navegador.

Sin embargo, esto no es suficiente. Resulta que muchos sitios de phishing simplemente incluirán la imagen del icono de candado en el sitio en sí, pero usarán una URL diferente. Y si no sabe cuál debería ser la dirección de este sitio, puede ser engañado. En este sentido, este lado de la interfaz de usuario es un poco confuso, en parte porque los propios usuarios a menudo están confundidos. Entonces, es difícil decir qué hay aquí. Por lo tanto, nos centraremos principalmente en el segundo aspecto, B, que sin duda es mucho más fácil de discutir. ¿Tienes preguntas sobre esto?



Estudiante: Noté que algunos sitios cambian con el tiempo de HTTP a HTTPS.

Profesor: sí, los navegadores evolucionan con el tiempo, y esto se confirma por el hecho de que obtienen un icono de candado. Algunos navegadores establecen un ícono de candado solo si todo el contenido o todos los recursos en su página también se transmiten a través de https. Entonces, uno de los problemas que HTTPS está tratando de resolver por la fuerza es contenido mixto o problemas con tipos inseguros de contenido incrustado en la página. Por lo tanto, a veces no podrá obtener un icono de candado debido a esta verificación. Si el navegador Chrome considera que el certificado del sitio no es lo suficientemente bueno y utiliza criptografía débil, entonces no le dará un icono de candado. Sin embargo, los diferentes navegadores actúan de manera diferente, y si Chrome no le da un ícono de candado, entonces Firefox sí. Por lo tanto, una vez más, no hay una definición clara de lo que significa este ícono de bloqueo.

Veamos qué problemas pueden surgir al implementar este plan. En HTTP normal, estamos acostumbrados a confiar en DNS, que debería darnos la dirección IP correcta en el servidor. DNS HTTPS URL-? DNS DNS?

: , , , IP-.

: , , , amazon.com.

: , - amazon.com, IP-.

: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?

: , HTTPS?

: , , .

: , HTTP URL.

: , HTTPS, .

: .

: , . . , CA, , , , - , .

, - https , - , , , , , , .

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

, , , . , amazon.com www.amazon.com , , , .

-, , , . , : „ , , , , ». , - , . .

, DNS, , , .

, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .

, — , ? , , ? , ?



: , - , . , .

: , , , , , , : « »! , , - , , , , . , .

: , .

: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .

, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .

52:10

MIT « ». 14: «SSL HTTPS», 3


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?