[kwlug-disc] "In the new Canada, the web browses you"
unsolicited
unsolicited at swiz.ca
Sun Aug 14 02:44:42 EDT 2011
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
>>>
>>
>> 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
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
More information about the kwlug-disc
mailing list