Pues ahí no dice como consiguen las llaves privadas de los certificados de las páginas las cuales son necesarias para descifrar el tráfico del intercambio de llaves de sesión. Creo que la página que ud miro es sobre el uso de fortinet en un entorno controlado usualmente un entorno empresarial en el cual los navegadores de los empleados se parchan con certificados para poderles monitorear el tráfico https pero nada tiene que ver con lo que hace claro.
Si, eso es algo que aun no tengo completamente "claro".
Siempre he dicho que FortiGuard no es pensado para ISP y aun menos para un ISP como tamaño Comcel.
Cuando buscaba aplicaciones a nivel de ISP me contestaron que los ISP no pueden ver el contenido como tal pero que sí tienen acceso a los headers.
A base de los headers pueden saber que estamos haciendo o a cual recurso accedemos.
A base de estos headers también pueden bloquear o permitir el trafico.
En este sentido tal vez no hay que alarmarse porque no es probable que los de Comcel están leyendo los correos de uno, pero el hecho que tienen acceso a los headers de los paquetes ya es algo que levanta sospecha.
Concretamente, el problema que tuvimos con los correos gmail y outlook fue que los adjuntos no se podían descargar. Esto fue resuelto con el tiempo por los de Comcel.
Lo que si debo recalcar (otra vez, porque ya habían varios con la misma inquietud) aquí sí estamos hablando de un "cache proxy" y si quieres te lo puedo demostrar con un TCP trace.
O puedes leer mis post anteriores donde claramente puedes ver que el recurso esta siendo servido desde ADENTRO de la red de Comcel, específicamente desde el proxy FortiGuard.
Código:
scan report for bing.com (13.107.21.200)
Host is up (0.042s latency).
Other addresses for bing.com (not scanned): 204.79.197.200
TRACEROUTE (using port 443/tcp)
HOP RTT ADDRESS
1 0.00 ms Lan IP
2 ...
3 14.00 ms 172.21.111.234
4 18.00 ms dynamic-ip-19015711133.cable.net.co (190.157.11.133)
5 37.00 ms 10.14.16.78
6 35.00 ms 10.14.18.29
7 42.00 ms 172.25.255.24
8 ... 9
10 39.00 ms 13.107.21.200
También me gustaría que mires atentamente la IP, la cual no pertenece a Comcel, pero en el trace se evidencia que no se hace peering con ningún otro operador.
Latencias hablan por si, 39ms es demasiado bajo teniendo en cuenta que el recurso (bing) esta hospedado en un CDN que no pertenece a Comcel.
Así que en este caso, Comcel esta haciendo spoofing de IP.
Si aun no crees, haz un tracert normal (icmp) y vez que milagrosamente llegaras a la IP real...Porque Comcel hace un pass-through de trafico icmp para que sea mas difícil de descubrir que en efecto, están haciendo spoofing.
El caso de Google con su GGC es un poco diferente, ya que los servidores de Google están dentro del mismo datacenter de Comcel, según el contrato que tiene el ISP con Google:
The GGC servers are not hosted within datacenters owned by Google. Instead, Google contracts with internet service providers (ISPs) within the district to host Google’s GGC servers within the ISP’s datacenter. When a user requests Google’s content, the ISP attempts to route the user’s request to a GGC server within its own network (within the district) before routing the request to Google’s central data storage servers (outside the district).
Enfin, el filtrado se hace a base de dirección IP, porque algunas paginas pasan por el filtro usando servidor DNS "x" mientras con servidor DNS "y" no pasa por el filtro, esas situaciones ya hemos tenido acá en el tema.
Edit: No esta mal...
Escorpiom.
Última edición: