Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: dpreed@reed.com
To: "Maciej Soltysiak" <maciej@soltysiak.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Nokia decrypts user's HTTPS to compress to improve speed
Date: Thu, 10 Jan 2013 16:51:01 -0500 (EST)	[thread overview]
Message-ID: <1357854661.301326601@apps.rackspace.com> (raw)
In-Reply-To: <CAMZR1YBVb4BNgfYeZnwJBFXedp8ZMYuq6UCpQVga9WRTjEnsSQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]


Where is the data decompressed again?  That's a vulnerable point, too.  It's where I would attack - a much more "target rich environment" to make money, because you see *everybody's* data in the clear there.
 
In other words, the vulnerability is not just "in the phone" but systemic.
 
Creating a concentrated vultnerability, with uncertain protection - in the US, this would also violate HIPAA compliance, which is a *very* serious law, with very severe monetary and felony criminal consequences for anyone who systematically opens up encrypted personal health-related data.  One violation by Nokia technology would be enough to trigger the HIPAA stuff, if intentional.
 
 
-----Original Message-----
From: "Maciej Soltysiak" <maciej@soltysiak.com>
Sent: Thursday, January 10, 2013 11:50am
To: dpreed@reed.com
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Nokia decrypts user's HTTPS to compress to improve speed



On Thu, Jan 10, 2013 at 3:58 PM, <[mailto:dpreed@reed.com] dpreed@reed.com> wrote:

I'm curious if they have data about how much compression they are achieving?  Most HTTPS servers are set up by people who use quite a bit of compression in the payload (gzip of web pages, etc, "minification" of javascript), so I would hypothesize that the actual savings are minimal on the average.
My finger in the air suggests that it is no more than 30% on average. Is it worth it? If it's up to 1/3 of more media time available for other stations to send data, perhaps it is.

However, it points out that there is a man-in-the-middle problem with HTTPS alone.  Your phone's browser should be checking the certificates more rigorously than it does.  It can do that quite easily, and I think the destination can do that in Javascript that comes with the pages.
Hmm, wouldn't something like HTTPS Everywhere + SSL Observatory help here? It should detect the certs are different than what they've been seen by other users.

"We don't look" is not a defense in the EU privacy regime, and probably not in the US one (though many US Senators think that ISP's looking at content is just fine).
You are right. There's a different angle than privacy here too. A one that users should be able to understand better. Such a phone might also be a security threat. Maybe Nokia don't do anyting with except compression, but malicious code knowing this might steer the compromised browser+dodgy_cert+phone to rob you of money in your bank.



Maciej



---Original Message-----
From: "Maciej Soltysiak" <[mailto:maciej@soltysiak.com] maciej@soltysiak.com>
 Sent: Thursday, January 10, 2013 9:46am
To: [mailto:cerowrt-devel@lists.bufferbloat.net] cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] Nokia decrypts user's HTTPS to compress to improve speed



[http://yro.slashdot.org/story/13/01/10/1356228/nokia-admits-decrypting-user-data-claiming-it-isnt-looking] http://yro.slashdot.org/story/13/01/10/1356228/nokia-admits-decrypting-user-data-claiming-it-isnt-looking
Have a look at what corporations resort to when they're in need of serious debloating and things like TCP Fast Open? :-|
Regards,
Maciej

[-- Attachment #2: Type: text/html, Size: 5075 bytes --]

      reply	other threads:[~2013-01-10 21:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 14:46 Maciej Soltysiak
2013-01-10 14:58 ` dpreed
2013-01-10 15:44   ` Michael Richardson
2013-01-10 16:50   ` Maciej Soltysiak
2013-01-10 21:51     ` dpreed [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1357854661.301326601@apps.rackspace.com \
    --to=dpreed@reed.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=maciej@soltysiak.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox