Bugzilla – Bug 3538
Behind squid 3.1 series, can't authenticate in sharepoint server
Last modified: 2012-08-15 02:38:18 UTC
Created attachment 2662 [details] Pcap file, squi.conf, access.log and cache.log of both squid 3.1 and 3.2. Sharepoint server: - Win 2008R2 Enterprise. - Sharepoint 2007 Enterprise. Squid configuration: - Default squid.conf, with uncommented "cache_dir" and through "http_access allow localhost". - No squid auth configuration. Tests: - Client using last versions of google chrome and firefox. - Behind squid 3.1 series (including last one, squid-3.1.19), can't authenticate in sharepoint http server. - Behind squid 3.2 series (including first one, squid-3.2.0.1), no problem authenticating sharepoint. Behaviour: - With squid 3.2 or withouth squid, accessing sharepoint url (http://my_sharepoint_server), a pop-up asks for sharepoint user/password. After inserting a correct user/password, got success message: HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Date: Thu, 26 Apr 2012 16:06:02 GMT Connection: close - With squid 3.1, inserting correct user/password, pop-up comes again and again, just like wrong user/password. Looks like a parser problem, since squid haven't to handle sharepoint authentication headers. My sharepoint credentials: - User: usertest - Password: Test123
Created attachment 2663 [details] New pcap files before and after squid and sniffer map.
Two things in this trace. For 3.1 the server is responding without Connection:keep-alive. We need to check if Squid-3.1 is assuming keep-alive or not when receiving HTTP/1.1 responses. The connection is closed immediately, so it could be a bad KA assumption left over from HTTP/1.0. In the 3.2 traces I'm seeing request-smuggling attacks being performed by IIS/7.5. The 404 response after login has a 100-byte body which starts: "HTTP/1.1 200 OK\r\n".
(In reply to comment #2) > Two things in this trace. > > For 3.1 the server is responding without Connection:keep-alive. We need to > check if Squid-3.1 is assuming keep-alive or not when receiving HTTP/1.1 > responses. The connection is closed immediately, so it could be a bad KA > assumption left over from HTTP/1.0. UPDATE: traces provided in squid-users indicate 3.1.19 at least is providing correct keep-alive on the squid->client connection. Unless there are any objections I am going to close this bug againt 3.2 series and put it down to HTTP 1.0/1.1 behaviour problems in IIS and IE. The response smuggling performed by Sharepoint in the "working" 3.2 traces is highly suspect of broken client/server software.
I am experiencing the same problem accessing a sharepoint site via Squid 3.1.16. IE on XP works. IE on Win7 does not work. Firefox on XP does not work. All work when I bypass the proxy and all work through Astaro proxy.
*** Bug 3512 has been marked as a duplicate of this bug. ***
Squid 3.2 series is now released as stable for production use and suercededs all 3.1 releases. Closing this bug against 3.2.