Re: [squid-users] hopeless Windows Update problem(?)

On Tue, 11 May 2004, Michael Hocke wrote:

> Configure it as transparent proxy and make sure it considers the Host:
> header. Tighten the access controls so that only that restricted network
> can get out and only to *.windowsupdate.com,
> *.windowsupdate.microsoft.com, and wustat.windows.com. Well, in theory

Windowsupdate does also access one other site by ssl (at least it did
when I last checked). But I think this you could find out yourself.

> this is fine and dandy and would work if only it wouldn't be using SSL
> down the road. That is pretty much a show stopper and we can forget about
> the transparent proxy idea.

Hmm, I would guess that ssl cannot be transparently proxied, basically
because it's encrypted and you cannot cache it anyway, so squid could just
redirect the traffic and then why first intercept it?

I think there are two cases:

a) Your users need a proxy to access the internet anyway, they have it
configured (and have to), so you don't need transparent proxying, and on
that machine which they use as a proxy, you could probably easily allow
them to use ssl to the microsoft machines and redirect them otherwise.

b) They are not forced to use a proxy, and you just do transparent
proxying of plain http for the sake of caches and what else. However,
since ssl cannot by transparently proxied (and redirected etc), they
probably can do direct ssl already anyway. What I mean is, you'll probably
have to modify your firewall setup in a way that quarantined hosts cannot
access the internet EXCEPT for the ssl ports of the microsoft update
servers (you'll probably have to use an address range here)

> I know that we are not the only ones that are trying or tried to solve
> this problem. Our network is all over the place and grew almost
> uncontrolled over two decades, consisting of many, many subnets behind T1s
> so that direct access to the internet for that purpose is pretty much out
> of question (using NAT for example). So is WCCP or other things we could

Still, https cannot be cached, hence the bandwidth limitation does not
apply here. Either block https completely or the traffic goes out
uncached.

I don't know what information to Microsoft uses https, but it may well be
that several of the update packages cannot be cache for such a reason.
Now, you can complain to Microsoft about this, but they'll probably say:
Just use SUS.

> do on router level. SUS or SMS is not going to work either because a) it
> doesn't really have the entire repertoire of update packages and b) it
> requires support from the client and c) we deal with personal computers
> here that belong to the students and not to the organization. That would
> work in a corporate world but not on our campus.
>
> Anything else we could look into? Would contacting Microsoft do any good?
> The only solution I have right now is keep the proxy but have the infected
> end-user configure a proxy auto config script into his browser.
>
> Thanks for any pointers, ideas, comments.
>
> - Michael

Michael.

--
Michael Weller: eowmob@exp-math.uni-essen.de.