Hola,
a veces un foro muestra advertencias de contenido mixto. Mira esto en Letsencrypt:
Algunos favicons: http://alohadentalgroup.com/assets/icons/favicon.ico
Encontrado en https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
¿No es posible cambiar estos enlaces a https o ignorar estos enlaces http?
Un foro con contenido mixto es problemático.
Esa URL del favicon no está alojada en Discourse. ¿Estás usando Discourse? ¿Cuál es la URL de la instalación?
¿Tienes force_https activado?
Si es así, vuelve a subir tus iconos. Si no, actívalo y luego vuelve a subirlos.
No lo sé, no soy administrador del foro de Letsencrypt.
Pero si hay una opción local, lo preguntaré en el foro interno Regular.
PD: Gracias por moverlo.
La advertencia no es motivo de preocupación.
Uno de los usuarios del sitio de Let’s Encrypt agregó una URL en http en este tema: Issues running certbot command - Help - Let's Encrypt Community Support.
Por esta razón, el navegador advierte (correctamente) que hay contenido mixto.
Las advertencias de contenido mixto siempre son malas. Es posible agregar cookies mediante HTTP que se utilizan en la siguiente conexión HTTPS. Por lo tanto, el software del foro nunca debe iniciar conexiones HTTP.
Especialmente en un foro que habla sobre “Mi certificado es incorrecto” o “Tengo advertencias de contenido” (el certificado es correcto, pero hay contenido mixto: primer certificado con ese dominio, los enlaces deben actualizarse).
Ese favicon no está disponible a través de HTTPS. La advertencia de contenido mixto no es ideal, pero es preferible a la confusión del usuario sobre por qué sus enlaces no funcionan.
Lo sé. Pero es posible que un atacante de intermediario utilice esa conexión HTTP iniciada por el navegador para añadir una cookie mediante HTTP. Más tarde, la cookie se envía desde el navegador a través de HTTPS, y el atacante de intermediario conoce la cookie de sesión.
Esto funciona. El estado HTTP (404, 301, 410, 500) no es relevante.
Eso
no es un problema. El favicon no es un enlace iniciado por el usuario; el usuario solo añade el enlace HTTP al sitio, sin HTTPS.
Solución sencilla: No mostrar vista previa si el destino es HTTP. Así, no será necesario cargar el favicon.
No en una conexión de terceros. El navegador no está enviando sus cookies del sitio del foro a otro sitio, ya sea HTTP o HTTPS.
Estás creando un problema donde no existe. Por favor, demuestra una explotación de esto en try.discourse.org si realmente crees que es un problema.
Eso no es el problema. Eso sería un error del navegador.
Un atacante en el medio puede agregar una cookie en la conexión http://alohadentalgroup.com con el dominio alohadentalgroup.com, usando el nombre conocido de una cookie de sesión (si existe, no lo verifiqué) de ese dominio (no del dominio del foro).
Si un usuario, más tarde, utiliza el inicio de sesión de https://alohadentalgroup.com para gestionar ese dominio, esa cookie (creada vía HTTP) se enviará de vuelta vía HTTPS.
Esta es una característica crítica (y a menudo desconocida) de las cookies.
Esta es una de las razones por las que se crean los prefijos de cookies. Las cookies que comienzan con __Secure- o __Host- requieren HTTPS. De esa manera, esto ya no es posible. Lo mismo ocurre con Preload (aunque la mayoría de los sitios no usan HSTS y no están precargados).
Vea (2017)
u otros enlaces.
PD: Mi “verifica tu sitio web” (vea mi perfil) tiene una página con algunos ejemplos y una pequeña demostración: una cookie creada vía HTTP y enviada de vuelta vía HTTPS. A través de HTTP no es posible (con un navegador moderno) crear la cookie __Host-. Sin embargo, las cookies con prefijos son poco comunes.