[cryptography] yet another certificate MITM attack

Adam Back adam at cypherspace.org
Fri Jan 11 13:39:08 EST 2013


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

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).

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.

Adam

On Fri, Jan 11, 2013 at 10:04:42AM -0500, Jeffrey Walton wrote:
>On Thu, Jan 10, 2013 at 7:47 PM, Peter Gutmann
><pgut001 at cs.auckland.ac.nz> wrote:
>> Jon Callas <jon at 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).



More information about the cryptography mailing list