https anonymous proxies

[DaveJ2717uk]

Anyone know a way to successfully kill https proxy sites with isa 2006, I can put them in the deny domains, I put every variation I can think of in the deny urls and they go away. They then start working again a couple of days later:mad: At least the https addresses will, it's bugging the hell out of me. any help graciously accepted:) I've even put the domain into our sonicwall box content filter but the https addresses bypass that aswell:mad:

[ZeroHour]

tbh the only real fix I can think of is to use a whitelist of allowed https sites and block the rest. Thats how we cured it here and even then we have a separate list of url's for staff and pupils in ISA. Smoothwall has some https scanning stuff but since we dont allow it here anyway I have not looked into it. No doubt Tom/others will elaborate.

[tom_newton]

Ooh, elaboration time... what fun

 

HTTPS traffic is end-to-end encrypted. When any eavesdropper (ISA included) sees it, it is nothing but "garbage". Generally we can recognise it by the port it lives on (443).

 

If we are doing transparent filtering there's not a lot you can do about this (though we are working on some hacks here at SmoothWall to try and improve that situation).

 

If you are doing non-transparent, then when the browser wants to make its end-to-end encrypted tunnel, it has to ask the proxy for permission. This comes in the form of a connect request. This allows us to see the domain only. We can easily block and allow these requests. SmoothWall has been doing this for ages, and ISA must be able to too?!

The thing to remember is *domain* only - no URL (so nothing after the /).

With this method you will find yourself doing the "proxy chase" - forever reactively blocking new domains, same as non-https. This applies if you are a single admin, or if you are a top-5 web filter company (you guys know who you are). You can, of course, go for the "whitelist only HTTPS" solution - my friend Stewart at Malvern college (who i believe still only lurks here... ) has been doing this for (literally) many years, before a lot of people had even heard of HTTPS proxies. If you don't mind generating parts of the whitelist yourself, and your solution supports it, this is not a bad method.

 

The second stage in proxy finding is to do a cert check. Most proxy operators have invalid or self-signed SSL certificates, because valid ones cost money. 90% of proxies are a money making venture, and CA fees would hit the bottom line. For this reason, a cert check will give good effectiveness against a range of proxies. This does overblock when the odd bank or govt. department can't get their act together (you lads know who you are as well HSBC forgets to renew its digital certificate ? The Register) but generally, pretty benign. SmoothWall have been doing this for a while. We enjoy it.

 

Finally... there's the full gun - Man In The Middle interception. This uses your proxy to turn 1 SSL session into 2 - with a small gap in between so you can examine the URL and page content. This is VERY powerful. Scary in places. A number of vendors do this - but look for ones who don't store the data, who warn users, and who allow exception sites. This technique basically drops the HTTPS proxy down to being about as well hidden as a normal HTTP one. Even better, our pals the proxy authors aren't really expecting us to be this sophisticated, so they actually obfuscate their intentions even less - making these arguably easier to block. We SmoothWall folk have been doing this only a month - relatively little feedback as yet but seems like fun.

 

Hope that helps, if anyone would like more info, I am usually available by phone/email/edugeek

 

Tom

[Geoff]

Finally... there's the full gun - Man In The Middle interception. This uses your proxy to turn 1 SSL session into 2 - with a small gap in between so you can examine the URL and page content. This is VERY powerful. Scary in places. A number of vendors do this - but look for ones who don't store the data, who warn users, and who allow exception sites. This technique basically drops the HTTPS proxy down to being about as well hidden as a normal HTTP one. Even better, our pals the proxy authors aren't really expecting us to be this sophisticated, so they actually obfuscate their intentions even less - making these arguably easier to block. We SmoothWall folk have been doing this only a month - relatively little feedback as yet but seems like fun.

 

This 'feature' is available to anyone running Squid 3.1 or later via the SSLBump configuration directive. Some client side configuration is required if you wish it to be total 'quiet' (You must push out your server certificates to clients so the browsers trust you). You may intercept, alter and adapt the HTTP session, once it's been decrypted by Squid/SSLBump, via ICAP.

Edited May 11, 2009 by Geoff

[tom_newton]

Geoff - indeed it is. We will (probably) drop our implementation and use squids in the 2010 branch of SmoothWall, but with it still being in beta (alpha when the SSL MITM project was spec'd) we did it ourselves. We also use our custom SSL stuff for MITM inspecting jabber (googletalk) IM.

[azrael78]

What we have done for students at least - is to totally block any HTTPS traffic using ISA 2006's protocol/port blocking rules.

 

The only time they need it is for the VLE and that doesn't go through our proxies on-site as that goes straight to the county equipment.

 

It works for us - staff however, have HTTPS available to them.

 

Az

[john]

Must admit I've still to read that section of the manual for that new feature in my Smoothwall Just playing with getting the VPN setup and publishing sites through it, well the sites are done its just VPN to go now Nearly there on that score, then its back to looking at the SSL But its a good thing to have

[Geoff]

Geoff - indeed it is. We will (probably) drop our implementation and use squids in the 2010 branch of SmoothWall, but with it still being in beta (alpha when the SSL MITM project was spec'd) we did it ourselves. We also use our custom SSL stuff for MITM inspecting jabber (googletalk) IM.

 

 

Does this mean you'l be reimplmenting some/all of dansguardian as an ICAP plugin?

[tom_newton]

Geoff, unfortunately, no. We've looked at both ecap and icap and we couldn't get either to do what we wanted; icap is too limited, ecap is so tightly bound to squid, you end up sharing squid's process model which is OK for a proxy but crap for a filter.

[Geoff]

That's a shame.