Re: [squid-users] NTLM not working with HTTPS pages

On 27/04/2012 5:08 a.m., Wladner Klimach wrote:
> Amos,
>
> did you receive my e-mail? I really need to fix this problem. I've
> been struggling for months to build a proxy solution and now the only
> problem is this. So if you could point me some direction of what to do
> I would appreciate.

There is nothing we can do about this.

The client software is pushing data into the CONNECT tunnel before the
NTLM handshake is completed, and sending RST in order to clear the
channel when it gets the handshake stage-2 response back. NTLM requires
that connections MUST be kept alive between stage 1 and stage 3 of the
handshake.

The client is just broken, it is already handling state knowledge that
NTLM is present and what stage the handshake is at, there is no reason
to send data on that second CONNECT and NTLM requires it not to.

Amos

>
> Regards,
>
> Wladner
>
> 2012/4/25 Wladner Klimach:
>> Amos,
>>
>> I've made the capture as you said. I can see the CONNECT request from
>> the client and later the 407 Proxy Authentication Required, but after
>> that with no reason the client close the connection with a RST flag.
>> I'm sending you the file so that you can see the whole data flow. Can
>> you see something wrong at this captured data?
>>
>> Regards,
>>
>> Wladner
>>
>> 2012/4/20 Amos Jeffries:
>>> On 21/04/2012 4:01 a.m., Wladner Klimach wrote:
>>>> Amos,
>>>>
>>>> what could be causing this? When I desable NTLM authentication or when
>>>> I use Kerberos all access go just fine, but when only NTLM is able I
>>>> can't get access to https pages and I get in the logs TCP_DENIED/407.
>>>> How can I debug it?
>>>
>>> You need to locate and identify what request headers are being denied.
>>>
>>> The easiest way with 3.1 is a packet dump with full packet bodies ("tcpdump
>>> -s0 ..."). Then base-64 decode the www-authenticate headers from the client
>>> and check the type codes. NTLM has "NTLMSSPI" then a binary type number 1, 2
>>> or 3.
>>>
>>> The NTLM flow should be:
>>>
>>> client: makes request (no auth)
>>> Squid: emits 407 with NTLM advertised as available
>>> squid: [optionally closes the connection (due to "auth_param ntlm
>>> keep-alive off" hack)]
>>> client: repeat request with type-1 NTLM proxy-auth header
>>> squid: 407 with type-2 NTLM proxy-auth header
>>> client: repeat request with type-3 NTLM proxy-auth header
>>> squid: HTTP response
>>> client: [optionally make other requests with type-3 NTLM proxy-auth header]
>>> connection closes.
>>>
>>>
>>> If you find connections opening and starting immediately with type-3 token
>>> that is Kerberos or broken NTLM from the client.
>>>
>>>
>>> Amos
>>>
>>>
>>>> regards
>>>>
>>>> 2012/4/20 Amos Jeffries<squid3_at_treenet.co.nz>:
>>>>> On 21/04/2012 1:15 a.m., Harry Mills wrote:
>>>>>> Hi Wladner,
>>>>>>
>>>>>> I don't think this is causing your problems, but I think you need to
>>>>>> change the following:
>>>>>>
>>>>>> Instead of:
>>>>>>
>>>>>> http_access deny CONNECT !Safe_ports
>>>>>>
>>>>>> try:
>>>>>>
>>>>>> http_access deny !Safe_ports
>>>>>> http_access deny CONNECT !SSL_ports
>>>>>>
>>>>>> Also, on the last two lines of your included config you have:
>>>>>>
>>>>>> acl AUTENTICADO proxy_auth REQUIRED
>>>>>> http_access allow AUTENTICADO
>>>>>
>>>>> This is one of several correct proxy-auth configurations.
>>>>>
>>>>>
>>>>>> I simply have:
>>>>>>
>>>>>> http_access allow proxy_auth
>>>>>>
>>>>>> I have no idea if this will help, but worth giving it a try perhaps?
>>>>>
>>>>> ?? for that to work you require this somewhere above your http_access
>>>>> rule
>>>>> ...
>>>>>
>>>>> acl proxy_auth proxy_auth REQUIRED
>>>>>
>>>>> or some other definition for an ACL *label* "proxy_auth".
>>>>>
>>>>> Amos
>>>
Received on Thu Apr 26 2012 - 21:54:45 MDT