[clug] OT: Protesting the proposed clean feed?

Nathan Rickerby rickerby at gmail.com
Wed Oct 22 22:25:48 GMT 2008

Perhaps if there's still no talk scheduled for tonight, a few people
could get together and discuss the Clean Feed issues, it's clearly a
popular topic.  The outcomes could be distilled, simplified and described
in non-technical language, some open source solutions could be proposed.
That could then be sent onto the list in point form so each of us could
glue the points together in letters to our representatives.  (I can't
offer to coordinate this sorry as I'll be late or not there at all
tonight - slack, I know)

On Thu, Oct 23, 2008 at 01:13:40AM +1100, Sunnz wrote:
> By the way from what I have read, the proposal is to filter https as
> well as http.

Do you have any references that mention https?

> As you may know https's designed specifically not to be intercepted,
> so my guess is that they would force people to use their https proxy,
> or transparently intercept the connection anyway and let the user
> click the ignore button... which the ignore function have been made
> more scare factor in FireFox 3.

Even when using a https via a proxy, you still get a tls connection to
the other end, it's just that your tcp connection ends at the proxy, you
CONNECT and a new one is established from the other side to the end point.

The only difference between the above situation and transparently
intercepting a direct connection is that the interception doesn't have
to be on-route to the destination.

I suspect if they're going to do anything at the ISP level about https,
in practice it would have to be a whitelist or blacklist solution.

There are some big issues if they do intercept and man-in-the-middle
encrypted connections.  For starters they'll need a fair bit more cpu
[1].  To be effective they have to do it to everything that's encrypted.
There would be a lot of objections from banks, corporations using vpns,
government agencies with online services and many more groups that do
have well paid lobbyists.

Some organisations do a combination of whitelisting and interception.
Banks and the like might be whitelisted while anything not on the
whitelist is man-in-the-middled.  The appropriate certificates can be
deployed within the network and users can be educated about what's going
on.  I don't know how this would work on a wider scale.

> What about foreigners coming Australia for business, we will be
> forcing them to trust our government to intercept their secure
> connection?

If an ISP level intercepting/decrypting scheme was put in place then
any sane vpn client would refuse to connect because it wouldn't get the
correct certificate.  There would also be corporate policy (and the
required technical restrictions) that no one was to use anything https
to connect to the corporate services from Australia.

A significant technical point for me in this whole thing is that
intercepting and decrypting one type of encrypted protocol would
be ineffective.  If they did it to one thing, the others would become
popular.  If they did it to https then an industry of vpn service providers
would pop up overnight, there would even be free ones that only allow
you access to certain otherwise-blocked sites.  It would be brought to
the masses in the same way p2p apps brought file sharing to the masses.
If they try and do it to every encrypted protocol... well, there's no
point talking about that because it just won't work and if they did then
we'd just make a new way to do it.


1.  Doesn't this open up an opportunity for a virus to DOS the filtering
hardware by initiating connections to many different https websites,
forcing the filtering hardware to do lots of expensive tls/ssl initiations
(two for the price of one).

Also, I don't really agree with the kids and contraceptives analogy.
The way I see it, it's more like the government saying  "lets stop the
children hearing swear words by implanting magical hearing aids."

More information about the linux mailing list