Quali sono alcuni modi possibili per inviare una richiesta anonima per eseguire nuovamente la scansione di Google? [chiuso]

0

Questa è un'architettura proposta per inviare una richiesta anonima per eseguire nuovamente la scansione della pagina web su google bot. Ho provato a venire con la soluzione indicata di seguito. L'intenzione di postarla qui è conoscere le falle nella sicurezza nell'architettura data e scoprire quali miglioramenti potrebbero avvantaggiare l'architettura attuale

Ecco lo scenario, diciamo che l'utente visita un URL e sospetta che la pagina sia occultata o che per qualche motivo desideri che il bot esegua nuovamente la scansione dell'URL. Google fornisce fetch come strumento google per lo stesso. Ma comunque, quando inviamo l'URL a Google, Google conoscerà il nostro IP. Voglio che questa richiesta sia anonima. Per favore non confondere con questo. Supponiamo che raggiungo la pagina disattivando (disabilitando) il mio JavaScript.

Quindi ecco i passaggi: 1. Richiesta dell'utente per il numero casuale da un'autorità che concede all'utente un numero casuale e lo stesso al server di Google. Da una durata da t a t 'stesso numero casuale verrà dato a tutti gli utenti e Google memorizzerà anche lo stesso numero casuale per quella durata. Dopodiché verrà visualizzato un nuovo numero casuale e tale numero casuale non verrà utilizzato {Volevo ridurre al minimo la gestione delle chiavi per un utente, quindi ho fatto ricorso a tale approccio}
2. Una volta ottenuto il numero casuale, XOR questo con l'URL e inviare l'URL crittografato a trusted mediator . Questo mediatore memorizza la richiesta di tutti gli utenti {URL crittografato} e dopo ogni 5-10 minuti fornisce questi URL al server di Google. 3. Si noti inoltre che un utente può inviare un URL una volta ogni 15 minuti. 4. Non appena la finestra di dialogo con il mediatore è terminata, la connessione viene chiusa dall'utente. 5. Ora mediatore invia tutti gli URL crittografati al server di Google 6. Il server di Google conosce solo gli URL e l'origine crittografati come mediatore, pertanto la privacy dell'utente viene preservata

Queste sono supposizioni che ho fatto: a.Mediatore può consentire solo una connessione per utente o client in ogni finestra di 15 minuti. b. Il Mediatore al termine della connessione con l'utente o il cliente non conserva dettagli sull'utente o sul cliente c.Il generatore di numeri casuali è un vero generatore di numeri casuali d.Mediatore e generatore di numeri casuali sono entrambi tolleranti ai guasti (in questo contesto intendo robusti da caricare).

Quali sono alcuni difetti esistenti? Quali possono essere i miglioramenti?

EDIT: Nonostante abbia accettato la risposta. Accolgo con favore commenti e altre risposte e miglioramenti, quindi sentitevi liberi di farmi conoscere i difetti o i miglioramenti.

    
posta Paul Schimmer 24.04.2017 - 18:25
fonte

1 risposta

0

È più semplice utilizzare qualsiasi proxy VPN o SOCKS.

Quando invii la tua richiesta di riesame (o praticamente qualsiasi richiesta) tramite un VPN / proxy:

  1. Il servizio finale (Google) vede solo l'indirizzo IP della VPN / del proxy, non il tuo vero IP
  2. Il proxy / mediatore non può vedere i dati (URL) inviati, perché la tua connessione al servizio finale (Google) è crittografata utilizzando la crittografia a chiave pubblica (TLS)
  3. La tua unica preoccupazione è di garantire che il browser non invii cookie (o identificatori di tracciamento simili) durante la connessione al servizio finale (Google). Questo può essere fatto usando un nuovo profilo del browser.

L'unica "debolezza" qui è che dal momento che questa è una richiesta in tempo reale a bassa latenza, è possibile che un attacker sufficientemente avanzato possa monitorare tutto il collegamento a Internet del server VPN / proxy ma non abbia compromesso il server VPN / proxy stesso per fare analisi del traffico per vedere che c'è una richiesta in uscita al servizio finale poco dopo che i pacchetti arrivano al server intermedio.

Per proteggerti dall'analisi del traffico, avrai bisogno di un sistema ad alta latenza / store-and-forward. Il protocollo stereotipo store-and-forward è email. È possibile che il server intermedio esegua un server di posta elettronica, si invii una e-mail all'intermediario, che memorizza l'e-mail per un periodo di tempo casuale, e quindi inoltra la posta / richiesta al servizio finale a quel timeout, eventualmente il batching richieste. Per garantire la privacy dell'URL contro il server di posta dell'intermediario, puoi GPG crittografare l'e-mail su una chiave GPG detenuta dal servizio finale.

    
risposta data 25.04.2017 - 11:19
fonte

Leggi altre domande sui tag