Subject: Proxy-Authorization with empty credentials

From: Adrien de Croy <[email-masked]>
Date: Wed, 05 Oct 2011 22:16:30 +1300

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.

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).

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 8 Oct 2011 08:42:20 +0200

Hi Adrien,

> 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.

> creds without clear directive from the user (since it's a potential 

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