[lacnog] Articulo: How to avoid security issues with VPN leaks on dual-stack networks

[Eduardo Trápani]

> 	A que te referias con esto y los host con redes privadas? No es
> necesario escribir NAT para decir NAT.

Obviamente no estás leyendo.  La línea que sigue a tu cita, incluída por
vos mismo es:

>> Estaría bueno, en modo irónico o no, ceñirse a lo que los otros dicen.
>> IP privadas y proxy es un esquema común (y el que tenía en mente y
>> todavía veo en algunos lugares).

IP privadas + Proxy.  Sé que no necesito explicitar que Proxy != NAT, ¿no?

Proxy: squid, apache (en modo proxy), tinyproxy, wwwoffle, ¿se entiende?
 *NO* hay NAT.  Por eso *no* dice NAT, ¿está más claro?

> 	Seguridad mi ISP? Por favor, si crees que tu ISP te va a dar seguridad
> y confias en ella ...

*Parte* de la seguridad.  Viste la parte en que decía que eras *una*
parte, bueno, el ISP es *otra* parte.  Y, por las dudas, hay más, como
los nodos intermedios, el host con el que efectivamente te comunicás ...

Yo doy por bueno el recursive DNS de mi ISP, no digo que sea lo mejor,
pero sí hace que crea en esa parte de seguridad que provee.  Y en muchos
lugares, cuando estoy en una inalámbrica, ni siquiera tengo la opción,
haga lo que haga me va a resolver localmente.  ¿Cómo resolvés vos el
tema de DNS?

> 	Totalmente. Si quiero seguirad encripto end-to-end. Y creo que si
> sonrien, pero por la inocencia de confiar en mi ISP para darme seguridad.

Para darte *una parte* de la seguridad.  El cifrado end-to-end no
depende solamente de vos, sino de lo que ofrezca el otro "end".

Igual me suena a que hay una pequeña confusión entre seguridad de los
datos y seguridad de las aplicaciones y los protocolos.  Para
ejemplificar: poco importa el cifrado si tenés un buffer overflow que
permite ejecución remota de código.  Y sí, eso pasó en SSH por ejemplo.

Eduardo.