squid transparente con https

Imagen de sxavyer

Forums: 

squid transparente con https

buenas tardes,
he leido de todo un poco
y no consigo hacer q squid transparente acceda a paginas https
es raro porque si en cada cliente especifico el proxy con el puerto 3128 en mi caso, sale sin ningun problema a paginas con https pero al hacer proxy transparente es decir con iptables REDIRECT, las paginas http habre normalmente pero las https no las abre, el explorador se queda pensando y al final sale error. y en los log tanto del firewall como del squid no me bloquea nada, no registra ningun bloqueo no registra nada en esos casos.

ayuda!!!!!

lo que hice fue hacer REDIRECT al puerto 3128 de todo lo que sale por el puerto 443 y me da un error del explorador (no de squid) q dice "Código de error: ssl_error_rx_record_too_long "

repito si configuro el proxy manualmente en cada cliente salgo sin problemas a paginas https como www.gmail.com por ejemplo

la version de squid q utilizo es 2.6
centos 5

ya he revisado todo t3engo bien las acl caso contrario no ingresara https ni especificando manualmente el proxy en los clientes, tengo abierto el puerto 443 trafico saliente a internet en mi firewall asi q no es nada de eso

he leido q proxy transparente no soporta https es verdad eso y si es asi he leido q debe hacerc nat pero no veo lo mas adecuado eso ya que me estaria saltando el proxy y justamente eso es lo q no quiero.

gracias

No puedes hacer pasar las

Imagen de acl

No puedes hacer pasar las peticiones https por el squid. Lo que hiciste al redireccionar el puerto 443 al 3128 es provocar que una petición de SSL o TLS (que no es http) llegue al puerto de squid. Squid al ver que no es una entrada http válida simplemente cierra la conexión y el browser interpreta esa salida como un error.

Lo que debes hacer es aceptar forwarding del tráfico dirigido a 443 sin redireccionar.

No es posible hacer cacheo de https y tampoco es posible hacer un proxy transparente de https. Tienes que usar iptables si tu proxy es transparente.

Gracias por

Imagen de sxavyer

Gracias por responder"!!!!

Lo que debes hacer es aceptar forwarding del tráfico dirigido a 443 sin redireccionar.??
a q te refieres con eso especificamente , me puedes dar una pequeña explicacion por favor. eso es con iptables verdad.

y el momento q haga eso no tengo el problema q mis clientes (con algo de conocimiento) por ejemplo empiecen a navegar saltandose el proxy.

mi politica por defecto del iptables es denegar todo e ir abriendo lo q necestio..

Att.

Xavier !!!

tendrías que agregar reglas

Imagen de acl

tendrías que agregar reglas de la forma

$IPTABLES -A FORWARD -s tu-red/tu-mascara -d destino/mascara -p tcp --dport 443 -j ACCEPT

No vas a poder estar a salvo de que tus clientes usen puertos autorizados para transmitir otro tipo de tráfico. Incluso si decides no hacerle transparente y dejas que squid deje el paso de conexiones al puerto 443, alguien con conocimiento puede hacer una aplicación que hable al proxy y le pida enviar datos por el 443 alguna aplicación que tenga corriendo remotamente y que hace lo que el quiera.

Ese es un problema que no puedes resolver técnicamente. Necesitas que los usuarios estén conscientes que el uso de los equipos está regulado, es un privilegio y que puede ser revocado en caso de mal uso. Y eso se lo hace con la política de uso de equipos.

una cosa adicional entonces

Imagen de sxavyer

una cosa adicional

entonces porque el archivo de configuracion del squid menciona los puertos 443 tanto en el parametro Safe_ports como en SSL_ports porque incluso hay acls con dichos puertos y asi mismo permite esos puerto con "http_access deny !Safe_ports" que me dice q niegue todo menos los puertos safe en los cuales incluyen el 443.

y si squid no soporta https, porque si en los navegadores de los clientes yo configuro el proxy manualmente ahi si accesa a paginas https????

tengo esa duda!!!

gracias por responder...

Att.

Xavier !!!

Cuando configuras tu browser

Imagen de acl

Cuando configuras tu browser para que se alcance sitios https mediante squid, lo que sucede es que el browser envía una petición estilo proxy (conéctate a ese man al 443 y mandale este chorizo; cualquier chorizo que él mande, me lo pasas). En este caso, squid solo actúa como intermediario y no puede hacer nada con los datos que tiene en sus manos. Las directivas de connect y safe_ports son para definir puertos en los que permites que el squid haga de intermediario a lo poncio pilatos.

Cuando haces que el proxy sea transparente, el browser no sabe que hay un proxy de por medio y en lo que a él concierne, está hablando directamente con el destinatario, por lo que enviará el chorizo de arriba sin las instrucciones para el proxy de a donde tiene que conectarse.

acl!!! gracias por tus

Imagen de sxavyer

acl!!! gracias por tus respuestas muy valiosas.

ahora ya comprendo todo esto aunq si me puedes despejar esta ultima duda por favor.

yo navego con proxy transparente, tengo mi servidor en el cual corre squid dhcp etc, lo administro con webmin (el cual utiliza el puerto https en el puerto 10000) porque al yo ingresar desde mi pc en el explorador https://192.168.1.1 (direccion ejem del servidor) ingresa sin problemas pese a q se trata de https y esta corriendo squid.

es porque es una peticion local??? mi pc por ejem tiene la direccion 192.168.1.2 y mi server la 192.168.1.1. asi mismo desde mi pc 192.168.1.2 ingreso a un router (interfaz web del router https) tambien ingresa normalmente sin configurar manualmente el proxy en mi explorador.. porque se da eso

squid reconoce peticiones locales (lan - misma red) y no hace caso a eso????

Att.

Xavier !!!

No hay de qué. En el caso de

Imagen de acl

No hay de qué.

En el caso de acceder a un sitio https en la máquina que también corre el proxy, el paquete está destinado a ésta, y por tanto la redirección a 3128 que pusiste no aplica y el paquete simplemente llega a la capa superior. En resumen, sí, la petición es local y no pasa por el proxy.

SOLUCIONADO!!!!!

Imagen de sxavyer

Ahi si todas mis dudas aclaradas.

Tranks acl.

Opinion personal.
El squid como tal por mas robusto que sea para restriccion autentificacion etc etc, tiene una gran debilidad en cuanto a https, nada q no se pueda solucionar !!!claro. Pero la idea de proxy transparente deberia englobar todo y bueno mas que una critica esto es un comentario, ya que aun no me considero desarrolador en linux mas bien aplico lo que ya esta establecido.

buen dia!!!!

:D

Att.

Xavier !!!

https es un protocolo

Imagen de acl

https es un protocolo encriptado, es decir que únicamente el origen y el destino del mensaje pueden leer tal mensaje. Squid, al ser un intermediario no va a poder decifrar lo que pasa a través de él. Esto en el caso que le digas al browser que use a squid como intermediario. Fíjate que es el cliente el que tiene que saber con quién está hablando.

En el caso de transparencia, el browser no sabe que hay un proxy de por medio. ¿Cómo puede saber la puerta de enlace si los paquetes que el browser envía son para el proxy o para alguien más? La respuesta es que no puede.

No existe forma de "solucionar" esto, pues no es un problema (ni una limitación exclusiva a squid), es simplemente la forma en que trabajan los protocolos. Si necesitas que siempre se pase por el proxy, tienes que renunciar a la transparencia y decirle al browser que encapsule sus pedidos. Ganas en control, pero pierdes en comodidad. Y viceversa.

Algo similar sucede cuando quieres hacer autenticación: el browser tiene que saber con quién está hablando al otro lado.

En realidad si se puede, y

En realidad si se puede, y algunos proxys comerciales lo hacen, lo que pasa es que es de dudosa etica.

Hacen lo llamado "Man in the middle" o inspección SSL es decir engañar al cliente y hacer de intermediarios en una conexión ssl.

Funciona de la siguiente forma:
1) El cliente desea contactar con una pagina cifrada.
2) El proxy intercepta la petición.
3) El proxy hace una conexión ssl como cliente al servidor
4) Mira el certificado del destino, copiando los campos comunes, sobre todo el CN, pero firmandolos con su CA.
5) El proxy muestra este certificado hecho al vuelo al cliente, solo de advierte si el cliente no confia en la CA del proxy.
6) Ya está creada la conexion.

Cliente --https--> [proxy inspección en politicas ] --proxy https client--> Site SSL

Con este sistema es posible el uso de politicas con conexiones SSL, pero debes advertirlo a los clientes, pq podrias estar incurriendo en un delito contra la intimidad u otros.

Lo más sencillo si la red que accede al proxy ruta directo a Internet, es dejarlo pasar, y meterlo en algun tipo de cola QoS para limitar el uso de p2p.

Si la red no ruta a Internet, es mas complicado, ya que tendrás que crear un tunel entre esa red y el gw a Internet, y despues marcando paquetes y con policy routing puedes enviar solo el trafico que quieras a esa gw (la del tunel).

Páginas