¿Cuáles son algunas formas posibles de enviar una solicitud anónima para volver a rastrear a Google? [cerrado]

0

Esta es una arquitectura propuesta para enviar una solicitud anónima para volver a rastrear la página web a google bot. Traté de encontrar la solución que se da a continuación. La intención de publicarlo aquí es conocer las lagunas de seguridad en la arquitectura dada y descubrir qué mejoras podrían beneficiar a la arquitectura actual.

Aquí está el escenario. Digamos que el usuario visita una URL y sospecha que la página está oculta o, por algún motivo, quiere que el bot vuelva a rastrear la URL. Google proporciona fetch como herramienta de google para el mismo. Pero de todos modos, cuando enviemos la URL a Google, Google conocerá nuestra IP. Quiero que esta sumisión sea anónima. Por favor, no confunda con esto. Supongamos que llego a la página desactivando (deshabilitando) mi JavaScript.

Así que aquí están los pasos: 1. Solicitud del usuario para un número aleatorio de una autoridad que otorga al usuario un número aleatorio y el mismo al servidor de Google. De una duración de t a t ', todos los usuarios recibirán el mismo número aleatorio y Google también almacenará el mismo número aleatorio para esa duración. Después de eso, aparecerá un nuevo número aleatorio en la imagen y ese número aleatorio no se utilizará {quería minimizar la administración de claves para un usuario, así que recurrí a ese enfoque}
2.Una vez que obtengamos el número aleatorio, XOR con la URL y enviemos la URL cifrada a trusted mediator . Este mediador almacena la solicitud de todos los usuarios {URL encriptada} y después de cada 5-10 minutos entrega esta URL al servidor de Google. 3. También tenga en cuenta que un usuario puede enviar una URL cada 15 minutos. 4. Tan pronto como el diálogo con el mediador finalice, el usuario cerrará la conexión. 5. Ahora el mediador envía todas las URL cifradas al servidor de Google 6. El servidor de Google solo conoce las URL cifradas y la fuente como mediador, por lo que se preserva la privacidad del usuario

Estas son suposiciones que hice: a.Mediator solo puede permitir una conexión por usuario o cliente en cada ventana de 15 minutos. b.Mediator al terminar la conexión con el usuario o cliente no guarda detalles sobre el usuario o cliente c.El generador de números aleatorios es verdadero generador de números aleatorios d.Mediator y el generador de números aleatorios son tolerantes a fallos (en este contexto me refiero a robustos para cargar).

¿Cuáles son algunas fallas existentes? ¿Qué pueden ser mejoras?

EDITAR: A pesar del hecho, he aceptado la respuesta. Doy la bienvenida a comentarios, otras respuestas y mejoras, así que no dude en hacerme saber los defectos o las mejoras.

    
pregunta Paul Schimmer 24.04.2017 - 18:25
fuente

1 respuesta

0

Lo más simple es usar cualquier proxy VPN o SOCKS.

Cuando envía su solicitud de recuperación (o casi cualquier solicitud) a través de una VPN / proxy:

  1. El servicio final (Google) solo ve la dirección IP de VPN / proxy, no su IP real
  2. El proxy / mediador no puede ver los datos (URL) que ha enviado, porque su conexión al servicio final (Google) está cifrada mediante el uso de criptografía de clave pública (TLS)
  3. Su única preocupación es asegurarse de que su navegador no envíe cookies (o identificadores de seguimiento similares) cuando se conecte al servicio final (Google). Esto se puede hacer usando un nuevo perfil de navegador.

La única "debilidad" aquí es que, dado que se trata de una solicitud de baja latencia en tiempo real, es posible que un atacante suficientemente avanzado pueda monitorear todo el enlace de Internet del servidor proxy / VPN pero no haya comprometido el servidor proxy / VPN Hágase un análisis de tráfico para ver si hay una solicitud de salida al servicio final poco después de que sus paquetes llegan al servidor intermediario.

Para protegerse contra el análisis de tráfico, necesitará un sistema de alta latencia / almacenamiento y reenvío. El protocolo de almacenamiento y reenvío estereotipado es el correo electrónico. Es posible que el servidor intermediario ejecute un servidor de correo electrónico, usted envía un correo electrónico al intermediario, que almacena el correo electrónico durante un período de tiempo aleatorio, y luego reenvía el correo / solicitud al servicio final en ese tiempo de espera, posiblemente por lotes peticiones. Para garantizar la privacidad de la URL frente al servidor de correo electrónico del intermediario, puede GPG cifrar el correo electrónico en una clave GPG que tenga el servicio final.

    
respondido por el Lie Ryan 25.04.2017 - 11:19
fuente

Lea otras preguntas en las etiquetas