On Fri, Jan 11, 2013 at 1:39 PM, Adam Back <[email protected]> wrote: > For http there is a mechanism for cache security as this is an issue that > does come up (you do not want to cache security information or responses > with security information in them, eg cookies or information related to one > user and then have the proxy cache accidentally send that to a different > user. This has to work generically also because some proxies are > transparent. > > Cache-Control: private Devil's advocate: citation please in the SSL/TLS context. Here's I'm pleading to the case of a Web Service over port 80 or 443 using SSL/TLS, and not an HTTP request in general.
> would instruct a cache not to cache a response because "the response message > is intended for a single user and MUST NOT be cached by a shared cache" (rfc > 2616). What are our assurances that the request is being honored? Right now, there are none and it's "catch me if you can" business-as-usual in corporate america. > However I would like you take the fact that it is HTTPS to mean blanket the > proxy MUST NOT attempt to MITM connection, as the encryption is designed to > be end-to-end secure. The browser on the phone must have also been tampered > with to incorrectly display a security indicator which is false (the traffic > is not end to end secure). This is similarly bad to the old WAP gap and > there is no excuse. Shame on Nokia. Suppose a carrier or handset manufacturer pre-loaded a certificate just for the purpose of subverting end-to-end security? That appears to be the case here. The trusted certificate was "just installed", without any auditing (for example, what a CA might have to go through). One of the things I find most befuddling: the industry has conditioned many folks to accept this sort of thing as "normal" (Proxy/Interception on a "secure' channel"), even when those same folks know better. Its seems to be a repeat of browsers conditioning users. Jeff > On Fri, Jan 11, 2013 at 10:04:42AM -0500, Jeffrey Walton wrote: >> >> On Thu, Jan 10, 2013 at 7:47 PM, Peter Gutmann >> <[email protected]> wrote: >>> >>> Jon Callas <[email protected]> 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). _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
