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

Chris Irwin chris at chrisirwin.ca
Sat Aug 13 14:31:16 EDT 2011


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.

There was a presentation a BlackHat 2009 using a MITM attack to rewrite
'https://..." urls to "http://..." urls, then as users navigate around
the site, the attack could act as a proxy and snoop on your plaintext
communication, while relaying it to the server in HTTPS (so the server
doesn't see anything odd). This is based on the assumption that that 
most users don't specifically type 'https' and merely follow a link to 
it. This is a simple attack to bypass SSL.

So you're okay because you always manually type 'https', righ? But now
it has become an issue of trust.

Your browser says "This is really https://facebook.com because the
certificate says it is, and the certificate is signed by DigiCert, whom
I trust" But do you trust Digicert to have verified this is really 
facebook.com for whom they signed the certificate for, and not
bobs-net-monitor.com? Note that I only know that the signer was 
Digicert by manually checking. Note that the US DHS has the ability to 
sign certificates without prompting a warning (not to mention 650 
other organizations).

    EFF warning about bad cert signers
    http://www.networkworld.com/community/blog/eff-warns-untrustworthy-ssl-undetectable-surv

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

So if you take the position of not trusting signing authorities, how
can we still use SSL securely? There are a few firefox extensions to try
and solve various issues.

    'Certificate Patrol' warns you when SSL certs change, so you can
    verify it was proper to (manual verification). Only catches SSL
    switcheroo if you've actually ever seen the real cert before, since
    it verifies against a local cache.
    https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

    'Perspectives' takes a different approach. There are distributed
    notaries, and you decide which ones you trust. It then verifies SSL
    certificates by contacting those, and ensuring you have the same
    cert they got, with a (configurable) minimum 75% consensus.
    http://perspectives-project.org/

The 'perspectives' approach is pretty decent, and it will also verify
self-signed certificates (which is probably what most of us use
privately) assuming all the notaries see the same self-signed cert. By
default, you need to trust perspectives' eight notaries, but that is not
required. The notary server is GPLv2, so you can run your own in some
other location (VPS in another country) if you'd like.

    https://gitorious.org/perspectives-notary-server

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

-- 
Chris Irwin
e:  chris at chrisirwin.ca
w: http://chrisirwin.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20110813/b9823f6b/attachment.bin>


More information about the kwlug-disc mailing list