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

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

Creo que la aplicación de HTTPS se debe a la preocupación de los usuarios que tienen demasiada discreción para decidir si usan certificados.

Otro problema que se manifiesta en la práctica y que también obliga al uso de HTTPS es un archivo adjunto inseguro o contenido mixto en una página web. El punto de este problema es que un sitio seguro o cualquier sitio web, para el caso, puede incrustar otras piezas de contenido en una página web.

Entonces, si tiene algún tipo de sitio web, por ejemplo foo.com/index.html, entonces se puede servir utilizando el protocolo HTTPS, pero dentro de la página HTML puede tener muchas etiquetas que obligan al navegador a ir a algún lado y hacerlo parte Esta página tiene algún tipo de contenido extraterrestre.



La etiqueta para este escenario se ve así:

<script scr = «http://jquery.com/…”> 

Y apunta a la fuente de jquery.com. Por lo tanto, la popular biblioteca de JavaScript facilita la interacción de muchas cosas en su navegador. Pero muchos desarrolladores web simplemente enlazan a la URL de otro sitio. Esto facilita las cosas, pero ¿cuál podría ser la trampa? Supongamos que tiene un sitio seguro y simplemente descarga jQuery desde allí.

Estudiante: podría ser falso jQuery.

Profesor: sí, lo es. En realidad, hay dos formas de obtener lo incorrecto que no espera recibir. Una posibilidad es que jQuery pueda verse comprometido. Tienes algo similar a lo que solicitaste. Si jQuery se ve comprometido, entonces esto es muy malo. Otra posibilidad es que esta solicitud se envíe a través de la red sin ningún cifrado o autenticación. Por lo tanto, si el adversario controla su conexión de red, puede interceptar esta solicitud y enviarle otro código JavaScript en respuesta, y ahora este código JavaScript funcionará como parte de su página. Y dado que trabaja en este dominio HTTPS foo.com, tiene acceso a sus cookies protegidas foo.com y cualquier otra cosa en esta página. Esto parece algo realmente malo, así que ten cuidado. Y el desarrollador web también debe tener cuidado de no cometer este tipo de error.

Por lo tanto, una de las soluciones es garantizar la seguridad de todo el contenido incrustado en una página segura. Esta es una buena guía para que la sigan muchos desarrolladores web. Entonces, tal vez debería usar jquery.com en esta línea en lugar de jquery.com . O si las URL admiten la política de origen, esto significa que puede omitir parte de HTTPS y solo decir que el origen de este script es //jquery.com/, es decir, scr = "//jquery.com / ..."



Y esto significa que esta etiqueta lo enviará a jquery.com si está en la página HTTPS, y a jquery.com si no está en HTTPS, sino en una URL HTTP normal. Esta es una forma de evitar tal problema.

Sin embargo, las personas constantemente intentan mejorar todo, por lo que una de las formas alternativas de resolver este problema es quizás incluir un hash o algo así como un indicador aquí mismo en la etiqueta:

 <script scr = «http://jquery.com/…”> 

Porque si sabe qué tipo de contenido desea descargar, probablemente no necesite descargarlo completamente utilizando el protocolo HTTPS. De hecho, no te importa quién te proporcione este contenido siempre que coincida con un hash específico.

Por lo tanto, hay una nueva especificación que le permite configurar hashes para etiquetas de este tipo. Entonces, en lugar de vincular a jquery.com con una URL HTTPS, simplemente podría decir que la fuente del script es jquery.com o incluso HTTP, pero al final del script agrega algún tipo de atributo de etiqueta, por ejemplo, el hash es igual a lo que Espero llegar desde el servidor.



Estudiante: ¿cuál es el nombre de esta especificación?

Profesor: tiene un nombre complejo, está en las notas de las notas de clase, algo así como "integridad de los recursos", integridad de los recursos. Se está implementando bastante lentamente, pero espero que en un futuro cercano se aplique en varios navegadores. Esto es similar a otra forma de autenticar contenido sin depender del cifrado de datos a nivel de red.

Por lo tanto, tenemos este plan muy general que utiliza SSL y TLS para autenticar las conexiones a un servidor específico. Esta es una forma alternativa de proteger su conexión de red. Si le importa la integridad, es posible que no necesite un canal de red seguro y encriptado. Todo lo que necesita hacer es especificar qué es exactamente lo que quiere obtener al final.

Estudiante: ¿Este código SRC no proviene del cliente?

Profesor: trabaja en el lado del cliente, pero el cliente recibe este código de algún servidor.

Estudiante: ¿Nadie puede simplemente ingresar su código JavaScript en una página?

Profesor: Creo que puede. Por lo tanto, el significado del hash es proteger el contenido de la página de los intrusos que intentan ingresar un código JavaScript diferente. Para jQuery, esto es muy importante porque jQuery es bien conocido, porque no está tratando de ocultar el código fuente de jQuery. Por lo tanto, debe asegurarse de que un atacante de red no pueda interceptar su conexión e insertar una versión maliciosa de jQuery, lo que provocará la fuga de cookies. Es cierto que cualquiera puede descubrir el hash de estas cosas por sí mismo. Por lo tanto, es una solución a los problemas de integridad, no a la privacidad.

Creo que los desarrolladores deberían estar atentos a esto cuando escriban páginas o incluyan el contenido de sus páginas HTML en las URL HTTPS. Otra preocupación que tenemos es con las cookies. Aquí es donde entra en juego la diferencia entre cookies con banderas de seguridad y solo cookies con origen de origen. Lo único que el desarrollador puede estropear aquí es simplemente olvidarse de establecer la bandera en las cookies en primer lugar, esto sucede. Tal vez solo piensa en los usuarios que solo irán a la URL HTTPS, y considera innecesario configurar las banderas. ¿Es esto un problema? Si sus usuarios son muy cuidadosos y siempre visitan las URL HTTPS, no hay problema. ¿Crees que tiene sentido en este caso dejar una bandera de seguridad en tus cookies?

Estudiante: ¿es probable que un atacante pueda conectarse a su URL y redirigirlo a un sitio malicioso?

Profesor: si. Incluso si el usuario no accede explícitamente manualmente a alguna URL en forma de texto sin formato, el atacante aún puede proporcionarle un enlace a un sitio inseguro o pedirle que descargue una imagen con una URL que no sea HTTPS. Y luego se enviarán cookies inseguras junto con la solicitud de red. Por lo tanto, esto es un problema y realmente necesita una marca, incluso si sus usuarios y sus aplicaciones son muy cuidadosos.

Estudiante: Supongo que hay URL HTTP seguras.
Profesor: sí, eso es verdad. Supongamos que tengo un sitio web que ni siquiera está escuchando en el puerto 80 y no hay forma de conectarme a través del puerto 80, entonces, ¿por qué podría haber un problema si uso cookies inseguras?

Estudiante: porque el navegador no podrá enviar sus cookies a otro dominio.

Profesor: Así es, el navegador no enviará cookies a otro dominio, pero aún existe el peligro de que un atacante pueda descargar su URL. Entonces, supongamos que amazon.com usa solo SSL, ni siquiera escucha en el puerto 80. Como resultado, no configuran su bandera de seguridad en las cookies. Entonces, ¿cómo puede un hacker robar sus cookies si Amazon ni siquiera escucha en el puerto 80?

Estudiante: ¿el navegador aún puede pensar que se trata de una conexión HTTP?

Profesor: bueno, si se conecta al puerto 443 y usa SSL o TLS, entonces la conexión siempre estará encriptada, por lo que esto no es un problema.

Estudiante: Un atacante podría interceptar la conexión.

Profesor: sí, un atacante puede interceptar sus paquetes que intentan conectarse a Amazon a través del puerto 80, y pretender que se conectó con éxito al sitio. Entonces, si un atacante tiene control sobre su red, puede redirigir sus paquetes dirigidos a Amazon al puerto 80 de su propia máquina, y el cliente no podrá ver la diferencia. Se verá como si Amazon estuviera escuchando en el puerto 80, pero en realidad sus cookies se enviarán al servidor web de este hacker.

Estudiante: porque el cliente es desconocido.

Profesor: Así es, ya que HTTP no tiene forma de verificar la autenticidad del host al que está conectado. Esto es exactamente lo que está sucediendo. HTTP no tiene autenticación. Por lo tanto, si asume que hay un adversario de la red, primero debe evitar que sus cookies se envíen a través de HTTP, porque no tiene idea de a quién irá esta conexión HTTP.

Estudiante: para esto necesitas controlar la red.

Profesor: sí, por supuesto. Si tienes control total sobre tu red, entonces sabes que los oponentes no podrán interceptar tus paquetes. Sin embargo, incluso con el control total sobre la red, es posible que tenga problemas, mire los materiales para la conferencia sobre TCP, allí se consideraron varios tipos de ataques de red.

Audiencia: ¿ Pero no es posible en este caso evitar un ataque de redireccionamiento?

Profesor: es probable que el hacker intercepte la solicitud http del cliente en amazon.com , y esta solicitud incluirá todas sus cookies para amazon.com, o cookies para cualquier otro dominio al que envíe la solicitud. Por lo tanto, si no marca estas cookies como seguras, se pueden enviar a través de una conexión cifrada y no cifrada.

Estudiante: ¿cómo se inicia esta solicitud?

Profesor: tal vez pueda hacer que el usuario visite newyorktimes.com, donde pagó por un anuncio cargando una imagen de amazon.com . Y no hay nada que proteja al usuario de preguntar: "descargue la imagen de esta URL". Pero cuando el navegador intenta conectarse al sitio, enviará cookies si la conexión fue exitosa.

Existe una extensión HTTPS Everywhere, que es muy similar a Force HTTPS o HTTPS forzado, y que intenta evitar este tipo de error. Cuando selecciona un sitio en modo HTTPS forzado, el navegador evitará principalmente cualquier conexión HTTP a este host.



Por lo tanto, no hay forma de no marcar sus cookies como seguras o cometer un error similar. Si el desarrollador olvidó establecer una marca de seguridad en las cookies, en este caso la solución es obvia: solo tiene que corregir su error. Pero hay un problema más delicado: cuando un servidor web seguro recibe la cookie del cliente, no tiene idea de si esta cookie se envió a través de una conexión cifrada o de texto sin formato. Porque, de hecho, el servidor recibe solo un par de valores clave para la cookie.

Del plan de acción discutido anteriormente, se deduce que al enviar una solicitud a un servidor seguro, el navegador incluirá cookies seguras e inseguras, porque por su parte, le preocupa su confidencialidad. Pero en el lado del servidor no hay garantías de confidencialidad, y cuando el servidor recibe cookies de usuario, se pueden enviar a través de una conexión cifrada y de texto. Esto lleva a la posibilidad de ataques como la fijación de la sesión.

Esto significa que un atacante, por ejemplo, quiere ver qué correos electrónicos envía. Para hacer esto, él establecerá sus propias cookies, que son una copia de las cookies de su cuenta de Gmail. Y cuando envíe su carta, aparecerá en su carpeta Elementos enviados y no en su carpeta. Será como si estuvieras usando una cuenta de atacante, para que él pueda extraer tu correspondencia de su buzón. Entonces, si un pirata informático pone a la fuerza cookies de sesión en su navegador, entonces lo obligará a usar su cuenta. Entonces, este es otro problema que surge debido a malentendidos con la separación incompleta de las cookies HTTP y HTTPS.

Estudiante: pero para insertar sus cookies en el navegador de otra persona, debe tener una vulnerabilidad allí.

Profesor: no, para configurar su cookie, la vulnerabilidad no es necesaria. Simplemente está engañando al navegador para que se conecte a la URL del host HTTP normal. Y si el navegador no tiene una extensión, como Force HTTPS o HTTPS Everywhere, usted, como atacante, podría establecer la clave en el navegador del usuario. Esta es una cookie insegura, pero se enviará de vuelta, incluso para solicitudes seguras.

Estudiante: ¿cómo puede hacer que el navegador piense que este dominio es el mismo dominio?
Profesor: para esto debe interceptar la conexión de red y llevar a cabo uno de los tipos de ataques de los que hablamos hace unos minutos.

Entonces, ¿qué hace realmente HTTPS forzado? Él está tratando de prevenir algunos de los muchos problemas. Los estudios sobre el protocolo Force HTTPS se publicaron hace 5 o 6 años. Desde entonces, ha sido estandarizado y realmente adoptado. Parece un complemento incompleto que almacena algunas cosas y algunas cookies. Hoy, la mayoría de los desarrolladores de navegadores creen que crearlo fue una buena idea. Lo mejor es integrarlo directamente en el navegador. Hay algo llamado HTTP Strict Transport Security, o HSTS, un mecanismo para forzar una conexión segura a través del protocolo HTTPS. Este es un buen ejemplo de cómo la investigación científica afecta la seguridad de las aplicaciones web y los navegadores.

Veamos qué hace Force HTTPS para un sitio web. HTTPS forzado permite que un sitio web establezca este bit para un nombre de host específico, y hay tres cosas que obligan a HTTPS a afectar el comportamiento del navegador.

El primero es que cualquier error de certificado siempre es fatal. Por lo tanto, el usuario no tiene la posibilidad de aceptar el certificado incorrecto con el nombre de host incorrecto o caducado, y así sucesivamente. Esta es una cosa que cambia el navegador.

Lo segundo es que Force HTTPS redirige todas las solicitudes HTTP a HTTPS. Esta es una muy buena idea. Si sabe que el sitio siempre usa HTTPS legítimamente, entonces probablemente debería prohibir cualquier solicitud HTTP regular, ya que esto puede ser un signo de algún tipo de error o evidencia de que un atacante está tratando de engañarlo para que le ofrezca conectarse al sitio sin cifrado . Desea asegurarse de que esto realmente suceda antes de que se ejecute la solicitud HTTP; de lo contrario, cualquier solicitud HTTP ya iría a la red.

Y lo último que Force Force HTTPS obliga al navegador a hacer es que prohíbe el plan inseguro de incrustación que vimos anteriormente, cuando incrusta una URL HTTP en un sitio HTTPS.



Entonces, esto es lo que hace la extensión Force HTTPS. Basado en la terminología utilizada hoy, el protocolo HSTS hace lo mismo. Ahora, por defecto, la mayoría de los navegadores prohíben la incrustación insegura. Esto fue controvertido, ya que muchos desarrolladores tuvieron problemas debido a Force HTTPS, pero creo que Firefox, Chrome e IE por defecto se negarán a cargar componentes inseguros, o al menos JavaScript y CSS inseguros en su página si entonces hazlo mal.

Estudiante: ¿no le preguntan al usuario sobre el desempeño de ninguna acción?

Profesor: están acostumbrados al hecho de que generalmente el usuario está de acuerdo. Por ejemplo, IE utiliza un cuadro de diálogo emergente que le pregunta si desea descargar contenido adicional o algo así. Creo que si lo intentas, puedes eludir todas estas medidas de seguridad, pero no te aconsejo que lo hagas. Por lo tanto, los navegadores modernos intentan resolver algunos de los problemas utilizando Force HTTPS y HSTS.

Estudiante: ¿qué sucede cuando un sitio no admite HTTPS?

Profesor: ¿qué quieres decir?

Estudiante: que el navegador no se conectará al sitio a través de HTTPS.

Profesor: ¿qué sucede si tiene un sitio web que no admite HTTPS pero establece estas cookies? El hecho es que si usa esta opción en su navegador, no podrá hablar con la mayor parte de Internet, porque no usan HTTPS. Por lo tanto, el navegador debe poder comunicarse a través de HTTPS con aquellos sitios que realmente desean dicha protección.

Estudiante: si no recuerdo mal, no puede configurar una cookie hasta que el sitio lo permita.

Profesor: sí, eso es verdad. Estos chicos están preocupados por los ataques DoS, en los que este complemento se puede usar para causar problemas a otros sitios. Por ejemplo, si configura el bit Force HTTPS para algunos sitios web desprevenidos, de repente dejarían de funcionar, porque ahora todos intentarían conectarse a ellos a través de HTTPS, que no son compatibles. Por lo tanto, este es un ejemplo que le preocupa la posibilidad de usar un ataque DoS al usar HTTPS forzado para sitios que no cuentan con esto.

Otra cosa es que este protocolo no admite el uso de Force HTTPS para todo el dominio. Por ejemplo, soy un usuario mit.edu que ha configurado las cookies Force HTTPS en todos los navegadores, y ahora solo las conexiones HTTPS funcionan en MIT. Esto parece un poco catastrófico, por lo que probablemente desee evitar una situación similar.

Por otro lado, el protocolo HSTS volvió a esto, diciendo que puede configurar Force HTTPS para todo el subdominio, porque resulta útil para las cookies inseguras enviadas junto con la solicitud si no sabe de dónde se enviaron originalmente. Hay un montón de configuraciones para estas cosas en el nivel más bajo, pero aún no está claro qué significa la elección correcta en este caso.

Hay una pregunta interesante que podría hacer: ¿son fundamentales estas mejoras o están destinadas únicamente a ayudar a los desarrolladores a evitar errores? Suponga que tiene un desarrollador muy responsable que no toma medidas peligrosas, actualiza los certificados a tiempo, redacta nuevos, ¿necesita usar Force HTTPS?

Estudiante: por supuesto, porque nada detendrá al pirata informático que obligará al usuario a descargar algo a través de HTTP y luego interceptará la conexión.

Profesor: es verdad. Pero si siente que es muy diligente y todas sus cookies están marcadas como seguras, entonces si alguien visita la versión HTTP de su sitio, esto no debería causar problemas.



Sin embargo, probablemente todavía tenga que defenderse contra la sobrescritura de cookies o ataques de inyección. Esto es agotador, pero probablemente pueda hacer algo al respecto.

Estudiante: Creo que el desarrollador en cualquier caso no podrá verificar la autenticidad del certificado, ¿verdad?

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

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

, Google , , , , , Google . , Chrome , URL- Force HTTPS.


.

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?