Last Comment Bug 667429 - Shibboleth Replay Detection Failure
: Shibboleth Replay Detection Failure
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 5 Branch
: All Other
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Patrick McManus [:mcmanus]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-27 05:20 PDT by Mischan Gholizadeh Toosarani
Modified: 2011-06-29 17:31 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The complete http-log with the necessary steps for reproducing the error, using a new/clean profile (289.54 KB, text/plain)
2011-06-28 09:16 PDT, Mischan Gholizadeh Toosarani
no flags Details

Description Mischan Gholizadeh Toosarani 2011-06-27 05:20:05 PDT
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30

Steps to reproduce:

We have a website at a university institute, that accepts authentication from the university/federation Shibboleth-IdP. Users are logging in/out multiple times a day. Sometimes the IdP session is still active, sometime the user has to re-authenticate. I did the same thing and this issue is perfectly reproducible with multiple users.

Other Firefox 5/Shibboleth - Users seem to have the same problem, look at the following thread for details:

https://lists.internet2.edu/sympa/arc/shibboleth-users/2011-06/msg00449.html


Actual results:

The user gets a "Message did not meet security requirements" in the http-based response from the IdP. In the IdP-logs sysadmins get a 'Rejecting replayed message ID' error.


Expected results:

Our plattform should have gotten a notification that the user is still authenticated.
The user should have been redirected to the requested page.
There should have been no errors logged on the IdP side.
Comment 1 Mischan Gholizadeh Toosarani 2011-06-27 05:24:22 PDT
btw, i can reproduce it at least with the following build:

Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0

While i can confirm that all of our users have the same problem on Windows-based builds, the "shibboleth-users" thread seems to show that it works on some client-configurations:

https://lists.internet2.edu/sympa/arc/shibboleth-users/2011-06/msg00451.html
https://lists.internet2.edu/sympa/arc/shibboleth-users/2011-06/msg00456.html
Comment 2 Matthias Versen [:Matti] 2011-06-27 07:12:56 PDT
The browser understands html,Javascript,cookies,http etc.
Could you please rephrase your report so that we can understand it ?
Comment 3 Scott Cantor 2011-06-27 07:52:18 PDT
The observation is that the browser seems to be issuing two GETs to the server in response to a 302/Location redirect. One server returns the redirect, and then the client seems to make two requests to the designated Location.
Comment 4 Matthias Versen [:Matti] 2011-06-27 11:19:49 PDT
Would it be possible to attach a http log if you can reproduce the problem ?
https://developer.mozilla.org/en/HTTP_Logging

Can you also try to reproduce it with a new profile http://support.mozilla.com/kb/Managing%20profiles ?
Comment 5 Scott Cantor 2011-06-27 13:06:22 PDT
I've made the same request of the people reporting the issue to the Shibboleth mailing list. I can't reproduce the issue so far, so it's waiting on the people who can.
Comment 6 steve 2011-06-27 15:25:56 PDT
I believe this is a bug in the mod_shib Apache module for Shibboleth. The module is sending far-expires headers with a 302 redirect early in the auth process:

GET foo

Location: bar
Cache-Control: max-age=315360000
Expires: Thu, 24 Jun 2021 21:29:33 GMT

When the browser later gets redirected to "foo", FF5 honors the cached Location and re-forwards to "bar" (breaking the Shibboleth process), whereas previous versions and most other browsers disregard the cached response and go ahead and re-issue the request for "foo".

While my opinion is that FF5 is right to cache that redirect (and Steve Souders wants it :), doing so may expose more bugs like this in other apps.
Comment 7 Scott Cantor 2011-06-27 16:33:57 PDT
Actually that's Apache, not mod_shib. It handles redirects via a fixed response code and a built-in set of response headers. I'll see what I can do to alter this, but in the meantime, can you explain how you reproduced this? I've tested any number of times with no failure. The client must be involved on some level, not just the server.
Comment 8 Scott Cantor 2011-06-27 16:54:20 PDT
This is actually environmental, not mod_shib or Apache. Any number of existing sites don't exhibit this response header behavior, so it's coming from additional Apache settings.
Comment 9 Mischan Gholizadeh Toosarani 2011-06-28 09:16:27 PDT
Created attachment 542497 [details]
The complete http-log with the necessary steps for reproducing the error, using a new/clean profile

In this case the authentication-session at the IdP was still active so you have no initial login, just the actual issue when reauthenticating with the IdP.

The relevant part starts at line 193.
Comment 10 Scott Cantor 2011-06-28 09:59:01 PDT
I can't tell much from that log (try Live Headers), but accessing the site mentioned in the log does show the caching information in the response. So that appears to be the "bug", I think we can probably close this as invalid.
Comment 11 Mischan Gholizadeh Toosarani 2011-06-28 10:45:43 PDT
(In reply to comment #10)
> I can't tell much from that log (try Live Headers), but accessing the site
> mentioned in the log does show the caching information in the response. So
> that appears to be the "bug", I think we can probably close this as invalid.

sorry to be a pain, but can you tell me - and potentially others - exactly which apache configuration is wrong ("the log does show the caching information in the response"). I thought the problem was between FF5 and the IdP. Even if the error is in our configs it would be interesting to know what should be changed and at which point. Issuing this at mozillas tracker doesn't mean i'm blaming you, but until now the problem occured with FF5 only. Thanks.
Comment 12 Scott Cantor 2011-06-28 10:51:46 PDT
"You" in this case is the Shibboleth team, I'm the SP author, and I'm trying to head off blaming FF if we can identify the issue and shift the discussion back to our list.

The problem is with the caching headers returned by the Apache server hosting the SP, it's telling the client to cache the Redirect. See previous comments in the bug here.

The SP doesn't do that itself, it leaves the behavior of redirects up to Apache right now. It may be that needs to change, but in the meantime, there doesn't appear to be any bug here, just a reasonable choice by FF5 to honor the caching headers on the 302.
Comment 13 Mischan Gholizadeh Toosarani 2011-06-28 10:58:37 PDT
Ok, thank you for clearing that up (especially the part with the apache server hosting the SP).
Comment 14 Matthias Versen [:Matti] 2011-06-29 16:45:33 PDT
marking invalid based on comment#12.
Scott, thank you very much for the help !
Comment 15 Hideki Sakamoto 2011-06-29 17:28:15 PDT
I found a workaround. Add following 3 lines to your SP's shib.conf
-----
<Location /Shibboleth.sso>
  ExpiresActive Off
</Location>
-----

BTW, I think this is FF5's bug. In redirect situations, FF5 sees first page's cache-control and chache last page ignoring cache-control of any passing points.

In Shibboleth, IdP(passing point) always send cache-control header to browser.
-----
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Pragma: no-cache
-----
FF5 ignore it. Though other browser(including ff4 or earlier) does not do so.
Comment 16 Scott Cantor 2011-06-29 17:31:16 PDT
I can't speak to correct behavior, but the workaround won't work in the general case. Not every redirect from the SP is explicitly issued out of that location. We are adding an option to the next patch release to control this globally.

Note You need to log in before you can comment on or make changes to this bug.