Re: [squid-users] NTLM pass-through breaking uploads to Flickr, etc.

On Wed, 24 Feb 2010 10:15:29 -0800, Mike Ely <mikeely_at_amyskitchen.net>
wrote:
> On 2/23/10 4:24 PM, "Amos Jeffries" <squid3_at_treenet.co.nz> wrote:
>
>> On Tue, 23 Feb 2010 15:38:34 -0800, Mike Ely <mikeely_at_amyskitchen.net>
>> wrote:
>>> On 2/19/10 6:11 PM, "Amos Jeffries" <squid3_at_treenet.co.nz> wrote:
>>>
>>>> Mike Ely wrote:
>>>>> On 2/17/10 4:10 PM, "Mike Ely" <mikeely_at_amyskitchen.net> wrote:
>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> We've got 2.6 stable running as logging only server, no caching
going
>>>>>> on.
>>>>>> Users are authenticated via NTLM if they're on Windows, works fine
in
>>>>>> FF and
>>>>>> IE with one exception. Uploading a file prompts a second auth
>> dialogue
>>>>>> (regardless of which browser) and entering credentials to that only
>>>>>> causes
>>>>>> the browser to hork. I've tested this on XP and 2k3, various
browser
>>>>>> versions.
>>>>>>
>>>>>> What I find interesting about this is that if I set the Internet
>>>>>> Connection
>>>>>> Settings in the control panel to "auto-detect" I will get the
failure
>>>>>> even
>>>>>> if I explicitly configure FireFox (via about:config) to not do NTLM
>>>>>> pass-through. My current working guess is that Flickr (and the
>>>>>> work-related
>>>>>> site that uses a somewhat similar ajaxy/flashy uploader) is making
a
>>>>>> call to
>>>>>> Flash and Flash is barfing on the NTLM pass-through, but that's
>> really
>>>>>> only
>>>>>> a guess.
>>>>>>
>>>>>> Steps to reproduce:
>>>>>> Setup NTLM auth
>>>>>> Connect through the proxy
>>>>>> Attempt to upload a photo to Flickr
>>>>>>
>>>>>> Steps to work around:
>>>>>> Disable "automatically connect" on the client control panel and
auth
>> by
>>>>>> hand, or use a non-windows client and also auth by hand.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Squid.conf here:
>>>>
>>>> <snip>
>>>>
>>>>>>
>>>>>> # Destinations here
>>>>>> acl fedex dstdomain .fedex.com
>>>>>>
>>>>>> # User groups here
>>>>>> acl localnet proxy_auth REQUIRED src 10.0.0.0/8
>>>>
>>>> 1) "proxy_auth" ACL type accepts a list of usernames OR the word
>>>> "REQUIRED" to accept any valid username.
>>>>
>>>> 2) "proxy_auth REQUIRED src" has never been valid AFAICT. The "src
..."
>>>> bit has silently been discarded by all Squid 2.6+ I'm aware of.
>>>>
>>>> 3) If I'm wrong about (2) being discarded then the effect will be
that
>>>> the username "src" or "10.0.0.0/8" with no password might possibly be
>>>> used to login on your Squid.
>>>>
>>>> 4) Without IP address range checks there is no restriction on where
the
>>>> logins may be done from.
>>>>
>>>>
>>>>>> http_access allow CONNECT wuCONNECT localnet
>>>>
>>>> 'localnet Requires authentication and will challenge.
>>>>
>>>>>> http_access allow windowsupdate localnet
>>>>
>>>> 'localnet Requires authentication and will challenge.
>>>>
>>>> NOTE: 'localnet' being one of the default Squid-3 ACL all
documentation
>>>> you will find anywhere will assume that it retains that default type
>>>> (which is to match source IP address only).
>>>>
>>>>
>>>> SOLUTION:
>>>> Create a new name for your login ACL and use that where login is
>>>> needed.
>>>> Revert localnet to IP range "src" type and use that where
>> appropriate
>>>> as well.
>>>>
>>>> <snip again>
>>>>
>>>> The notes I've added above in your config should help out a LOT.
>>>> Get those corrected and we can work on the additional fix after that.
>>>>
>>>> Amos
>>>
>>> Hi Amos,
>>>
>>> Thanks for the reply. Per your suggestions, I¹ve created a test
server
>>> running 2.7.STABLE7 and rebuilt the config (which I¹ll append below).
>>> Unfortunately this doesn¹t change the original issue with file uploads
>>> ­
>>> client machine thinks it¹s getting regular proxy stuff due to edited
>> hosts
>>> file and I¹m verifying through logs that it¹s hitting the test server
I
>>> want
>>> it to use. Then again, maybe I simply misunderstood you and
>> misconfigured
>>> it again...
>>
>> That one looks much better. As far as I can tell right now it should be
>> passing NTLM auth bits thru to the web server when that server asks for
>> them.
>>
>> The "acl amysnet proxy_auth REQUIRED src 10.0.0.0/8" is still broken,
but
>> you are not using it so can remove.
>>
>> Or to retain it you will need it to become something like this:
>> acl amysnetIP src 10.0.0.0/8
>> acl amysnetLogin proxy_auth REQUIRED
>> http_access deny amysnetIP !amysnetLogin
>> http_access allow amysnetIP amysnetLogin
>>
>> Amos
>>
> OK, I've implemented that change as well, but even still, whenever I try
to
> do the upload, the NTLM auth dies and I get prompted to login. The
access
> log shows something like the following (from Firefox, IE uses an ActiveX
> uploader for Flickr):
>
> 1267034703.566 632 10.10.5.62 TCP_DENIED/407 2090 POST
> http://up.flickr.com/services/upload/ - NONE/- text/html
>
> Note the lack of a username in the POST even though various CONNECT and
GET
> calls work fine. Also, I see POST calls working correctly for things
like
> login screens, so maybe it's just binary files? I see exactly the same
> behavior in uploads going to the actual work-related site that triggered
> the
> whole issue.
>
> Here's what's utterly maddening: I can toggle this on and off simply by
> checking and unchecking "automatically detect settings" in the Windows
> Internet Control Panel, even though I'm using Firefox AND Firefox is
using
> NTLM pass-through auth correctly (it goes out and gets the WPAD, I can
see
> the access_log running through visits with my username attached, etc.).
We
> have a lot of users running IE for various lazily-coded sites, so we
need
> IE
> to go through the proxy as well.

Ah. So its definitely something at the browser end then. not much we can
do about that Sorry.

>
> It seems like there's some weird hook in the Windows networking stack
that
> horks things when the "autodetect settings" feature is enabled, and I'm
> going nuts trying to figure out what it is.

I really wish I could say I was surprised. I've seen similar funkiness in
the most recent WinHTTP libraries used by Win7. The windows update ActiveX
controls only follow the manually configured proxy settings, even if
disabled.

Amos
Received on Wed Feb 24 2010 - 23:39:32 MST