[clug] OT: Protesting the proposed clean feed?

[Michael Cohen]

On Thu, Oct 23, 2008 at 10:48 PM, Nathan Rickerby <rickerby at gmail.com> wrote:
> But what if the ISP was to MitM my connection.  How can they verify
> the certificate?  It's not signed by a CA they trust, I can do a much
> better job of verifying the certificate than they can.  How do I control
> who the ISP trusts?

Thats a very good point which many people seem to miss (not on this
thread though!!!). The _best_ PKI you can have is one which _you_ own
and control the CA. Thats why openvpn (a tls/ssl vpn) recommends that
you should create your own CA to sign your own certificates. Verisgn
and other commercial CAs want to tell you that you should buy a cert
to be more secure. This is simply not true in general - its more
convenient granted, but not more secure. As was mentioned previously
if someone pays MS or Mozilla enough they can get their CA in the
trusted CA store. SSL in browsers was designed as an all or nothing
mechanism - _any_ CA in the trust store can verify _any_ certificate.
You only need one CA cert to be compromised for all certs to be
forgeable. The most secure setup is to remove all root CA's from your
trust store and only put in those ones you really trust (or your own
CA if you trust that more).  The way the SSL Mitm inspection proxy
that was mentioned previously in this thread works is that their CA is
added to the trust store (via the desktop SOE) and it generates certs
on the fly for all connections. In fact in such a setup you can remove
_all_ CAs from the trust store and only have the proxy CA because
thats the only one used.

This might work in a corporation which has a regimented security
policy but obviously will not work in the ISP space. ISPs are
currently classed as carriers which technically means their job is to
move bits from A to B. Like the postman moving packages from address
to address, they dont care whats in the packages. Do you consider
Australia post's job to look inside letters to see if they are
"appropriate" before delivering them? We have mail protection laws for
that very reason (illegal to open mail not addressed to you).

ISP inspection is no different - inspection will breach similar
privacy legislation. We also have telecommunication intercept act
which will need to amended to actually allow this kind of global
filtering (simply because the proxy logs are a form of interception)
and clearly SSL Mitm is also interception. Clearly there is no
commercial impetus to implement filtering because it raises admin
costs, and increases helpdesk support, slows the network and generally
is not what the customers want (as i mentioned before most customers
do actually want pr0n). So ISP will resist greatly to any such
legislation.

IMHO there is a really long road of legislative changes before this
can be enforced on ISPs. I maintain that this push is at best an ill
conceived publicity stunt and seriously doubt it can get much traction
- certainly not once it gets law makers actually involved.  Right now
its nothing more than a glimmer in the minister's eye - before they
enact anything into law it will need to go through the appropriate
legal scrutiny and its going to be struck down at that stage because
of all the big laws that will require amendment (e.g. privacy and
telecom intercept). At which point it will be cast into the too hard
basket. Its just a shame that tax payers will spend quite a bit on
trials, policy papers and pointless publicity. OTOH with the current
economic crisis it may not be so bad for the govt to waste money
"invigorating the economy".

Michael.

>
> The ISP can generate a certificate with the correct CN, have it signed
> on the fly by a CA that browsers have been coerced into trusting, there
> will be no error message but the keys still won't match.
>
> You can imagine solutions where the ISP presents an advertisement littered
> page saying here are the credentials for the server I just connected to
> for you, click here if they're okay or disconnect.  It's awful, but maybe
> it would be okay... for a web browser.  What about my tls vpn application
> that's expecting to start some other protocol over the tls tunnel but
> now the ISP is trying to talk http to it.  That's just not going to work
> well at all.
>
> Another solution might be that you can configure via some other web based
> system what CAs and certificates you trust for your internet connection.
> Or we could invent a whole new protocol for projecting who you trust
> to your ISP (maybe that already exists).  This is all a very bad idea
> and it's trying to undo what this stuff was fundamentally designed to
> do.  You always wind up having to trust the security of your ISP and
> that they'll do the right thing.
>
> Nathan
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>