RE: [squid-users] POST method when using squid_kerb_auth and sending Yahoo mail attachment

From: Hank Disuko <gourmetcisco_at_hotmail.com>
Date: Wed, 8 Feb 2012 09:33:31 -0500

Ok, to add yet another dimension to this...

When I use IE with the configured proxy settings, and I run a packet
capture at the moment I select "Attach File" in the Yahoo Mail compose
message window, I capture the aforementioned POST method, which
eventually fails or hangs etc.

When I use Firefox with manually configured proxy settings (NOT the "use
system settings" option) and I perform the same packet capture at the
same point, I capture nothing to/from squid and the file is attached
successfully.

When I use Firefox with the "use system settings" proxy config, it behaves like IE above and fails.

I know this is significant, but at this point I'm not sure what it means.

Hank

> Date: Mon, 6 Feb 2012 20:00:24 +1300
> From: squid3_at_treenet.co.nz
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] POST method when using squid_kerb_auth and sending Yahoo mail attachment
>
> On 6/02/2012 5:31 p.m., Hank Disuko wrote:
> > Thanks Amos,
> >
> > What's happening is quite similar to the details described in the aforementioned Firefox bug filing.
>
> Of course. Authentication in HTTP has a flow of 4+ steps:
> 1) --> client request
> 2) <-- server challenge 401 or 407 response
> 3) --> client request w/ credentials
> 4) <-- server success/fail response
> ...
>
> This is the same for all authentication protocols. Possibly with a loop
> repeating 3 & 4 until a suitable set of credentials are agreed on or the
> client gives up.
>
> * The firefox bug was about firefox not sending "Basic" auth protocol
> credentials properly when challenged.
> * So far you have been talking around the edges of something that sounds
> like a client not sending "Kerberos" auth protocol credentials correctly
> when challenged,
> or possibly you misconfiguring a Kerberos helper to validate
> non-Kerberos credentials.
>
> The user watching gets to see only that the auth worked, a popup
> appeared, or the forbidden error page appeared. They are not forced to
> see what protocols are in use or how many retries were made.
>
> >
> > When the "attach file" function is started in the Yahoo Mail compose message window and a file is selected from the user's desktop filesystem, a new HTTP POST operation is initiated to squid. This is a new tcp session entirely.
>
> This would be step (1) above.
>
> >
> >
> > The POST operation is a form served by host sp1.attach.mail.yahoo.com using a Shockwave Flash user-agent - so I'm assuming the browser itself sits this one out. Here's the first little bit of the request, it's followed by form-data such as "filename" and "content-type" etc.
>
> Aha. Now we are getting places. First item is to check whether Shockwave
> Flash supports Kerberos protocol which you are requiring of it. Chances
> are shockwave does but the applet it is running does not. It is very
> common to find web apps which cannot do auth even when SDK like Flash
> and Java have long provided API to do all the difficult parts.
>
> >
> > POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred?-- HTTP/1.1
> > Accept: text/*
> > Content-Type: multipart/form-data; boundary=----------cH2ae0gL6KM7ei4ei4ei4Ij5Ij5KM7
> > User-Agent: Shockwave Flash
> > Host: sp1.attach.mail.yahoo.com
> > Content-Length: 719794
> > Proxy-Connection: Keep-Alive
> > Pragma: no-cache
> > Cookie: B=dgrausd7a344r&b=4&d=vku6LippYFR6PRpZokl3s5qyCUJklnhtfiFf&s=pt&i=A6MbHqjIfHzX9QIh5CDC;
>
> Yes definitely a step (1) client request with no credentials.
>
> However the thing to note here is that this POST request is using a
> simple HTTP format without the HTTP/1.1 chunked encoding or Expect
> features. That is fine but it means that Content-Length bytes of data
> MUST be transmitted for the body, regardess of what the server rsponds with.
>
> >
> >
> > Squid responds to this initial POST operation with the predictable TCP_DENIED/407 "Cache Access Denied" message:
> >
> > from access.log:
> >
> > Sun Feb 5 22:29:16 2012 3 172.16.130.22 TCP_DENIED/407 5626 POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred? - NONE/- text/html
> >
> > HTTP/1.0 407 Proxy Authentication Required
> >
> > Server: squid/3.1.11
> >
> > Mime-Version: 1.0
> >
> > Date: Mon, 06 Feb 2012 03:29:16 GMT
> >
> > Content-Type: text/html
> >
> > Content-Length: 5206
> >
> > X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
> >
> > Vary: Accept-Language
> >
> > Content-Language: en
> >
> > Proxy-Authenticate: Negotiate
> >
> > X-Cache: MISS from localhost
> >
> > X-Cache-Lookup: NONE from localhost:3128
> >
> > Via: 1.0 localhost (squid/3.1.11)
> >
> > Connection: keep-alive
> >
>
> So far everything is perfectly correct.
>
>
> >
> > Squid actually serves up the full "407 Denied" webpage, but it's not presented to the user.
> That is correct. Displaying the error page is optional. Being kerberos
> authentication it SHOULD be able to locate the Kerberos credentials
> silently in the background without bothering the user at all.
>
> > Instead, the Yahoo Flash user-agent seems to trample on instead and attempts to send the attachment anyway, without first re-sending the request with the credentials required to access squid.
>
> This is correct. It MUST do so. It has instructed Squid that
> "Content-Length: 719794" bytes are following the headers. Squid will
> read and discarded it all then the connection will become free for the
> keep-alive features to re-use.
>
> > I can see the pdf being uploaded to the squid server, but squid just ignores it.
>
> Good. That means Squid is working.
>
> > This manifests as a "hanging" upload window to the user.
>
> Maybe, maybe not. Flash is expected to locate credentials after the 407
> and repeat the POST request with them attached.
> If it cannot locate credentials it is expected to produce some form of
> error about that failure.
>
> A non-changing upload window could just mean the app is waiting while
> the first POST is transmitted and discarded and the Kerberos credentials
> are being located. It may start to display things if it ever gets to the
> point of doing a POST with credentials.
>
> >
> >
> >
> > I guess I need to know where to look in order to find out why the request is not re-sent using the proper credentials. Is it the Yahoo user-agent? is it the browser?
>
> The Shockwave player or the application running inside it. If either one
> does not support your required Negotiate/Kerberos auth (or even auth in
> general) it will fail.
>
> Amos
>
                                               
Received on Wed Feb 08 2012 - 14:33:38 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 08 2012 - 12:00:02 MST