[cryptography] yet another certificate MITM attack

Jeffrey Walton noloader at gmail.com
Fri Jan 11 13:53:27 EST 2013


On Fri, Jan 11, 2013 at 1:39 PM, Adam Back <adam at cypherspace.org> 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
>> <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