HTTPS en EOL

Desde aproximadamente las 13:00h del 25 de enero ya está el HTTPS funcionando obligatoriamente para todo el mundo.

Cosas pendientes:
  • Alertas de "contenido mixto". Algunas están pendientes de solucionar por los proveedores de los banners. En cuanto a las imágenes insertadas por los usuarios, tendremos que estudiarlo (por ejemplo imgur es fácil reescribir porque sirven por HTTPS) pero la mayoría probablemente quede como está: no tenemos los recursos para utilizar algo como camo estamos empezando a reescribir algunas URLs. Más info aquí.
  • HSTS. A la espera de probar todo un poco más.
  • Cookies con flag 'secure'. Primero me gustaría capar algo más el acceso por HTTP usando HSTS.
  • Keep-Alive en Apache para evitar la renegociación SSL en cada petición. Pendiente de estudiar.
  • OCSP stapling para mejorar el rendimiento y la privacidad. Pendiente de actualización de software.
  • HTTP/2. pendiente de actualización de software.
Interesante...

Ahora mismo no será la prioridad, pero entro para avisar que la previsualización de las wikis no funciona bajo https.
He probado en Edge 38 y Chrome 55.
Para acceder a https://elotrolado.net desde el navegador de la New 3DS (version 1.8.10156) me dio 2 avisos de sitio con poca seguridad y al aceptar 2 veces me entró sin problemas, no hice captura. mea culpa [snif]
largeroliker escribió:Ahora mismo no será la prioridad, pero entro para avisar que la previsualización de las wikis no funciona bajo https

Sí, eso es por el tema de "contenido mixto". De momento buscamos errores que impidan acceder a la web.

Liquid Snake yo escribió:Para acceder a https://elotrolado.net desde el navegador de la New 3DS (version 1.8.10156) me dio 2 avisos de sitio con poca seguridad

¿Una vez aceptas el aviso, vuelve a salir de cada vez? ¿O solo una vez por sesión? ¿Hay alguna casilla para añadir una excepción para que no vuelva a avisar?
melado escribió:
Liquid Snake yo escribió:Para acceder a https://elotrolado.net desde el navegador de la New 3DS (version 1.8.10156) me dio 2 avisos de sitio con poca seguridad

¿Una vez aceptas el aviso, vuelve a salir de cada vez? ¿O solo una vez por sesión? ¿Hay alguna casilla para añadir una excepción para que no vuelva a avisar?


Pues me salió dos veces, en plan aceptar/rechazar sin casilla para añadir exepción, no me ha vuelto a salir, he probado a borrar la caché para ver si salia de nuevo y hacer la captura y nada. No mas mensajes

Edito: en el navegador de New 3DS, navegando por el foro con https, no cargan los avatares de los usuarios, se ve un rectangulo aplastado en su lugar asi:

Imagen
Navegador apus para Android y no he visto fallos
largeroliker escribió:Interesante...

Ahora mismo no será la prioridad, pero entro para avisar que la previsualización de las wikis no funciona bajo https.
He probado en Edge 38 y Chrome 55.

Con Firefox 50 tampoco.

Para mas feedback, he probado con navegadores raros, qutebrowser (0.9.0) y Konqueror (16.12), ambos entran perfectamente sin errores con https. El tema de las wikis con qutebrowser si que funciona, con Chromium 55 no.
melado escribió:
  • Alertas de "contenido mixto". El contenido que está bajo *.elotrolado.net lo iremos corrigiendo, pero primero queremos comprobar la compatibilidad. En cuanto al contenido que está fuera, tendremos que estudiarlo (por ejemplo imgur es fácil reescribir porque sirven por HTTPS) pero la mayoría que quedará como está: no tenemos los recursos para utilizar algo como camo.
    • NO REPORTÉIS ESTE TIPO DE ALERTAS COMO FALLO. SI LA WEB CARGA, NO ES UN FALLO (aún).



Eso lo has esgrimido muchas veces como el mayor, o casi mayor, impedimento para montar la web sobre SSL/TLS.

De verdad (leerlo con pausas): NO TE COMAS EL TARRO.

A ver, la gente tiene que pensar un poco (ya sé lo que me vas a decir, pero bueno).

Sólo veo un obvio efecto colateral y es una posible penalización de Google por ello, pero, de verdad, que le den a Google. Poco a poco la web (la parte más conocida) está haciendo la transición hacia TLS y se verá cada vez menos el error de contenido mixto mientras se implemente poco a poco la automatización HSTS.

Yo es que el proxy..., no lo veo. No lo veo a este nivel.

Quiero decir, no lo hiciste con la sugerencia que te daba de comprobar el tamaño de las imágenes (a la hora de publicar, no cada vez que se carga una página) comprobando las cabeceras HTTP, ¿y vas a montarte un proxy para TODO el contenido?.

Si en su momento querías salvar tráfico, veo ridículo montar un proxy por salvar el culo al usuario, desde el punto de vista de "jo, es que me dice el navegador que la web no es segura" :-|

No se puede tener todo.

Yo me conformo, de momento, con que cambias las urls a "//" y ya. Mientras tanto, habilitaré contenido mixto aquí.

Por cierto, técnicamente, tú no necesitas hacer una reescritura de URL de imgur. Yo llevo viendo las imágenes de imgur sobre TLS desde hace tiempo porque tengo forzada la carga con TLS. Sé que es pedir mucho al usuario común, pero para librarse de estos problemas, aunque no es santo de mi devoción (yo lo hago a mano), diría a la gente que se instalase la mastodóntica extensión de "HTTPS everywhere". (Y luego vendrán otros lloros que recuerdo que se abrió un hilo al respecto, pero, lo dicho, no se puede tener todo.)
A mi se me ve este espacio entre el primer post y el segundo:

Imagen

Ademas me sale una advertencia de si debo cargar o no contenido no seguro

Windows 10
IE 11.0.34
@JohnH es que precisamente estoy diciendo que no vamos a usar camo. Lo de "estudiarlo" como mucho se reducirá a tener una lista de una docena de alojamientos de imágenes habituales que admitan HTTPS y hacer una reescritura al vuelo de las URLs utilizando el sistema de censura de palabras del foro, que es algo relativamente sencillo y que vale la pena. No mucho más, porque como tú dices no es nuestro problema :P

A los demás, insisto: de momento solo me interesan reportes la imposibilidad de cargar la web, como el que ha puesto Liquid Snake Yo. El resto es conocido y esperado.
@melado perdón por la meada fuera de tiesto. Reportemos pues.


Es que no me pasa en otras web, y supongo que es por la cabecera cache-control, pero el caso es que sin TLS no da este problema y se envía también la cabecera y en navegadores Gecko se cachea el contenido TLS desde hace... no sé cuantas versiones, y como mínimo, en la memoria. Bueno, da igual porque me pasa en diferentes versiones, tanto en K-meleon como Firefox.

A ver si alguno puede confirmar que, visitando la lista de hilos de un foro, pongamos este de políticas (u os váis al que tengáis sin leer):

https://www.elotrolado.net/foro_feedbac ... -de-eol_10

Si visitamos un hilo (si tiene varias páginas, la última página) y luego volvemos atrás (flecha atrás del navegador, del menú contextual, CRL + ⭠ (o como tengáis la combinación de teclas)), en vez de volver a la lista de hilos cacheada, bien sea en disco, bien sea en memoria, lo que hace es recargar la lista de hilos del foro, por lo que el hilo al que hemos accedido se marca como leído.

A ver, esto, en verdad, puede parecer una tontería y se podría incluso agradecer, pero, hay dos peros, y es que esto genera tráfico, tráfico que antes no se generaba sin TLS; y ralentiza la carga de la lista de hilos porque no la saca de la cache sino que la vuelve a cargar otra vez, así que cada vez que le das para atrás, pues se pierde el tiempo. A no ser que trabajes Off-line, cuando vayas a ir atrás en el navegador. Y es importante, porque no sé si pasará en la versión móvil, pero esto consumirá el doble de datos si se hace mucho uso del ir atrás.

Y el parámetro private de la cabecera no es, porque lo acabo de probar en otras páginas. Será no-cache="set-cookie".

No creo que tenga que ver con lo que mencionas de Keep-alive. Es que no me pasa en otros foros :-S Debería tirar de caché sí o sí.

Raro, raro.
Es un bug de Firefox pero se solucionó en la versión 47, o al menos así lo anuncian sus release notes.

¿Qué versión tienes tú?
melado escribió:Es un bug de Firefox pero se solucionó en la versión 47, o al menos así lo anuncian sus release notes.

¿Qué versión tienes tú?


[facepalm] ¡vaya por dios!

Pues una versión inferior, tanto en uno como en otro, y sin posibilidad práctica* de actualizar, así que..., pues nada.

:-|

* deseable, más que práctica
He actualizado el primer post con la siguiente información:

melado escribió:Desde aproximadamente las 13:00h del 25 de enero ya está el HTTPS funcionando obligatoriamente para todo el mundo.

Cosas pendientes:
  • Alertas de "contenido mixto". Algunas están pendientes de solucionar por los proveedores de los banners. En cuanto a las imágenes insertadas por los usuarios, tendremos que estudiarlo (por ejemplo imgur es fácil reescribir porque sirven por HTTPS) pero la mayoría probablemente quede como está: no tenemos los recursos para utilizar algo como camo.
  • HSTS. A la espera de probar todo un poco más.
  • Cookies con flag 'secure'. Primero me gustaría capar algo más el acceso por HTTP usando HSTS.
  • Keep-Alive en Apache para evitar la renegociación SSL en cada petición. Pendiente de estudiar.
  • OCSP stapling para mejorar el rendimiento y la privacidad. Pendiente de actualización de software.
  • HTTP/2. pendiente de actualización de software.
(mensaje borrado)
Algo has tenido que tocar porque me ha vuelto a saltar el aviso en el navegador de la New 3DS y esta vez he hecho fotos:

Imagen
Imagen
Imagen
Imagen
¿No quedamos en que te preguntaba una vez por sesión?
melado escribió:¿No quedamos en que te preguntaba una vez por sesión?


Y eso pensaba, pero ayer me saltó el aviso desde que lo reporté la primera vez
Porque ayer forzamos el HTTPS para todo el mundo, y probablemente desde que abrí el hilo hasta ayer tú habías estado entrando por HTTP normal. ¿Puede ser?
Es posible si, de todas formas despues de una doble comprobacion ya no vuelve a salir, si aparece otra vez ya te avisaré
No es nada que reportar en sí, pero estoy viendo varios ejemplos de contenido mixto bajo el paraguas del mismo dominio de eol. Es decir, se pueden arreglar y no veo razón para lo contrario.

En partícular los dominios download.elotrolado.net (avatares) e images.elotrolado.net (noticias).

El primero, en particular, ocurre en la página de los perfiles, que los avatares se sirven con URLs absolutas http://download......

El segundo caso es más de desidia. Los "editores" a veces publican las imágenes de las noticias como https://images.el...... y otras http://images.el.....

Este último en particular no te niego que me crea sorpresa, aunque como no conozco el mecanismo interno de publicación de imágenes en las noticias, mejor me callo.
En cuanto a las imágenes insertadas por los usuarios, tendremos que estudiarlo

Bueno en general, casi todos los hosts de imágenes tienen para https.

Un apaño sería "probar" si ese mismo link con https no devuelve error 404. En tal caso reescribirlo como https.

Por ejemplo, ejecutando wget desde algun script:
wget --spider -w 1 https://www.example.com 2>&1 > /dev/null | grep -i 404


Si la salida es vacía, entonces se encuentra disponible. Si la salida no es vacía, entonces no se encuentra disponible.

EDITO: Vale, también habría que comprobar en el grep si no hay ningún servidor https activo, pero la idea sigue siendo la misma.
Y un warning al usuario que postea con el servicio que no de https para ir educandolo?

Atencion, debido a blablabla intenta usar imgur capullo!

Eso + el filtro aunque no infalible ayudaria a que el contenido nuevo sea mas https y evitar contenido mixto

Y ahora se me ocurre, movemos el chequeo de machacon a js en lado cliente en la vista de posteo / accion submit para completar xD
Hay que tener una lista previa de reescrituras permitidas: una sustitución a ciegas como esa no funcionaría porque un servidor podría responder por HTTPS un error o un contenido distinto de por HTTP, o no estar disponible momentáneamente o tener nuestra IP bloqueada (nos pasa muchas veces con la comprobación del peso de las firmas).

Por eso estoy preparando una reescritura "al vuelo" (al visualizar, no al postear, porque tenemos ¿millones? de posts con imágenes ya publicados...) utilizando la completísima base de datos de HTTPS Everywhere :)

No confío en educar al usuario medio. Si se puede hacer de forma automática, transparente, sin molestar a nadie y de forma no destructiva, mucho mejor.
Para minimizar las alertas de contenido mixto, desde hace unos minutos he activado la reescritura de la URL a HTTPS de las imágenes insertadas de una serie de alojamientos externos, entre los que se incluyen:
  • imgur
  • photobucket
  • postimg
  • imageshack (hay alguna que falla porque tienen una redirección mal configurada, he probado a escribirles...)
  • twitter
  • wordpress
  • blogger/google
  • facebook
  • flickr
  • twitpic
  • tumblr
  • gyazo

De momento solo está activado en la vista de hilo, en la previsualización de los posts, y en los posts bajo el editor. Faltaría en las páginas de búsqueda y seguro que en algún sitio más.
Sé que soy mosca cojonera, pero te falta "lo más importante" (porque es propio de EOL) como que el avatar, al visitar el perfil de un usuario, no de alerta de contenido mixto.

Te añado otro hosting: deviantart.net

EDITO: Y porque no tenía a mano un elocuente ejemplo, pero ahí va el tema de las noticias que ya mencioné:
hilo_facebook-filtrara-las-noticias-falsas-en-francia-de-cara-a-las-elecciones-presidenciales_2215159
noticia_facebook-filtrara-las-noticias-falsas-en-francia-de-cara-a-las-elecciones-presidenciales_30800

Alejo es un hacha en cuanto a ponerlas con http:// día sí día no, hoy me apetece, hoy me equivoco.
Reescrito por HTTPS:
  • Todas las noticias con imágenes propias
  • Avatares y galería de GentEOL
  • Resultados de búsqueda
A mi el error de HTTP's que pone Liquid Snake yo , también me pasa en WiiU y sale cada dos por tres, a más de no cargar los avatares.
No hay mucho que hacer, Nintendo no actualiza los certificados de sus consolas desde hace siglos :(
28 respuestas