[cryptography] yet another certificate MITM attack
noloader at gmail.com
Sat Jan 12 16:37:47 EST 2013
On Sat, Jan 12, 2013 at 2:35 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> Relevant to this thread, but OT to the charter of this list.
> On Sat, Jan 12, 2013 at 5:46 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>> On Sat, Jan 12, 2013 at 4:27 AM, ianG <iang at iang.org> wrote:
>>> On 11/01/13 02:59 AM, Jon Callas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>> Others have said pretty much the same in this thread; this isn't an MITM
>>>> attack, it's a proxy browsing service.
>>>> There are a number of "optimized" browsers around. Opera Mini/Mobile,
>>>> Amazon Silk for the Kindle Fire, and likely others. Lots of old "WAP"
>>>> proxies did pretty much the same thing. The Nokia one is essentially Opera.
>>>> These optimized browsers take your URL, process it on their server and
>>>> then send you back an "optimized" page.
>>> Oh, I see. So basically they are breaking the implied promise of the https
>>> component of the URL.
>>> In words, if one sticks https at the front of the URL, we are instructing
>>> the browser as our agent to connect securely with the server using SSL, and
>>> to check the certs are in sync.
>>> The browser is deciding it has a better idea, and is redirecting that URL to
>>> a cloud server somewhere.
>>> (I'm still just trying to understand the model. Yes, I'm surprised, I had
>>> never previously heard of this.)
>> It's right up there with the PenTesters using BurpSuite to to destroy
>> a secure channel. I look at the PenTest reports and shake my head in
>> disbelief that no one took exception to what the PenTesters did....
> Whoa...hold on there Jeff. I'm hoping that I'm misunderstanding your
> last statement about what the pen testers did to "destroy a secure
> Are you implying that _authorized_ PenTesters using software such as
> BurpSuite (or Fiddler2 or Paros Proxy, or any other software that
> leverages the browser's _forward_ proxy ability is violation of some
> law or morals? If so, I would wholeheartedly disagree. They are not
> capturing arbitrary HTTPS traffic of others, but only that originating
> from their
In this case, the user trusted the certificate and took control of
infrastructure. The result: the developer possibly absorbed a
Note: there was no Jailbreak required, no re-engineering of the IPA
required, and no low-level debugging required. The user trusted a
proxy certificate and gave bad DNS answers through a server under
his/her control. That was it.
Do you think the developer thought Apple's StoreKit API was secure?
After all, Apple supplied the library. Do you think he cares why,
since it was supposed to be secure?
BTW, Apple did not fix the failure with technical controls such as
public key pinning. Taking advantage of the pre-existing relation
between the develop and Apple (using 'a priori' knowledge) must have
been too secure (?).
Instead, Apple gave the developers instructions on how to verify a
purchase (i.e., implement this bit of PKI); and they sent their
lawyers to do a takedown. Double fail.
More information about the cryptography