[cryptography] yet another certificate MITM attack

Warren Kumari warren at kumari.net
Sun Jan 13 13:20:37 EST 2013


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

I think that you had, just it was presented differently -- to my mind this is kinda similar to running a browser on an X11 server (or any sort of thin client, or Lynx over SSH, etc).  By using a browser that does this you are asking some better connected (or better resourced) device to be your "agent" and do work on your behalf -- if you don't want some other machine, run by some other folk to be your agent[0] simply don't use these types of browsers.

To my mind the crappy part is not the fact that this exists, but rather that the vendors didn't make this clearer.

The Amazon FAQ for Silk did at least say:
"We will establish a secure connection from the cloud to the site owner on your behalf for page requests of sites using SSL (e.g. https://siteaddress.com). Amazon Silk will facilitate a direct connection between your device and that site. Any security provided by these particular sites to their users would still exist."
while they were doing this.

There was some flap, grumpiness about this, see for example: http://www.zdnet.com/blog/networking/amazons-kindle-fire-silk-browser-has-serious-security-concerns/1516


W
[0]: I sure as hell don't...


> 
> 
>> That can be converted pictures, edits to the HTML proper, and so on.
>> 
>> The security characteristics are a mixed bag. They can send smaller pictures, scan for malware, but obviously they can't process your SSL connections. So they send the URL to the cloud server, make the SSL connection, and then send you the optimized page over SSL.
> 
> One could interpret the browser as being a combined service between the client on the phone, and the cloud support services, sure.
> 
> I think this interpretation would be unusual to any ordinary user.  At a contractual level, it would also need to be agreed by both ends.  We can easily ensure the end-users' agreement by means of the phone agreement, but it is less easy to imply the banks' agreement.
> 
> And, if a security case were to result in a bank being held for damages, it could easily expand to Nokia.  Given the complexity of modern day online banking sites (that's a kind description) I can't see how they could be agile enough to avoid making mistakes.
> 
> 
>> Some of these browsers let you turn off the "optimizations" for SSL pages. The Amazon Silk browser does.
>> 
>> You can find information about Opera at:
>> 
>> <http://www.opera.com/mobile/specs/>
>> 
>> Here's articles with various concerns about Silk:
>> 
>> <http://www.zdnet.com/blog/networking/amazons-kindle-fire-silk-browser-has-serious-security-concerns/1516>
>> 
>> <http://www.theinquirer.net/inquirer/news/2203964/amazon-confirms-kindle-fires-silk-browser-tracks-users>
>> 
>> They're not doing certificate hinkiness. They are straightforward cloud services, or perhaps more formally proxy services. Heck, Google Reader is more or less the same thing, itself, albeit as an RSS reader than a web browser.
> 
> ok.
> 
> 
>> If one wants to get upset about them, there's plenty to grumble over. There's the explicit security concerns, concerns about tracking, concerns about misrepresentation to the users about what's really going on, and so on. The meta concern that smart people like us are even discussing it is also a security concern.
>> 
>> But they provide services that some people find valuable. I don't use them, but I wouldn't even call them a MITM, myself. When we say "MITM" we're eliding the word "attack." It's not an attack.
> 
> 
> Yes, ok, it's not an attack if there isn't an attacker.  Or more generally, is it an attack when the attack is done by self?  "We have met the enemy, and he is us."
> 
> So more properly, it might be a breach-of-contract issue, where the contract to provide a browser that does the 'right thing' has been breached (in the view of the outraged).
> 
> Nokia will argue that their contract is clearly expressed, they can do this and they claim so in their contract.  OK.
> 
> Question remains -- what to make of a vendor that does tricksy things with the implied secure browsing contract?
> 
> If Nokia can do this, can the other vendors?  Why can't Firefox and Chrome start clouding the https connection?
> 
> 
> 
> iang
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
> 

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.





More information about the cryptography mailing list