On Fri, Jan 11, 2013 at 10:04 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Thu, Jan 10, 2013 at 7:47 PM, Peter Gutmann > <pgut...@cs.auckland.ac.nz> wrote: >> Jon Callas <j...@callas.org> writes: >> >>>Others have said pretty much the same in this thread; this isn't an MITM >>>attack, it's a proxy browsing service. >> >> Exactly. Cellular providers have been doing this for ages, it's hardly news. >> >> (Well, OK, given how surprised people seem to be, perhaps it should be news >> in >> order to make it more widely known :-). > Its not so much surprise as it is frustration (for me). > > My secure coding guides include something similar to: > * Do not send sensitive information, such as usernames > and passwords, through query parameters (GET) > * Use HTTPS, send using POST > > How do web applications pin their certificates when the language > (HTML) and the platform (Browser) do not offer the functionality? > > How do the proxies determine which HTTPS traffic is benign, "public > information" vs sensitive, "private information"? > > How do carriers know when its OK to log benign, "public information" > vs sensitive, "private information"? > > How do carriers differentiate the benign, "public information" data > from the sensitive, "private information" before selling it to firms > like GIGYA? > > How do we teach developers to differentiate between the good > "men-in-the-middle" vs the bad "man-in-the-middle"? > > Until we can clearly answer those questions, I will call a pot and > kettle black. Interception is interception, and its Man-in-the-Middle. > Period. > > From my [uneducated] data security point of view, it is best to stop > the practices. HTTPS is the cue to stop the standard operating > procedures on consumer information because the information is (or > could be) sensitive. All I care about is the user and the data (as a > person who endures life after a data breach).
This came on off-list: > IMNSHO, if Nokia didn't inform their customers that they were doing > this--especially for HTTPS traffic--in their TOS, then it might as well be a > MITM. At least in the US, people still have a reasonable expectation of > privacy (in a legal sense at least). There are at least two endpoints in a secure channel. Did they inform the other endpoint, too? Perhaps they should be using the evil bit in the TCP/IP header to indicate someone (or entity) is tampering with the secure channel? https://tools.ietf.org/html/rfc3514. Jeff _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
