Google Chrome: ecco il tracciante…

Comments (10)

Trackback URL | Feed dei commenti

1. flod says:

   06/09/2008 at 2:32 pm

   Credo di essermi perso qualche pezzo in questo post…

   Per quanto mi è dato sapere: * Firefox 2 di default non fa il controllo antiphishing con Google ma usando una lista locale, l’utente può attivare questa funzione (controllo con Google) accettando anche la relativa Informativa sulla privacy nelle opzioni * la lista locale di siti viene aggiornata periodicamente (mi sembra ogni mezz’ora), sia per Fx 2 che per Fx 3 (dove è l’unica opzione, visto che è sparito il controllo diretto tramite Google)

   Parli di una richiesta di Firefox per ogni sito visitato?

   P.S. quand’è che metti la possibilità di seguire i commenti via mail? ;-)
2. TM says:

   07/09/2008 at 1:13 am

   @flod Firefox e Chrome funzionano in modo simile. E indovina un po’? Firefox usa Google.

   In Chrome viene salvata localmente una lista di hash parziali che identificano le URL dei siti “insicuri”, caricata da un server di Google. Ci sono diverse “liste” che il browser richiede al server, una per il phising, una per il malware, ecc.

   Il primo confronto avviene localmente. Se l’hash parziale della lista locale combacia con l’hash (parziale) della URL digitata, e solo allora, il browser invia una richiesta per ottenere la lista degli hash completi che corrispondono alla porzione di hash verificata. Ottenuta la lista degli hash se uno di essi combacia integralmente con quello ricavato dalla URL allora il sito e’ considerato insicuro.

   Il tracciante indicato da MF e’ relativo alla richiesta iniziale di download delle liste, ma ci sono altri messaggi da/verso il server Google, differenti ma con struttura simile.

   Quindi la risposta al tuo quesito e’: non ti sei perso nessun pezzo, hai in parte ragione (e in parte no).

   Questo in breve. Bye guys!
3. ArMyZ says:

   07/09/2008 at 11:55 am

   Interessante. Ti seguo volentieri. A.
4. flod says:

   07/09/2008 at 5:22 pm

   @TM

   Ok, davo per scontato che il controllo fosse esclusivamente locale.

   Ma se la wrkey viene inviata solo in caso di corrispondenza dell’hash parziale, direi che c’è ben poco da tracciare, o sbaglio?

   Caso ben diverso sarebbe se, per ogni URL visitato, venisse inviata una richiesta a Google.
5. flod says:

   07/09/2008 at 5:43 pm

   Peraltro davo un’occhiata al protocollo http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec . wrkey viene indicato come parametro opzionale (e mi pare di capire che serva per garantire la sicurezza della comunicazione tra client e server) . P.S. il box dei commenti mangia le linee vuote :-(
6. Matteo G.P. Flora says:

   07/09/2008 at 6:06 pm

   @flod

   per non lasciarti a bocca asciutta fino alla presentazione accenno a sommi capi:

   • L’ID della wrkey viene generato NON dal client ma da Google. Può contenere, quindi per quel che ne sappiamo anche solo un md5 del client-string
   • Ogni mezz’ora Google viene aggiornato dell’IP in QUEL momento di QUEL client
   • Ad ogni accessoa d un servizio di Google, Google non solo ha l’IP, ma è anche in grado di ricreare l’ID e di consultare quindi la history

   Safebrowsing darà anche pubblica, ma la implementazione della generazione dell’ID rimane un segreto interno a Google. Esistono, infatti, solo un metodo Get-Key ed uno di update.

   Sono sicuro che sei in grado di vedere dove sto andando a parare…

   Finora l’utilizzo contemporaneo di più PC da stesso IP era un problema per Google. Non più.
7. flod says:

   07/09/2008 at 6:39 pm

   Ok, aspetterò l’articolo ;-) . Questo magari serve a qualcosa? https://wiki.mozilla.org/PhishingProtection:ServerSpec#GetKeyRequest
8. lorenzodes says:

   07/09/2008 at 6:55 pm

   Ecco come viene generata:

   http://safebrowsing.clients.google.com/safebrowsing/getkey?client=vivalapizza

   http://safebrowsing.clients.google.com/safebrowsing/getkey?client=vivalapizza2
9. lorenzodes says:

   07/09/2008 at 7:04 pm

   Dalla Wiki di mozilla:

   ” GetKey Request

   The GetKey request is used when the browser starts up to create a shared secret key between the client and the server. The secret key is used to encrypt lookup requests and also for authenticating table updates. The protocol does not enforce the use of a secret key but it’s strongly encouraged. To be secure, the client makes the a GetKey request over SSL.

   A server needs to respond with the following data:

   clientkey:24:pOAblTUiZFkLSv3xRiXKKQ== wrappedkey:24:MTqdJvrixHRGAyfebvaQWYda

   The client key is a 16-byte long random nonce generated by the server when receiving the GetKey request. The wrapped key is the random nonce encrypted by a server key. The wrappedkey is opaque to the client and a server may implement any encryption algorithm it sees fit. The wrappedkey allows the server to reconstruct the client key without requiring per-client state. It is up to the server to include verification information into the wrapped key that might allow it to determine if decrypting it was successful. “
10. JimmY2K. » Blog Archive » Google Chrome, impressioni d’uso says:

    08/09/2008 at 1:58 am

    [...] Non sono mancati i problemi, specie quando venivano coinvolti plug-in esterni, ma è solo una versione preliminare. Si tengano anche da conto le questioni relative alla privacy sollevate da alcuni. [...]