Hola gente,

Soy nueva por aquí (no sé si este post lo pongo en el sitio correcto) me surge una duda que llevo días intentando solucionar.
Como creo que le pasa a muchos, en las empresas, universidades.... muchas de las páginas están capadas, en mi caso Facebook.

He intentado entrar con decenas de Proxys que he encontrado en internet, pero en todos el acceso es denegado.
Me podéis recomendar alguna otra forma de poder burlar al sistema y meterme en páginas capadas???

Lo agradecería mucho!!
Saludos.

También varios para probar:

http://www.archivospc.com/c/1179/Proxy.php

Saludos

 Que tal.

Bueno, soluciones a modo proxy a muchas y variadas.

Como solucion Proxy, podrias probar Ultrasurf. Buscalo por inet.

Ahora, una solucion mas interesante seria esta otra: usando el proxy de google.
Yo en particular uso esta opcion que te propongo no solo para cambiar el idioma ( a espanol ) de una web la cual
no entiendo el idioma en la que esta, sino como solucion proxy tambien.

El caso es que vi hace poco incluso por aqui esta solucion y quede grato de verla.
El caso consiste en aplicar esta URL:
http://translate.google.com/translate_c?hl=es&u=http://www.web_a_visitar.com
donde web_a_visitar seria la web a visitar. :__)

Como ves, usamos el subdominio dedicado al translate de Google como Proxy.

Dependiendo de las reglas de filtrado o ACLs impuestas en la confi del Servidor Proxy, podrias ejecutar esta opcion o no.

Supongamos unas reglas de filtrados las cuales aceptend wild cards asi + o -:

*.google.com

Si esta fuera una regla de filtrado, podrias utilizar el subdominio de translate de Google.

Bueno, Suerte.

  /**** MODIFIKO ****/

Ah, por cierto, en esa URL la variable hl determina el idioma en que se mostrara la web /* en este caso, es es igual a espanol ). La variable u determinaria la URL a visitar, la cual seria mostrada en espanol :__).
Pra verla por ejemplo en ingles, cambiarias el "es" por un "en".

 Que tal.

Bueno, pues un proxy no es funciona tan simple como dices.
A ver, si el Auth se habilita pues si pedira password/username, peero si no esta habilitado no hara falta.
Esta persona nunca se quejo de que el Auth ( Basic/Digest.. ) fuera un problema.

Se ve que tienes razon a la hora de mencionar los provilegios dados por Grupos. esto en Guindows ( creo ) es mas facil a medida que se maneja el Active Directory. Es cierto que via ACLs basadas en grupos, se hacen reglas de filtrado mas certeras, pero ello no quita que se puedan sobrepasar.

Lo que deduzco aqui es que dices que se puede cambiar el Proxy justo antes del que esta configurado, no llevaria a nada pues el que nos encaminaria finalmente a Inet seria el autoritativo? Dependeria de la configuracion de la Red usada. Lo diras por las aplicaciones como Tor o Ultrasurf..
El problema suele surgir porque esta confi no se "puede" cambiar, y por ello el Proxy legitimo deniega comunicaciones hacia ciertos sitios.

Ahora si las reglas de filtrado del proxy son pesimas, pues podria servir un cgi/web proxy como proxify por ejemplo,
anonymouse..

Veo que tambien hablas de https Proxy via el metodo CONNECT, ya que hablas sobre un tunnel sobre el puerto 443.. Pues esto si, es https proxy via el HTTP Method Connect. En resumen, cuando nos encontramos en una Red con Proxy el cual soporte el metodo connect y asi conexiones https, podemos tunnelear la comnunicacion.
O sea, cuando un Proxy ve una conexion http con metodo connect, supone que se va a usar una comunicacion segura ssl por el puerto 443 remoto, redireccionando las comunicaciones sin mirar el conenido para respetar la seguridad del mismo ( por ello http/secure ). Pues este ataque consistiria en tunnelear la comunicacion mediante las cabeceras http. O sea, con el metodo http Connect en las cabeceras http el proxy dejaria de mirar el payload de las mismas. Imaginemos una conexion https "legitima":

CONNECT remote-server:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: remote-server
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache

Pues ahi estariamos ejerciendo una conexion https al puerto 443 del host remote-server. Todo es legitimo.
Ahora, supongamos otra tal:

CONNECT another-server:anyport HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: another-server
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache

Como vemos, permanecemos con el Metodo Connect, pero ahora estamos conectando con "another-server" en "anyport", por lo que podriamos conectar con por ejemplo host.mydomain.com:23 para encodear en las cabeceras una posible conexion telnet.

Al ser el Metodo HTTP Connect, el Proxy "dejaria" que la comunicacion fluyese sin mirar el payload al creerla una comunicacion segura basada en https.
Esto est amal explicado quizas y resumido, y no era la intencion de este post el explicar los funcionamientos internos de https proxying ( que vamos yo me lo tendria que mirar mejor ). Si era la intencion explayarme mas acerca de algo que tu has comentado demasiado brevemente.

Solo terminar diciendo que dependiendo de si el Proxy deja conexiones hacia el puerto 443 ( https ) y de demas configuraciones, se podria usar alguna aplicacion para hacer https proxying como:

http://search.cpan.org/author/BOOK/connect-tunnel-0.03

Por ello si que apoyo tu idea del posible https proxy.

Es que, a veces respondemos creyendo que la persona va a sobrentender nuestros terminos, cuando no es asi.

Suerte.