Return HTTP Vary header

Bug #913895 reported by Dolph Mathews
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Wishlist
Dolph Mathews

Bug Description

A Vary header should be returned with all authenticated responses to allow HTTP caches to differentiate between authenticated requests.

See "14.44 Vary": http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Request:

    GET /tenants
    X-Auth-Token: 12345

Response:

    Vary: X-Auth-Token

    { /* tenants specific to token 12345 */ }

Revision history for this message
Thierry Carrez (ttx) wrote :

@Dolph: trying to assess impact. Could you explain how this could be abused ? If this is serious, we might want to coordinate disclosure rather than just push the fix.

Revision history for this message
Dolph Mathews (dolph) wrote :

This came out of a meeting with Jorge Williams yesterday. My understanding is that keystone can't be deployed behind an HTTP cache as-is. If you did, you would might see the following behavior.

---

Request from Client 1:

    GET /tenants
    X-Auth-Token: 12345

HTTP Cache: no existing cache; reverse proxies request

Keystone Response:

    { /* tenants specific to token 12345 */ }

HTTP Cache: caches response

Client 1 receives the appropriate tenant list.

---

Request from Client 2:

    GET /tenants
    X-Auth-Token: 67890

HTTP Cache: Existing cache found for GET /tenants

HTTP Cache Response:

    { /* tenants specific to token 12345 */ }

Client 2 receives tenant list for Client 1.

---

Appending a Vary header to the Keystone response would instruct the cache to differentiate between responses relevant to different tokens (i.e. vary the cache response based on the X-Auth-Token header). The same solution would also apply to the new X-Subject-Token header.

Revision history for this message
Thierry Carrez (ttx) wrote :

Hrm... Are such components supposed to be deployed behind a cache ? Looks like all requests should be unique and non-cached, so why would you deploy behind a cache ? Doesn't this also apply to Nova; Swift or Glance ? Adding Vish for more input.

Revision history for this message
Vish Ishaya (vishvananda) wrote :

I don't think this is a security vulnerability and it doesn't need to be private. No one has keystone deployed behind a cache at the moment. Seems like a useful thing to fix, however.

Revision history for this message
Thierry Carrez (ttx) wrote :

@Dolph: do you agree to open this up ? I wouldn't consider it an exploitable vulnerability, more a workaround for crazy people deploying auth systems behind caches ?

Revision history for this message
Dolph Mathews (dolph) wrote : Re: [Bug 913895] Re: Return HTTP Vary header

I'm not opposed to opening it up.

As is, you can't deploy behind a cache at all, anyway.

Thierry Carrez (ttx)
Changed in keystone:
importance: High → Wishlist
visibility: private → public
Thierry Carrez (ttx)
security vulnerability: yes → no
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/3231

Changed in keystone:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/3231
Committed: http://github.com/openstack/keystone/commit/f2726df39c3ec4e50448361e3be4cfba45e4fa93
Submitter: Jenkins
Branch: master

commit f2726df39c3ec4e50448361e3be4cfba45e4fa93
Author: Dolph Mathews <email address hidden>
Date: Fri Jan 20 14:22:20 2012 -0600

    Added Vary header to support caching (bug 913895)

    Change-Id: I26dca09ace688a25cf207214808e8a9c919621c4

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in keystone:
milestone: essex-3 → 2012.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.