¿Por qué usar HTTPS en todas partes cuando tenemos navegadores compatibles con HSTS?

  

incluso si navegamos a un sitio web como www.facebook.com, el encabezado de respuesta de los servidores de Facebook mencionará HSTS

Hice una solicitud de curl a http://www.facebook.com y esto es lo que obtuve:

< HTTP/1.1 302 Found
< Location: https://www.facebook.com/
< Content-Type: text/html
< X-FB-Debug: zgK/A+8XSlghi/vWvAivsZ04gawpdr+3BuO7yuQaKDdrP/+B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A==
< Date: Sat, 29 Apr 2017 19:23:25 GMT
< Connection: keep-alive
< Content-Length: 0

Como puede ver, no hay un encabezado HSTS aquí, porque de acuerdo con su especificación (RFC6797) :

  

Un host HSTS NO DEBE incluir el campo de encabezado STS en las respuestas HTTP      transportado a través de transporte no seguro.

Los navegadores web también ignoran los encabezados HSTS en las respuestas http://

  

Nota: el navegador ignora el encabezado Strict-Transport-Security cuando se accede a su sitio mediante HTTP; esto se debe a que un atacante puede interceptar conexiones HTTP e inyectar el encabezado o eliminarlo. Cuando se accede a su sitio a través de HTTPS sin errores de certificado, el navegador sabe que su sitio es compatible con HTTPS y cumplirá con el encabezado de seguridad de transporte estricto.

El propósito de HSTS es decirle al cliente que NO cambie a HTTP una vez que haya accedido a un sitio web a través de HTTPS, y no al revés. De Wikipedia :

  

HTTP Strict Transport Security (HSTS) es un mecanismo de política de seguridad web que ayuda a proteger los sitios web contra ataques de degradación del protocolo y el secuestro de cookies.

Ataque de degradación de protocolo :

  

Un ataque de baja calificación es una forma de ataque a un sistema informático o protocolo de comunicaciones que hace que abandone un modo de operación de alta calidad (por ejemplo, una conexión encriptada) en favor de un modo de operación antiguo y de menor calidad (por ejemplo, claro). texto) que está ahí para la compatibilidad con sistemas anteriores.

Por lo tanto, un encabezado HSTS no se usa para redirigir una nueva conexión HTTP a HTTPS, sino para evitar que un navegador realice solicitudes HTTP a un sitio HTTPS existente.

El complemento HTTPS Everywhere por otro lado garantiza que el navegador web realice conexiones HTTPS a sitios web que admiten HTTPS, pero son también accesible a través de HTTP.

  

Muchos sitios en la web ofrecen un soporte limitado para el cifrado a través de HTTPS, pero hacen que sea difícil de usar. Por ejemplo, pueden omitir HTTP sin cifrar, o rellenar páginas cifradas con enlaces que regresan al sitio no cifrado. La extensión HTTPS Everywhere soluciona estos problemas mediante el uso de tecnología inteligente para reescribir las solicitudes de estos sitios a HTTPS.

HSTS utiliza un modelo de Trust on First Use . Si su primera conexión al sitio ya se vio comprometida, es posible que no reciba un error de HSTS en solicitudes posteriores.

El HTTPS Everywhere tapona este agujero, al permitir que su navegador sepa que el sitio es un sitio HTTPS único desde la primera conexión.

Además, algunos sitios web no anuncian un encabezado HSTS incluso cuando admiten HTTPS. O pueden tener su HTTPS en un dominio / ruta diferente (por ejemplo, http://www.example.com pero https://secure.example.com ), HTTPS Everywhere intenta ayudar con estas situaciones reescribiendo las URL del sitio.

HTTPS Everywhere es del lado del cliente, y HSTS es del lado del servidor.

Entonces, la respuesta es que HTTPS Everywhere es defender en los casos en que el servidor no establece un encabezado HSTS.

HSTS queda a discreción del operador del sitio web. Deben decidir si los beneficios de seguridad de HTTPS obligatorios valen la carga adicional del servidor, bloquear a los usuarios que no pueden usar HTTPS y hacer que los servidores proxy de almacenamiento en caché sean ineficaces. El HTTPS obligatorio es un requisito previo para HSTS.

Muchos sitios ofrecen HTTPS opcionalmente, pero si el usuario final lo elige o no, normalmente lo elige el usuario final, sino la persona que proporciona un enlace o URL. HTTPS Everywhere permite a los usuarios usar HTTPS en dichos sitios, incluso cuando el enlace o la URL escrita se usa HTTP.

A medida que más sitios hagan que HTTPS sea obligatorio e introduzcan HSTS para reducir el riesgo de seguridad de los redireccionamientos de texto sin formato, habrá menos necesidad de "HTTPS en todas partes", pero hasta / a menos que todos los sitios que ofrecen HTTPS lo hagan, seguirá siendo un complemento útil.

La pregunta se basa en premisas falsas.

  

... si navegamos a un sitio web, digamos www.facebook.com, el encabezado de respuesta de los servidores de Facebook mencionará HSTS y nuestro navegador nos dirigiría de http:// a https:// ...

no es cierto *. Aunque el encabezado Strict-Transport-Security es un encabezado HTTP, la especificación HSTS requiere que los servidores lo incluyan solo en las respuestas que se envían a través de un canal cifrado, y requiere que los clientes lo ignoren si se envían a través de un canal no cifrado. De RFC 6797 :

  

Host de seguridad de transporte estricto de HTTP: es un host conforme que implementa los aspectos del servidor HTTP de         Política de HSTS. Esto significa que un Host HSTS devuelve el         Campo de encabezado de respuesta HTTP "Strict-Transport-Security" en su HTTP         Mensajes de respuesta enviados a través de transporte seguro.

     

...

     

Un host HTTP se declara a sí mismo un HSTS Host mediante la emisión a UAs un HSTS      Política, que está representada y transmitida a través del      Campo de encabezado de respuesta HTTP Strict-Transport-Security sobre seguro      transporte (por ejemplo, TLS).

     

...

     

Un host HSTS NO DEBE incluir el campo de encabezado STS en las respuestas HTTP      transportado a través de transporte no seguro.

     

...

     

Si se recibe una respuesta HTTP a través de un transporte inseguro, el UA         DEBE ignorar los campos de encabezado de STS actuales.

* Ok, estoy excluyendo la posibilidad de que tanto el servidor de Facebook como su navegador infrinjan las especificaciones de HSTS. Y es cierto que un servidor bien configurado con HSTS también se configurará para que no escuche en el puerto 80 o envíe un redireccionamiento permanente a una URL de HTTPS. Pero vea la sección 7.2 de la RFC sobre las limitaciones de eso.

Veo que ninguna de las respuestas ha tocado en la carga de HSTS todavía. Para resumir: las advertencias mencionadas en las respuestas existentes, como @ Lie Ryan 's:

  

HSTS utiliza un modelo de Trust on First Use . Si su primera conexión al sitio ya se vio comprometida, es posible que no reciba un error de HSTS en solicitudes posteriores.

     

(…)

     

Además, algunos sitios web no anuncian un encabezado HSTS incluso cuando admiten HTTPS.

no se aplica a los sitios web que están precargados ; es decir, están en una lista que está integrada en el navegador web. Los sitios en esta lista, como con HTTPS Everywhere, siempre se reescribirán a HTTPS, incluso durante la primera visita.

Por este motivo, los mantenedores de HTTPS Everywhere han decidido que los sitios web de la lista de precarga no se agregarán a (y se puede eliminar de) la base de datos de URI de HTTPS Everywhere para volver a escribir.

Muchos dominios no tienen HSTS configurado correctamente. Por ejemplo, Google tiene HSTS en www.google.com y sus subdominios, pero no en google.com y sus subdominios. Por lo tanto, HSTS no se aplica en mail.google.com o drive.google.com como resultado de visitar enlace o enlace

La razón por la que Google tiene una configuración de este tipo es compleja. Los requisitos para ingresar a la lista de precarga de Chrome HSTS son que tiene HSTS para un dominio y sus subdominios. Supongo que Google tiene algunos servicios internos y quizás públicos que no funcionan a través de HTTPS. Así que HSTS para todos los subdominios de Google.com rompería esos servicios. HSTS para todos los dominios de www.google.com realmente solo cubre www.google.com, ya que no tiene subdominios en * .www.google.com.

Sin embargo, HTTPS Everywhere puede tener reglas que son mucho más complejas que HSTS que permiten estos casos de uso complejos.

Utilizo HTTPS Everywhere específicamente para el propio Stack Exchange. La última vez que lo comprobé (hace varios meses) no usaba HSTS y ni siquiera redirigía de HTTP a HTTPS. Sin embargo, proporcionó HTTPS, por lo que el complemento me salvó de posibles escuchas ilegales.

En cuanto a Stack Exchange, la situación puede haber cambiado ahora.