[kwlug-disc] "In the new Canada, the web browses you"

Sun Aug 14 11:24:47 EDT 2011

By the logic that some countries use for fighting against the use of
encryption.  I'm starting to wonder how long that it will be before having a
one on one conversation in a closed door room is illegal.

I've heard that RIM only gave the encryption keys for their BIS not their
BES as the countries involved in the investigations would have to subpoena
the corporation running the BES for that information so basically from what
I've been informed the blackberry security hasn't been compromised within
your BES anyways.  So theoretically if you wished you could have your own
micro darknet with the free version of Blackberry Enterprise Server if you
so desired still and the gov't would still need to speak with your admin
personally to aquire that encryption key.

I read somewhere that Google's Gmail fully encrypts your emails in transit
as long as it stays within the gmail system by default without you having a
choice.  Just food for thought.  I realize that a MITM attack between Gmail
servers and you is a major risk at this point.  But it is again food for
thought so basically if we can convince google that its profitable to give
us a free vpn service to their servers than were good there :P.

Anyways I feel like i'm trolling with this response so i'll stop.

On Sun, Aug 14, 2011 at 2:44 AM, unsolicited <unsolicited at swiz.ca> wrote:

> There are a number of answers to that - some are:
>
> Recognizing that:
> - not( everybody will be satisfied with all things)
> - new users will be most at risk, not having gained a sense of when things
> don't feel right.
>
> - You can't actually trust anything now, nothing coming will change that.
> - Most browsing is read only.
> - Frequently you must make arrangements in some other manner to gain
> access, including the provisioning of a password. When that password doesn't
> work, spidey senses should go off.
> - E-mail confirmations received, or not, granting access to the site.
> (- Theoretically, initially entering credentials to bogus sites won't
> achieve the desired effect. Signing into your [bogus] bank for the first
> time didn't actually transfer money between your accounts.)
> - Most of the people most of the time will be all right.
>  - I suspect this doesn't change from current circumstances. There
> currently aren't any guarantees, anyways. Witness Chris' earlier reminder
> that not all CA's have proven to be trustworthy.
> - Did you see my post on your facebook wall? No. Spidey senses go off.
> - I suspect if enough things get botched, enough people will raise a stink,
> and nefarious behaviour will be somewhat moderated. I'm not holding my
> breath. Witness the migration from UBB ISP's elsewhere - not saying that's
> speedy, but I expect it's happening faster this year than 2 years ago.
> - Whatever it is we're doing now, feel safe with, won't change much beyond
> what we're doing now. Just because I'm paranoid, doesn't mean I'm wrong.
> - We don't know that we're not being sniffed, now.
> - It doesn't matter if we're sniffed, it only matters what they do with it?
> - Necessity is the mother of invention - detections and workarounds will
> emerge.
> - If the perceived benefit is greater than the experienced risk, people
> will go ahead anyways. You rolls the dice, you takes your chances / You can
> pay now, or later, your choice?
>
>
> Bob Jonkman wrote, On 08/14/2011 2:12 AM:
>
>  Largely, we only care that the traffic of this conversation not be
>>> sniffable by the ISP. Getting into the, are we really on the site it says it
>>> is, is a whole 'nuther thread.
>>>
>>
>> OK, but if we can't verify that we're really on the site it says it is,
>> how do we know we're not secretly on the ISP's site, who's now sniffing all
>> our traffic?
>>
>> --Bob.
>>
>> On Sat 13 Aug 2011 04:30:39 PM EDT  unsolicited wrote:
>>
>>>
>>>
>>> Chris Irwin wrote, On 08/13/2011 2:31 PM:
>>>
>>>> On Fri, Aug 12, 2011 at 06:30:27PM -0400, unsolicited wrote:
>>>>
>>>>> Mind you ... you're right ... with ssl (https) ... isn't listening
>>>>> in at the ISP all but pointless?
>>>>>
>>>>
>>>> Not really. Most of the difficulty of executing a man-in-the-middle
>>>> attack is getting in the middle, a non-issue for your ISP.
>>>>
>>>
>>> OK, fair enough, I wasn't considering MITM, but I saw nothing in the
>>> articles discussing that. OTOH, I do wonder if we haven't just stepped into
>>> a form of digital lock breaking, which then becomes state sponsorship of it.
>>> Truth stranger than fiction, again.
>>>
>>>  There was a presentation a BlackHat 2009 using a MITM attack to rewrite
>>>> 'https://..." urls to "http://..." urls, ...
>>>>
>>>
>>> I remember that discussion coming up in the (our) lug.
>>>
>>>  Even if you trusted every certificate vendor in your browser (or removed
>>>> those you don't), can you trust their infrastructure?
>>>>
>>>>    CA hacked to provide fraudulent certificates.
>>>>    https://www.eff.org/deeplinks/**2011/03/iranian-hackers-**
>>>> obtain-fraudulent-https<https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https>
>>>>
>>>
>>> OK, but, for the purposes of this thread, we largely don't care.
>>>
>>> Largely, we only care that the traffic of this conversation not be
>>> sniffable by the ISP. Getting into the, are we really on the site it says it
>>> is, is a whole 'nuther thread.
>>>
>>> And ... how many of us have turned off the browser warnings about mixed
>>> un/encrypted pages. So, again, we're not paying as much attention as we
>>> probably should that the site really is the site, and the signer itself is
>>> trustable. Score another for marketing and VeriSign, I suppose. (I wonder
>>> how much budget they put towards just maintaining their credibility, proper
>>> use of logos on sites, etc.)
>>>
>>>
>>>  Thinking of the English riots, talk of BlackBerry sniffing whatever
>>>>> ... just having a sense of the preponderance of data going
>>>>> somewhere, like a facebook site, and the ability to get to that site
>>>>> directly oneself, seems sufficient. No need to crack the data
>>>>> itself, just, where it's going. And if you see bad stuff (facebook),
>>>>> then you're listening for what's headed that way.
>>>>>
>>>>
>>>> Anybody remember when Blackberry told (I believe) India and UAE that it
>>>> was absolutely impossible to allow snooping on blackberry traffic, and
>>>> there was a possible risk of blackberries being blacklisted in the country
>>>> due to that? Now they are willing to co-operate fully. Hmm.
>>>>
>>>
>>> Right, but my expectation was that RIM would open up the ability to plain
>>> text see the traffic at the BES point. In very specific circumstances. Is
>>> that how it went down?
>>>
>>> Given the Google / China experience, I don't expect RIM had much choice,
>>> shareholder wise.
>>>
>>> I will wonder, however, if that episode will lead to the eventual demise
>>> of the BB. In essence, they showed their security is not absolute in all
>>> cases, and with SSL end to end on PDA's (I presume) showing that alternate
>>> security strategies take you to the same place, the BB competitive advantage
>>> isn't as strong as it was - making i<thing> / Android viable choices even on
>>> the security front.
>>>
>>> Anyways, the debate point here, for England / riots is ... slippery
>>> slope.
>>>
>>> ______________________________**_________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org
>>> http://kwlug.org/mailman/**listinfo/kwlug-disc_kwlug.org<http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>>
>>
>> ______________________________**_________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/**listinfo/kwlug-disc_kwlug.org<http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>
>>
> ______________________________**_________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/**listinfo/kwlug-disc_kwlug.org<http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20110814/5f9a2f6d/attachment.htm>