RE: [squid-users] https analyze, squid rpc proxy to rpc proxy ii6 exchange2007 with ntlm

From: Clem <clemfree_at_free.fr>
Date: Fri, 2 Mar 2012 14:33:23 +0100

If I go to https://www.owasp.org/index.php/Authentication_In_IIS or
http://www.innovation.ch/personal/ronald/ntlm.html

NTLM Handshake

When a client needs to authenticate itself to a proxy or server using the
NTLM scheme then the following 4-way handshake takes place (only parts of
the request and status line and the relevant headers are shown here; "C" is
the client, "S" the server):

    1: C --> S GET ...
    
    2: C <-- S 401 Unauthorized
                  WWW-Authenticate: NTLM
    
    3: C --> S GET ...
                  Authorization: NTLM <base64-encoded type-1-message>
    
    4: C <-- S 401 Unauthorized
                  WWW-Authenticate: NTLM <base64-encoded type-2-message>
    
    5: C --> S GET ...
                  Authorization: NTLM <base64-encoded type-3-message>
    
    6: C <-- S 200 Ok

I can see there us 3 auth/authorization before le 200 OK, squid seems to
send only 1 and stop

-----Message d'origine-----
De : Clem [mailto:clemfree_at_free.fr]
Envoyé : vendredi 2 mars 2012 14:29
À : squid-users_at_squid-cache.org
Objet : [squid-users] https analyze, squid rpc proxy to rpc proxy ii6
exchange2007 with ntlm

Hello,

What I can see :

........ USER with outlook PROXY RPC enabled with NTLM auth -> PROXY RPC
IIS6/Exchange 2007

Outlook sends credentials, the proxy handles them and open exchange mailbox.

........ USER with outlook PROXY RPC enabled with NTLM auth -> SQUID PROXY
-> PROXY RPC IIS6/Exchange 2007

The user sends credentials via squid, squid can't forward them exactly to
the Exchange/IIS6 RPC Proxy and the proxy denies

In the https analyzer I can see the NTLM request header is very short when
we use squid and when we don't use it this header is very long ...

Like this

NTLM
TlRMTVNTUAADAAAAGAAYAJgAAABkAWQBsAAAABoAGgBYAAAAEAAQAHIAAAAWABYAggAAAAAAAAAU
AgAABYKIogYBsR0AAAAPOq4/lcuCWEXBWP01xOfE7UUAVQBSAE8AUwBJAFQATgBFAFYARQBSAFMA
YQAuAHcAYQBxAHUAZQB0AEEALQBXAEEAUQBVAEUAVAAtAEgAUAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA4lx3+SYlVeSBpzbj9B93OAQEAAAAAAABuLvLQdfjMAYEqGS4sEy38AAAAAAIAGgBFAFUA
UgBPAFMASQBUAE4ARQBWAEUAUgBTAAEAFgBFAFUAUgBPAFMASQBUAE0AQQBJAEwABAAgAGUAdQBy
AG8AcwBpAHQAbgBlAHYAZQByAHMALgBmAHIAAwA4AGUAdQByAG8AcwBpAHQAbQBhAGkAbAAuAGUA
dQByAG8AcwBpAHQAbgBlAHYAZQByAHMALgBmAHIABQAgAGUAdQByA[.....]

For direct connection

And whith squid :

NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

Like it's stucked, I dunno

The analyzer tells me that :

WWW-Authenticate header field (section 14.46) containing a challenge
   applicable to the requested resource. The client MAY repeat the
   request with a suitable Authorization header field (section 14.8). If
   the request already included Authorization credentials, then the 401
   response indicates that authorization has been refused for those
   credentials. If the 401 response contains the same challenge as the
   prior response, and the user agent has already attempted
   authentication at least once, then the user SHOULD be presented the
   entity that was given in the response, since that entity MAY include
   relevant diagnostic information. HTTP access authentication is
   explained in section 11.

Still stucked there ...

Regards

Clem
Received on Fri Mar 02 2012 - 13:33:29 MST

This archive was generated by hypermail 2.2.0 : Fri Mar 02 2012 - 12:00:02 MST