Cita de: saintdave en Febrero 17, 2014, 12:17:29 PM
Se agradece tus buenas intenciones compañero, cuenta conmigo para el test.

Gracias, pronto publicaré el código fuente e instrucciones para que lo pruebe quien quiera.

Cita de: firecold en Febrero 18, 2014, 10:08:36 AM
Evidentemente como usted dice loquitoslack, igualmente en mi pais Guatemala, la pagina esta en https, pero los videos salen en http y logran ser cacheados sin problemas, el detalle esta y siempre lo he dicho que cuando uno se loguea en gmail, por proteccion se cifra todo y para ver en un texto las paginas de youtube recomendaria el siguiente comando:

Código (bash) [Seleccionar] Expandir

sudo cat /var/log/squid3/access.log | grep googlevideo.com >> /home/log.log

Creando un archivo en tu home con la imformacion requerida para posterior analisis, Saludos

En España era así como dices hasta hace bien poco.
Ahora mismo... si entras por HTTPS a youtube (sin estar logueado) el video de googlevideo.com sale por HTTPS también (hace unas semanas no era así). Pero de momento no es obligado entrar por HTTPS, si entras por HTTP no cambia a HTTPS y el vídeo de googlevideo.com también sale por HTTP. Comprobado personalmente por mí, sniffeando la conexión con tcpdump.

Imagino que será progresivo el cambio, de unos servidores de youtube a otros. Así que mejor estar preparado para cuando ya no haya opción de utilizar la versión en HTTP.

Recordad que hace años ni siquiera había versión HTTPS de Twitter, y ahora es obligado su uso (y como punto intermedio, hace años, fue opcional). Así que la tendencia de esas grandes webs de EEUU (que se llevan el grueso del tráfico en cualquier ISP) es utilizar HTTPS cada vez más (quizá por la influencia de las revelaciones sobre espionaje de la NSA de Edward Snowden, contraespionaje de Alemania, etc).

Yo pienso que lo mejor es que sea siempre el usuario quien tenga la última opción de elegir si HTTP o HTTPS, y que no que se imponga esa opción desde EEUU ni desde el ISP. Por ejemplo, desde un hotspot público es preferible utilizar HTTPS, si el tráfico de la red wifi va sin cifrado. Pero desde casa en general es preferible HTTP si el ISP tiene un proxy caché para aumentar la velocidad de carga. Y por suerte, hacer esto siempre será técnicamente posible, cuestión de software del proxy, por mucho que traten de impedirlo desde esas grandes webs :D.

Si quieres bloquear dominios puedes editar el archivo /etc/hosts de donde tengas instalado el proxy.
Y si quieres bloquear direcciones IP que accedan por HTTPS o todo HTTPS en general, puedes utilizar iptables.

Ambas opciones son independientes del proxy cache que utilices.

Una solución comercial para bloquear dominios de pornografía es OpenDNS.

Tenéis razón.

La única solución que queda es habilitar un proxy HTTP->HTTPS. He estado haciendo pruebas en ese sentido.
Ya que tarde o temprano terminarán obligando a pasar todo el tráfico de Youtube por HTTPS.
Además de que también serviría para cachear Facebook/Twitter/etc...

No se trata de utilizar otro proxy diferente a squid/raptor/thunder/etc.. sino de utilizarlo como complemento a esos programas, únicamente para las citadas webs (Youtube/Facebook/Twitter/etc...), de forma que reciba las conexiones como servidor por HTTP y las saque como cliente por HTTPS. Así no habrá problemas de certificados en el navegador del cliente, y éste siempre tendrá la opción de utilizar HTTP (con caché y más velocidad) o HTTPS (con más privacidad, pero sin cache y menor velocidad), sin que sea vea obligado a utilizar HTTPS por Youtube/Facebook/Twitter/etc...

Tal como están las cosas, no queda otra solución que esa, y cuanto antes se haga, mejor. Youtube se lleva el grueso del tráfico en cualquier ISP.

Si alguien quiere hacer de betatester puedo poner instrucciones por aquí, pero para utilizarlo en producción todavía no lo he probado lo suficiente.

Saludos.

Cita de: saintdave en Febrero 10, 2014, 11:24:47 AM
Podrias explicar un poco mas detallado de o que citas ahi, o decirnos de como corregir ese problema del chrome que no deja hacer cache al youtube.

Cuando visitas por HTTPS a Youtube, los HTML, imagénes, css, javascripts, etc.. de Youtube van por HTTPS, y no se pueden cachear.
Pero los vídeos siguen yendo por HTTP y sí se pueden cachear.

Para saber por cual protocolo va cada elemento de la página puedes utilizar un sniffer (tcpdump & wireshark por ejemplo), para analizar el tráfico de cada página web.

Los vídeos hasta ahora siempre han ido por HTTP, así que no hay de qué preocuparse. Si el proxy caché no lo cachea, no es porque no se pueda, es porque no lo tiene implementado, pero poder se puede.

Cita de: peguerojs en Febrero 09, 2014, 05:43:18 PM
BUENAS TARDES AMIGOS DE ALTERSERV HOY ME ENCONTRE CON QUE MI RAPTOR NO ESTABA CACHEANDO LOS VIDEOS DE YOU TUBE YA QUE ESTA PASANDO POR EL PUERTO 443 O HTTPS
MI PREGUNTA ES :    QUE VAMOS A HACER YA NO PODEMOS CHACHEAR FACEBOOK NI LAS IMAGENES NI LOS JUEGOS Y AHORA YA NO PODEMOS CACHEAR YOUTUBE
SERA QUE ALGUIEN TIENE ALGUNA SOLUCION PARA ESTO YA QUE ESTAMOS PERDIENDO TERRENO

Aunque Youtube utilice HTTPS, el contenido de los vídeos sigue pasando por HTTP (dominio *.googlevideo.com), así que sí se puede cachear, otra cosa es que el proxy caché que utilices no lo tenga implementado. Pero poder, se puede.

Los WISP y otras empresas que utilizan RaptorCache deberían hacer el siguiente cálculo contable.

1. Calcular cuánto ancho de banda medio les ahorra RaptorCaché al mes.
2. Consultar las tarifas de su ISP para saber cuánto dinero les supondría contratar ese ancho de banda ahorrado gracias a RaptorCache.
3. A esa cantidad deben restarle los costes de electricidad y de amortización mensual (el precio del servidor+probables reparaciones dividido por la vida media del servidor expresada en meses) de los servidores que utilicen para RaptorCache.
4. El resultado es el ahorro mensual real que supone RaptorCaché para tu negocio.

Y que menos, que de esa cantidad resultante, se destinase un 10% a donaciones para el proyecto. ¿Qué os parece?.

A los que llevan tiempo utilizando proxys caché:
Cuando Facebook no utilizaba HTTPS, ¿qué ratio medio de elementos cacheados servíais con el proxy caché?.
Es para saber si de verdad merece la pena programar algo así o no.

Saludos.

Saludos tonyvzla, puedo decirte las reglas iptables exactas para implementar lo que dije en el anterior post. Pero MK no lo utilizo. Como sistema operativo en routers utilizo OpenWRT.

Cita de: jojo en Enero 28, 2014, 01:35:11 PM
y perdona pero como me cambio de servidor?

edita /etc/apt/sources.list y usa otro mirror. Si buscas por esas palabras clave en google, encontrarás varias webs explicando cómo hacerlo, cuáles son los mejores mirrors, etc...

De todos modos apt no es la única forma de instalar esos programas, siempre puedes bajarte el código fuente de la web de cada proyecto y compilarlo e instalarlo tu mismo (./configure, make, make install). Así además podrás probar versiones más nuevas, betas, snapshots, etc...

Una caché no tiene porqué vulnerar la privacidad, depende de como se implemente y de como se administre.
Por ejemplo, una implementación que haría imposible vulnerar la privacidad de una caché sería guardar en lugar de la url, un hash de la url como nombre del recurso cacheado, y el contenido cifrado usando como password un algoritmo de hash diferente sobre la url.

Por ejemplo para cachear www.google.com/logo.jpg, como nombre de archivo para ese archivo en el proxy caché se usaría el hash ripemd160 de "www.google.com/logo.jpg", y el contenido se cifraría utilizando cualquier algoritmo de cifrado simétrico utilizando como password el hash sha de la url.
De esta forma, para acceder a cada elemento cacheado sería necesario conocer la url exacta, así que nunca podría accederse a nada que no esté disponible en internet sabiendo su url, el administrador no podría ver que hay guardado en su caché, sólo podría saber el contenido de la caché introduciendo cada URL que esté cacheada, pero no ver la lista de urls cacheadas.

En Facebook lo que utiliza un tráfico de datos más intensivo son las imágenes, el resto no necesitaría ser cacheado. De todos modos la eficacia no sería la misma que en Youtube, porque la variedad de fotos que cada usuario ve en facebook, es mucho mayor que los vídeos que se ven en Youtube. Por ejemplo, hay videoclips en youtube que tienen cientos de millones de visitas, pero no hay usuarios de Facebook cuyas fotos tengan cientos de millones de visitas.

¿Se puede cachear Facebook? Sí, si el usuario entra a traves de http://www.facebook.com (sin S), y un proxy transparente se encarga de modificar al vuelo el código html y acceder como cliente a la versión https de esa web. Es complicado, pero es técnicamente posible.
¿Sería rentable para ahorrar ancho de banda? Pienso que no, salvo en excepciones donde el ancho de banda sea extremadamente caro.

Por la descripción del error, el proxy no debe tener bien implementado (o no debe tener implementado a secas) el uso de la cabecera http "Range" con esas webs.

Si es para redes que sólo utilicen tráfico web, es más fácil bloquear todas las conexiones salientes excepto las que vayan por los puertos 53, 80 y 443 por TCP, y 53 por UDP.

(53=DNS, 80=HTTP, 443=HTTPS).

La forma más eficiente (menos intensiva en uso de recursos del servidor) de bloquear dominios es a nivel de DNS, no a nivel de proxy http.
Utilizando una regla de iptables para forzar el tráfico DNS por el del servidor DNS que se quiera utilizar con los dominios bloqueados.
Como servidor DNS ligero que redirige las peticiones DNS y bloquea los dominios deseados se puede utilizar "dnsmasq".
También se puede utilizar un servidor DNS externo que ya esté configurado para bloquear los dominios de adultos, como OpenDNS, aunque es de pago, tiene una versión gratuita.

La única forma de intervenir el tráfico HTTPS es un "man in the middle" y eso siempre requerirá que cada usuario se instale un certificado ssl en su navegador creado para la ocasión.

Pero hay otra forma más sencilla de hacer esto, sin que el usuario deba instalar un certificado. Y es mostrar el tráfico https como tráfico http utilizando un proxy que haga de cliente HTTPS y de servidor HTTP.

Por ejemplo, si se quiere intervenir el tráfico de Twitter, cuando el servidor proxy HTTP recibiera peticiones de conexión a "http://ww.twitter.com" debería mostrar el contenido de "httpS://www.twitter.com", de esa forma, si el usuario voluntariamente decide utilizar "http://www.twitter.com" o "http://www.facebook.com" no será redirigido a la versión HTTPS de esas páginas. Además, según la web, podría ser necesario cambiar el código html on-the-fly para modificar las urls HTTPS por HTTP en el html.

Por tanto, poder se puede hacer, siempre que el usuario entre en primer lugar a la versión HTTP de la web. Pero es algo muy costoso en términos de consumo de recursos del servidor (cifrar/descifrar en ssl siempre lo es). Y el contenido que más ancho de banda consume nunca utiliza HTTPS (vídeos de youtube, etc). Por lo que implementar algo así sólo tiene sentido donde el ancho de banda sea muy caro, o en caso de que se necesite espiar el tráfico por otros motivos (monitorización por parte del estado, etc...).

RaptorCache es un proxy http transparente, por lo que no puede funcionar únicamente en modo bridge.
Ya que utiliza la capa de transporte (layer 4) del modelo OSI.
El modo bridge utiliza la capa de enlace d datos (layer 2) del modelo OSI.