El 07/04/15 a las 18:15, låzaro escribió:
Thread name: "Re: [Gutl-l] Incrementar la seguridad en el Proxy(Squid) 
[1/2Solucion]"
Mail number: 11
Date: Tue, Apr 07, 2015
In reply to: Michael González Medina
El 07/04/15 a las 16:56, Michael González Medina escribió:
El 07/04/15 a las 16:48, Carlos R Laguna escribió:
El 07/04/15 a las 16:06, ERNESTO TUR LAURENCIO escribió:
Como bien dices la idea de blindar más aún las conexiones
mediante el uso de SSL es una, lo que ya sabes que vas a
sacrificar velocidad de acceso por nivel de cifrado.

Mientras no aparezca la indicada, goza con la equivocada.

Salu2

-----Mensaje original-----
De: gutl-l-boun...@jovenclub.cu
[mailto:gutl-l-boun...@jovenclub.cu] En nombre de Michael
González Medina
Enviado el: martes, 07 de abril de 2015 02:39 p.m.
Para: Lista cubana de soporte tecnico en Tecnologias Libres
Asunto: [Gutl-l] Incrementar la seguridad en el Proxy(Squid)

Buenas tardes:

Antes que nada aclarar, que, cuando me refiero a seguridad en
el Proxy(Squid), estoy hablando de, la comunicación entre el
cliente y el servidor. Este tema se ha tocado varias veces y
existen otras variantes(como el Kerberos, LDAP, helpers del
Squid hechos para esto,
etc) pero... siempre hay un pero... existen
holgazanes/vagos/paranoicos como yo, a los que estas
soluciones les resulta un tanto engorrosas o...
no compatible por filosofía etc...

En fin, que buscando y probando, he logrado el tópico de este
correo pero, sin usar ninguna de las soluciones anteriores
sino, una un poco mas sencilla, pero que por ello, no deja de
ser válida, cual...:

Web Proxy Autodiscovery Protocol(WPAD) sobre SSL

me explico:

Mediante el queridísimo servidor de páginas web Apache,
montamos un Virtualhost(mencionar aquí *muy importante* que se
le debe habilitar el soporte para SSL lo cual es crítico en
este caso[lo explico mas adelante]), en este, ponemos el
script "proxy.pac" (que es el que contiene la información del
proxy), luego en los clientes(es decir en los
navegadores[Firefox]) configuramos la red como "configuración
automática del proxy" y le ponemos la url del Virtualhost, y
listo!

La diferencia del método tradicional (sin soporte para SSL)
es... que...
mientras, en el método anterior, si se conecta un
sniffer(hablo de sniffer porque es lo mas común para
monitorear redes en busca de datos
etc..) y se monitorean las conexiones, se podían obtener datos
relevantes en cuanto a user/pass etc.. sin embargo, al estar
comunicándose sobre SSL el sniffer no puede ver con la misma
facilidad dichos datos, por lo que, sí, creo que ahora la
comunicación entre cliente-servidor es un tanto más segura,

saludos,

PD: Se aceptan críticas/debates , dale Lázaro, "pichea" que yo
se que este tema te encanta.




______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
Tus opciones son, Kerberos
SSL, Firefox y Chrome lo soportan aunque no esta muy documentado.


cierto Carlos, lo que pasa es que no me quiero enredar ni con
Kerberos ni con LDAP para autenticar usuarios de un proxy, de
cualquier forma, muchas gracias por tu respuesta.

Por ejemplo, estoy "sniffeando" el esquema el digest y hasta
ahora... no veo el texto plano con el user y pass, así que....
pudiera(dejame cruzar los dedos.... ;-) ) ser una opción,

saludos,

Bueno vamos mejorando, ya me he cansado de "sniffear" el trafico de
datos entre cliente y servidor para autenticar en el Proxy y no
aparece el texto plano por ninguna parte, en cambio el metodo digest
usa nuevos campos como el nonce y el cnonce donde al parecer viajan
encriptados los datos del password(el campo user sigue siendo plano)
pero bueno, ya creo que ahora si, esta un pelin mas seguro,

saludos,

PD: No obstante sigo a la busqueda de perfeccionar esto hasta donde
sea posible.
En digest, el servidor del lado de hallá, almacena el password cifrado
y el cliente le envía dicho password cifrado, el servidor lo compara
con el que tiene almacenado y lo mache. Lo cual no es muy diferente de
si yo te intercepto el password y te lo mando cifrado :D sin
importarme cual sea este xD



y haz probado que pinche esto que me comentas? Te pregunto porque cuando cliente-servidor establecen una conexión para transferir datos(en este caso user/pass) dichos datos interceptados(flags, headers, etc... ) en teoría deberían ser válidos durante el tiempo de conexión por lo que si los interceptas y envías desde otro host no deberían servirte,

saludos,

--
Michael González Medina
Administrador de Red
Centro Nacional de Sanidad Vegetal


--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l

Responder a