Alright, let´s stop assuming things then. Anyhow, congrats for the great work. Nice chat, btw.
Att, Pablo Ximenes 2011/12/7 Dan Rosenberg <dan.j.rosenb...@gmail.com> > On Wed, Dec 7, 2011 at 10:02 AM, Pablo Ximenes <pa...@ximen.es> wrote: > > Hi, > > > > 2011/12/7 Dan Rosenberg <dan.j.rosenb...@gmail.com> > >> > >> On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes <pa...@ximen.es> wrote: > >> > >> > >> > >> That's a good question. As you've mentioned, the URL falls within the > >> HTTP request, the entirety of which is protected by SSL. So I would > >> argue that the URL is content that should remain secret in an SSL > >> session. I haven't made up my mind whether the same applies to > >> non-HTTPS URLs. The issue is further complicated by the fact that > >> perhaps the domain (without query parameters) that's being requested > >> shouldn't be considered secret since this is readily available by > >> looking at DNS. > >> > > > > Well, let´s take a look at a simple HTTP request: > > > > POST /login.php HTTP/1.1 > > Host: www.example.com > > User-Agent: Mozilla/5.0 (Windows;pt-BR; rv:1.8.0.11) Gecko/20070312 > > Firefox/1.5.0.11 > > Accept: text/xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > > Accept-Language: en-gb,en;q=0.5 > > Accept-Encoding: gzip,deflate > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > Keep-Alive: 300 > > Connection: keep-alive > > Referer: http://www.example.com/ > > Content-Type: application/x-www-form-urlencoded > > Content-Length: 22 > > > > username=jdoe&pass=god > > > > > > > > In this case, the URL being visited is http://www.example.com/login.php > > > > In order to capture this URL, the eavesdropping software would have to > open > > up the contents of the HTTP payload, get information from the method line > > (1st line, POST), then get information from the "Host:" line, Merge them > > together and then assemble the original URL. Bottom line is that the > > eavesdropping software has to look at the contents in order to assemble > this > > seemingly "header" information. I would say this info is content and not > > header, even for non-HTTPS requests, don´t you think? > > > > Even though DNS leaks some info, as you mentioned it´s never the full > URL. > > Also, there´s the DNS cache, URL domain names get resolved once in a > while, > > and chache is used quite often. > > > > And that´s only for URLs, I wonder how deep they would have to digg into > > HTTP payloads in order to get other metrics that they might be > collecting. > > As you already said the samgung model has direct indication of > collection of > > "Request type" (GET, POST, etc), "content length" (port of the request´s > > payload), and "status code" (part of the reply´s payload!), all of which > > would need deep inspection of HTTP payload request contents as I > mentioned. > > > > This is more of a semantic argument of what is meant by "content" and > "header". At the application layer, the URL is considered a header. > At the transport or network layer, the entire HTTP payload is > considered content. I don't know how the law interprets this. > > Regardless, you're correct that they are "digging into" HTTP payloads > to get this information: their instrumentation is in Webkit, where > they have easy access to this information. They never touch POST > parameters or response bodies, but they do collect the information I > described. > > > > >> > >> Please note that I'm not a lawyer, so I don't know the wording of any > >> laws related to this sort of thing. Also remember that it remains to > >> be seen whether URL data is/was being collected at all, which is > >> obviously a key piece of information with regards to the legal issues > >> at hand. > >> > > > > Assuming those metrics were intended mostly for debugging purposes, It > is a > > fair assumption that they were indeed colleting this info, since it´s > very a > > important piece of data for debugging their data network in terms of > > application level. > > > > I don't think either of us in a position to make a guess here. The > profiles I looked at included almost exclusively radio and telephony > related data and did not include URLs. Other profiles might include > application data like this. So, like I said, it's definitely possible > that URLs were being collected, but neither of us actually knows for > sure, and I'd prefer to not make any assumptions one way or the other. > > -Dan > > >> -Dan > >> > >> > > > > > > Att, > > > > Pablo Ximes > > > >> > >> > > >> >> Regards, > >> >> Dan > >> >> > >> > > >> > > >> > Regards, > >> > > >> > Pablo Ximenes > >> > > >> >> > >> >> > > >> >> > Regards, > >> >> > > >> >> > Pablo Ximenes > >> >> > > >> >> > 2011/12/6 Christian Sciberras <uuf6...@gmail.com> > >> >> >> > >> >> >> Or not... > >> >> >> > >> >> >> http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/ > >> >> >> > >> >> >> On the other hand, where that l33t hacker Drew (aka xD 0x41)? > >> >> >> Thought he'd enlighten us with more of his awesome hacking powers > on > >> >> >> this > >> >> >> issue. > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Full-Disclosure - We believe in it. > >> >> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html > >> >> >> Hosted and sponsored by Secunia - http://secunia.com/ > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Full-Disclosure - We believe in it. > >> >> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > >> >> > Hosted and sponsored by Secunia - http://secunia.com/ > >> > > >> > > > > > >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/