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 --]
prev parent 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