W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Proxy-Authorization with empty credentials

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 8 Oct 2011 08:42:20 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20111008064220.GB10549@1wt.eu>
Hi Adrien,

On Wed, Oct 05, 2011 at 10:16:30PM +1300, Adrien de Croy wrote:
> 
> Hi all, I'm hoping someone can help here.
> 
> I've been trawling RFC2616 and 2617 for clarity on an issue a customer 
> is having.
> 
> They have an AV product that does updates using HTTP, and has 
> configuration settings for a proxy, and settings to enable/disable proxy 
> auth and supply credentials.
> 
> The problem is the software sends Proxy-Authorization in all requests, 
> using Basic, and no user/pass - just a base64 encoded ':'
> 
> Since the credentials are empty, we fail authorization, even though 
> policy didn't require authorization, the existence of the 
> Proxy-Authorization header in the request triggered our auth code.
> 
> The reason we go straight into our auth code on the existence of this 
> header, is because with Basic auth, the client will commonly re-use the 
> credentials it previously successfully validated, and going straight to 
> check the creds saves a 407 and round trip.
> 
> I'm struggling to find any language in 2616 and 2617 that states that a 
> Proxy-Authorization with empty creds is invalid, although it seems like 
> an incredibly bad idea.
> 
> The customer contacted the vendor of the offending software, and they 
> said it's by design and not considered a bug.

At least it's better if they feel like they're allowed to do this,
because it means they have a bit of control over their software. Probably
that is was easier for them to do it this way and they did not find in the
RFC anything that forbids it.

> Maybe we need to clarify this going forward?  I think a client shouldn't 
> send P-A unless they wish to authenticate, and shouldn't send Basic 
> creds without clear directive from the user (since it's a potential 
> credential leak).

I pretty much agree with you here. Your last sentence summarizes the
purpose of the header very well IMHO : if you send a header, you want
to trigger some auth. What they're doing if pretty much like exhibiting
a fake ID card at the supermarket when the cashier did not ask for it.

And BTW it's doubly wrong to act this way because they insist on using
the basic auth scheme, but a proxy might want to use another one and
be confused by this header.

Just a suggestion, if their software can filter outgoing headers or if
yours can filter incoming headers (or if an intermediary does so), your
customer may consider removing a Proxy-Authorization which equals "Og=="
which is the base64 encoding for ":" alone. It's dirty, but may help.

Best regards,
Willy
Received on Saturday, 8 October 2011 06:43:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT