¿Hay alguna razón para no aplicar HTTPS en un sitio web?

Un sitio web que frecuenta finalmente ha decidido habilitar TLS en sus servidores, solo para no obligarlo como lo hacen muchos sitios web. El mantenedor afirma que TLS debe ser opcional. ¿Por qué?

En mi propio sitio web, he configurado TLS y HSTS obligatorios con largos períodos, y los conjuntos de cifrado más débiles están deshabilitados. El acceso a texto sin formato se garantiza con un HTTP 301 a la versión protegida por TLS. ¿Esto afecta negativamente a mi sitio web?

Hay varias buenas razones para usar TLS

(y solo algunas razones marginales para no hacerlo).

• Si el sitio tiene alguna autenticación, utilice la exposición HTTP para robar sesiones y contraseñas.

• Incluso en sitios estáticos, meramente informativos, el uso de TLS garantiza que nadie haya alterado los datos.

• Desde Google I / O 2014 , Google ha tomado varias medidas para alentar a todos los sitios a usar HTTPS:

  • Google ha estado ayudando a los webmasters a configurar sus servidores de manera más segura, pero también ha utilizado HTTPS como señal de clasificación .
  • Más recientemente, Google Chrome comenzó a marcar sitios HTTP como no seguros , como parte de un plan a largo plazo para marcar todos los sitios HTTP como no seguros .
  • La conferencia HTTPS Mythbusting del equipo de desarrolladores de Google Chrome establece claramente su actitud.

• El blog de seguridad de Mozilla también ha anunciado que desaprobará HTTP no seguro al hacer que todas las funciones nuevas estén disponibles solo para sitios web seguros y que elimine gradualmente el acceso a las funciones del navegador para sitios web no seguros, especialmente características que representan riesgos para la seguridad y privacidad de los usuarios .

También hay varias buenas razones para hacer cumplir TLS

Si ya tiene un certificado ampliamente confiable, ¿por qué no lo usa siempre? Prácticamente todos los navegadores actuales son compatibles con TLS y tienen certificados raíz instalados. El único problema de compatibilidad que he visto en años han sido los dispositivos Android y la falta de autoridad de certificación intermedia, ya que Android solo confía directamente en las CA raíz. Esto se puede evitar fácilmente configurando el servidor para que envíe la cadena de certificados a la CA raíz.

Si su responsable de mantenimiento aún desea permitir conexiones HTTP sin conexión directa 301 Moved Permanently, por ejemplo, para garantizar el acceso desde algunos navegadores o dispositivos móviles realmente antiguos, no hay forma de que el navegador sepa que incluso tiene configurado HTTPS . Además, no debe implementar HTTP Strict Transport Security (HSTS) sin 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

El Proyecto Tor y la Electronic Frontier Foundation reconocen el problema de varios sitios configurados para ambos protocolos y lo aborda una extensión HTTPS Everywhere de varios navegadores :

Muchos sitios en la web ofrecen un soporte limitado para el cifrado a través de HTTPS, pero dificultan su uso. Por ejemplo, pueden usar de manera predeterminada HTTP sin encriptar, o llenar páginas encriptadas con enlaces que regresan al sitio sin encriptar.

El contenido mixto también fue un gran problema debido a los posibles ataques XSS a sitios HTTPS mediante la modificación de JavaScript o CSS cargado a través de una conexión HTTP no segura. Por lo tanto, hoy en día todos los navegadores convencionales advierten a los usuarios sobre páginas con contenido mixto y se niega a cargarlo automáticamente. Esto hace que sea difícil mantener un sitio sin los 301redireccionamientos en HTTP: debe asegurarse de que cada página HTTP solo cargue contenido HTTP (CSS, JS, imágenes, etc.) y cada página HTTPS solo cargue contenido HTTPS. Eso es extremadamente difícil de lograr con el mismo contenido en ambos.

En la actualidad, TLS + HSTS son marcadores de que su sitio es administrado por profesionales en los que se puede confiar para saber lo que están haciendo. Ese es un estándar mínimo emergente para la confiabilidad, como lo demuestra Google al afirmar que proporcionarán una clasificación positiva para los sitios que lo hacen.

En el otro extremo está la máxima compatibilidad. Todavía hay clientes más antiguos, especialmente en partes del mundo que no son Estados Unidos, Europa o China. HTTP simple siempre funcionará (aunque no siempre funciona bien ; esa es otra historia).

TLS + HSTS: Optimizar para la clasificación del motor de búsqueda
HTTP simple: Optimizar para compatibilidad

Depende de lo que más te importe.

Hay una buena razón para que los sitios web de solo lectura no utilicen HTTPS.

• Los cachés web no pueden almacenar en caché las imágenes que se transportan a través de HTTPS.
• Algunas partes del mundo tienen conexiones internacionales de muy baja velocidad, por lo que dependen de los cachés.
• Alojar imágenes de otro dominio requiere habilidades que no puede esperar que tengan los operadores de sitios web pequeños de solo lectura .

El mantenedor afirma que TLS debe ser opcional. ¿Por qué?

Para saber realmente la respuesta a esta pregunta, debe preguntarles. Sin embargo, podemos hacer algunas conjeturas.

En entornos corporativos, es común que TI instale un firewall que inspeccione el tráfico entrante y saliente en busca de malware, actividad sospechosa similar a CnC, contenido considerado inapropiado para el trabajo (por ejemplo, pornografía), etc. Esto se vuelve mucho más difícil cuando el tráfico está encriptado. Hay esencialmente tres respuestas posibles:

1. Renunciar a la supervisión de este tráfico.
2. Instale una CA raíz en las máquinas de los usuarios para que pueda realizar el descifrado e inspección de MitM.
3. Venta al por mayor bloque de tráfico encriptado.

Para un administrador de sistemas preocupado, ninguna de estas opciones es particularmente atractiva. Existen muchas amenazas que atacan una red corporativa, y es su trabajo proteger a la compañía contra ellas. Sin embargo, el bloqueo de una gran cantidad de sitios aumenta completamente la ira de los usuarios, y la instalación de una CA raíz puede parecer un poco descuidada, ya que introduce consideraciones de privacidad y seguridad para los usuarios. Recuerdo haber visto (lo siento, no puedo encontrar el hilo) una petición de administrador de sistemas reddit cuando encendieron HSTS por primera vez porque estaba exactamente en esta situación, y no quería bloquear todo reddit simplemente porque el negocio lo obligó para bloquear los subreddits centrados en la pornografía.

Las ruedas de la tecnología siguen avanzando, y encontrarás a muchos que argumentan que este tipo de protección está pasado de moda y debería eliminarse gradualmente. Pero todavía hay muchos que lo practican, y tal vez sean ellos a quienes concierne su misterioso mantenedor.

Todo se reduce a sus requisitos de seguridad, elección del usuario y riesgo de degradación implícita. Desactivar los cifrados antiguos del lado del servidor es en gran medida necesario porque los navegadores se convertirán felizmente en cifrados absolutamente horribles del lado del cliente en nombre de la experiencia / conveniencia del usuario. Asegurarse de que nada de los suyos que dependa de un canal seguro para el usuario no pueda ser alcanzado con un método inseguro es, por supuesto, también muy sólido.

No me permite degradar explícitamente a HTTP inseguro cuando he considerado que tu publicación de blog sobre por qué te gusta Python más que a Ruby (no digo que te guste, solo un ejemplo genérico) no es algo que los espías o el público sepan Accedí porque se interpone en mi camino sin ninguna buena razón, suponiendo que HTTPS será trivial para mí.

Hoy en día, hay sistemas integrados que no tienen la capacidad de usar TLS fuera de la caja, o los que están atascados en implementaciones antiguas (creo que es muy malo que esto sea así, pero como un usuario avanzado de [insertar incrustados dispositivo aquí], a veces no puedo cambiar esto).

Aquí hay un experimento divertido: intente descargar una versión reciente de LibreSSL desde el sitio de OpenBSD ascendente a través de HTTPS con una implementación TLS / SSL suficientemente antigua. No podrás hacerlo. Intenté el otro día en un dispositivo con una versión anterior de OpenSSL de 2012 más o menos, porque quería actualizar este sistema embebido a una fuente más segura y nueva desde el origen: no tengo el lujo de un paquete preconstruido. Los mensajes de error cuando lo intenté no fueron exactamente intuitivos, pero supongo que fue porque mi OpenSSL anterior no era compatible con las cosas correctas.

Este es un ejemplo en el que el único HTTPS puede perjudicar a las personas: si no tiene el lujo de los paquetes prefabricados recientes y desea solucionar el problema usted mismo construyendo desde la fuente, está bloqueado. Afortunadamente, en el caso de LibreSSL, puede recurrir a la solicitud explícita de HTTP. Claro, esto no lo salvará de un atacante que ya está reescribiendo su tráfico, capaz de reemplazar los paquetes fuente con versiones comprometidas y reescribir todas las sumas de verificación en los cuerpos HTTP que describen los paquetes disponibles para descargar en las páginas web que navega, pero aún es útil en gran medida caso mas comun.

La mayoría de nosotros no estamos a una descarga no segura de ser propiedad de un APT (Advanced Persistent Thread: jerga de seguridad para las agencias de inteligencia nacionales y otras amenazas cibernéticas extremadamente bien financiadas). A veces solo quiero un wgetpoco de documentación de texto sin formato o un pequeño programa cuya fuente puedo auditar rápidamente (mis propias pequeñas utilidades / scripts en GitHub, por ejemplo) en una caja que no admite los conjuntos de cifrado más recientes.

Personalmente, preguntaría esto: ¿su contenido es tal que una persona pueda decidir legítimamente "Estoy de acuerdo con que yo sea de conocimiento público"? ¿Existe una posibilidad plausible de riesgo real para las personas no técnicas que degradan accidentalmente a HTTP su contenido? Considere sus requisitos de seguridad, los requisitos de privacidad forzada para sus usuarios y el riesgo de rebajas implícitas frente a la capacidad de los usuarios que entienden los riesgos de tomar una decisión informada caso por caso para no estar seguros. Es completamente legítimo decir que para su sitio, no hay una buena razón para no aplicar HTTPS, pero creo que es justo decir que todavía hay buenos casos de uso para HTTP simple.

Aquí hay mucha discusión sobre por qué tls es bueno, pero eso nunca se preguntó como en la publicación original.

Maxthon hizo 2 preguntas:

1) ¿por qué tiene un sitio aleatorio y sin nombre decidido mantener las presencias http y https?

2) ¿Hay un impacto negativo en que Maxthon sirva solo 301 respuestas a solicitudes http?

Con respecto a la primera pregunta, no sabemos por qué los proveedores optaron por retener los sitios http y https. Puede haber muchas razones. Además de los puntos sobre compatibilidad, almacenamiento en caché distribuido y algunos consejos sobre accesibilidad geopolítica, también se tiene en cuenta la integración de contenido y evitar mensajes feos del navegador sobre el contenido inseguro. Como Alvaro señaló, TLS es solo la punta del iceberg con respecto a la seguridad.

La segunda pregunta, sin embargo, es responsable. Exponer cualquier parte de su sitio web a través de http cuando realmente requiere https para una operación segura proporciona un vector explotable para los ataques. Sin embargo, tiene sentido mantener esto para identificar dónde se dirige incorrectamente el tráfico al puerto 80 en su sitio y solucionar la causa. Es decir, hay un impacto negativo y la oportunidad de un impacto positivo, el resultado neto depende de si está haciendo su trabajo como administrador.

Sysadmin1138 dice que https impacta en las clasificaciones de SEO. Si bien Google ha declarado que sí afecta las clasificaciones, los únicos estudios confiables que he visto sugieren que la diferencia es pequeña. Esto no es ayudado por personas que deberían saber mejor alegando que, dado que los sitios mejor clasificados tienen más probabilidades de tener una presencia https, una presencia https por lo tanto mejora la clasificación.

En el pasado, tuve que usar HTTP en lugar de HTTPS porque quería <embed>páginas de otros lugares que se hayan servido a través de HTTP, y de lo contrario no funcionarán.

Esta no es una buena razón, ya que significa que tiene clientes malos / rotos / inseguros, pero si hay procesos automatizados que acceden a los recursos a través de las http://URL existentes , es posible que algunos de ellos ni siquiera admitan https (por ejemplo, busybox wget, que no no tiene soporte TLS internamente y solo lo agregó más recientemente a través de un proceso hijo de openssl) y se rompería si se les diera una redirección a una URL https que no pueden seguir.

Me sentiría tentado a lidiar con esta posibilidad escribiendo la regla de redireccionamiento para excluir las cadenas de agente de usuario desconocidas (o heredadas conocidas) de ser redirigidas y permitirles acceder al contenido a través de http si lo desean, para que todos los navegadores reales puedan beneficiarse de https / hsts forzados.

Hay muy pocas buenas razones para usar HTTP en lugar de HTTPS en un sitio web. Si su sitio web maneja transacciones de cualquier tipo o almacena cualquier tipo de información confidencial o personal, debe usar absolutamente HTTPS si desea que dichos datos estén seguros. La única razón decente que vería por no aplicar HTTPS es si su sitio web depende del almacenamiento en caché, ya que HTTPS no funciona con el almacenamiento en caché. Sin embargo, a menudo vale la pena sacrificar un poco de rendimiento para garantizar la seguridad de su sitio web. También es posible que sus clientes no admitan HTTPS, pero realmente, en 2017, deberían hacerlo.