Categorías
Minipost

Busquedas seguras en Google con SSL

Logo Google SSLInteresante movida de Google al brindar búsquedas encriptadas con SSL en su buscador para que nadie, excepto ellos claro, pueda saber que estás buscando. Y antes que hablen de privacidad, imaginen como puede ayudar a gente en países como China que están siendo constantemente monitoreados… sumenle un proxy TOR y quizás, con algo de suerte, puedas ocultarle a algunos Gobiernos lo que estás haciendo en TU PC. + Features: SSL Search y Google SSL

17 respuestas en “Busquedas seguras en Google con SSL”

Marvin,
el que la puede ver sos vos que la estas usando y no un “hombre en el medio” y mucho menos saber que es lo que estas recibiendo en tu PC :)

Mariano tiene razón, que los parámetros viajen en la url o en el POST es lo mismo en cuanto a la seguridad que da https. La encriptación te protege contra espionaje-ataques “en el medio”, y en el medio la url completa viaja encriptada. Claro que si alguien tiene acceso a tu PC (a tu browser) (sea mirando por encima de tu hombro, sea instalándote un malware) https no puede protegerte.

Pero vale la pena mencionar otro escenario que puede embromar a los chinos (u otros) que quieren estar seguros: si estás navegando desde una empresa con un proxy de https, ese actuará como un “man in the middle” y podrá leer todo – aunque para esto el usuario habrá tenido que aceptar el certificado del proxy como confiable (o que aceptar usar un navegador con los certificados ya seteados por la empresa).

Por ahora el problema, creo yo, “no” es “a man in the middle”, yo creo que el problema es el mismo Google grabando mi historial de búsqueda. Porque tu ya lo decís Mariano “…excepto ellos claro,”.

Yo he comenzado a utilizar ixquick.com que esta prometiendo borrar en 48 horas el historial de búsqueda, y los resultados vienen de fuentes como Google o Yahoo.

Súmale TOR, un poco de sentido común (i.e. borrar cookies, NO entrar en tu cuenta, …) y Google no podrá saber quien eres.

Eso sí, Google registra tu historial de búsqueda solamente si has entrado en tu cuenta, para “tu propia comodidad”. NO PUEDE HACER NADA MÁS, a menos que lo ponga explicitamente en su Declaración de Privacidad.

Claro que siempre puede ser “evil” y pasar de la declaración, pero sinceramente, ¿qué tiene de especial uno entre tantos millones de humanos?

Estan equivocados….
saben lo fácil que es logear el tráfico ssl con squid….? es sólo recompilar (30 minutos en hardware moderno).
Es simple, ustedes son bloggers con gagdets, no sysadmin por lo tanto no leen las noticias interpretandolas con lo que trabajan en la vida real.

Estan equivocados….
[…]
ustedes son bloggers con gagdets, no sysadmin por lo tanto no leen las noticias interpretandolas con lo que trabajan en la vida real.

1) No trates a los demás como ignorantes, por mucho que tengas razón.
2) Squid? MITM? SSL? JA! O ciertamente eres un troll, o no tienes ni idea de como funciona todo esto.

Tú no puedes, repito, no puedes obligar a alguien a pasar por tu proxy. Si lo hace, ES TU PROXY EL QUE VISITA LAS PÁGINAS POR EL. Por tanto, puedes saber lo que visita, aunque sea HTTPS. Porque él ha aceptado pasar por ti.

En otras palabras, le estas obligando a renunciar a un derecho básico: el de la privacidad. Cuando espías a alguien, las cosas son distintas, por que el no ha aceptado (no quiere) pasar por ti.

Gobiernos como China se piensan que pueden controlar a sus habitantes, pero ellos mismos saben que no es verdad.

No quiero creer que los requisitos actuales para ser un “sysadmin” hayan bajado tanto. Me resulta menos deprimente suponer que es un troll.
Sólo por si algún visitante se queda con la duda, confirmo: nadie en el medio (tampoco un squid proxy – nadie) puede (sin el consentimiento del usuario) interceptar nada de un request https, ni siquiera el query string de la url.

http://stackoverflow.com/questions/753191/accessing-https-site-through-proxy-server
http://www.comfsm.fm/computing/squid/FAQ-1.html#ss1.12

No sé si lo que Marvin dice sea cierto o no, y realmente no me importa, pero ¿por qué siempre TIENE que ser “troll” el que dice algo que no te gusta? ESO sí es caer bajo.

Marvin, me parece que andas un poco flojo en conceptos de encriptación de clave publica… Haga lo que haga squid (que realmente no lo conozco), la teoria te dice que no vas a poder ver nada que vaya via https (salvo que tengas las claves privadas de Google, en ese caso no solo vas ver lo que vaya por https a google si no que tambien te ganas el premio de hacker del año…), como máximo podes bloquear este protocolo.
En cuanto al sniffing de dns tenes razón, pero tene cuenta que las búsquedas en si NO van a ser sniffeadas (pero el DNS no le compete a google,y ese es el tema en cuestión). Igual esto último se puede llegar a mitigar un poco NO usando los servers dns de tu ISP (openDns por ej, o mejor te creas tu propio server dns; Bind incluso bajo Windows es simple…). Una solución real no conozco (solicitudes y respuestas dns encriptadas?)

Teniendo en cuenta que:

A: estoy hablando de “loguear” el tráfico ssl con squid
B: NO estoy hablando de reemplazar el tráfico ssl (aunque squid use certificados propios en algunos casos).

No sé qué carajos estan diciendo…
Si NO usan squid, no hablen al pedo de suposiciones en base a lo que leyeron en internet ni creen que saben.
Si usan squid, hoy en dia puede hacer como proxy ssl y me consta por las pruebas que he realizado por lo tanto tambien registra en logs todo el tráfico.
Salvo que yo esté soberanamente equivocado y haya compilado mal squid (a la Debian), haya accedido a sitios propios bajo ssl y haya leído mal los logs de squid.
Yo me explayo en base a lo que sé, nada mas.

Squid puede registrar tráfico https porque ya puede funcionar como un proxy para el tráfico https, tan disparato suena lo que estoy diciendo….?

Marvin: Entonces lee la noticia mejor. Cualquiera loguea el trafico, solo tenes que tener un router intermedio y mirar las numeros IPs de los datagramas o directamente capturar los datagramas enteros… eso lo sabe hasta mi vieja. Y, justamente para que esto no viole la privacidad, justamente se invento https, ssl, pgp, etc.
Para loquear trafico no necesitas algo tan especifico como squid; con Ethereal o Wireshark te alcanza y te sobra (y ademas te permite loguear muchísimos otros tráficos no-web, por ej MSN, pop/imap, smtp…)
El tema que explica el autor es que “nadie, excepto ellos claro, pueda saber que estás buscando.” (y porque ellos sí? porque ellos tienen su clave privada… solo ellos)
Vos usa el squid para lo que quieras, pero no vas a poder ver si alguien esta buscando “autos en ventas” o “como construir un arma nuclear”. Ese es el punto.

PD : relee en los manuales a que le llaman “proxy ssl” o pregunta en que es lo que quieren decir esto. Te van a responder “ahora puede funcionar como proxy https y loguear el trafico https… trafico encriptado bajo ssl claro!” (por ej, vas a ir a mirar los logs y vas a ver algo como 100010100010011100111011101… clarisimo che!). Esa feature solo sirve SOPORTAR este protocolo, no para “hackearlo”.

PD 2: si en los logs de squid te aparecian el trafico desencriptado debe ser porque lo configuraste para que sepa cual era la clave privada (o tus sitios estan usando https de manera seria)… si no, es actualmente imposible (salvo que la gente de squid haya descubierto con hackear la criptografía simétrica moderna…). Entra a goggle via https y anda mirar lo logs si no me crees.

el_bot tiene razón.

El protocolo https usa encriptación en una capa encima de http. El primer paso, el handshaking SSL (intercambio de claves, certificados, acuerdo sobre cómo vamos a encriptar) es PREVIO al intercambio http (headers con url) ; hasta ese momento, todo que el browser ha hecho es abrir una simple conexión TCP/IP a una IP que él ha resuelto (pero todavía no ha dicho “quiero la URL https://google.com/). Como segundo paso, se establece el intercambio http (“dame la url…”), SOBRE ese enlace ya encriptado con una clave simétrica que sólo el browser y el server remoto conocen. Alguien en el medio sólo puede saber que el browser estableció una conexión https con la IP tal; nada más.

¿Cómo puede (en teoría y de hecho) un proxy transparente (ej squid) intervenir acá?

De dos maneras:

1) Haciendo un proxy “ciego” de todo el chorro de bytes encriptado (tunneling, usando CONNECT) (con lo cual no puede saber nada de los parámetros http, NI SIQUIERA LA URL). No sirve para cachear ni para espiar NADA.

2) Haciendo un proxy verdadero, como hace con http, “terminando” la conexión https y abriendo otra. Acá habría dos conexiones https: el cliente (el browser) en realidad se está comunicando con el squid, y este con el server verdadero. Acá SÍ podría el squid saber TODO (URL y contenido). PEEEEEROOOOOO : https protege al cliente contra este escenario, no se puede hacer realmente transparente: porque el browser SABE que el certificado que le manda SQUID no es de GOOGLE (ese es el punto de los certificados!!!) y entonces lo rechazará, A MENOS que el usuario de su consentimiento (o que alguien la empresa le haya instalado un browser con un firmante de certificados no confiables añadido).

En resumen: sin el consentimiento del usuario, o sin un browser “tocado”, https es completamente seguro contra ataques en el medio, proxy transparente incluidos: no pueden conocer ni el contenido ni los headers de la comunicación http (por lo tanto, tampoco la URL con su query string, que era el motivo que disparó todo esto).

Aver, sabios, de dónde soy? qué páginas estoy viendo?, qué archivos estoy descargando? jajajaja, y? donde está el conocimiento.. XD XD, y los de abajo dejen de inventar…

Los comentarios están cerrados.