667429 - Shibboleth Replay Detection Failure

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Mischan Gholizadeh Toosarani]

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]

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

The browser understands html,Javascript,cookies,http etc.
Could you please rephrase your report so that we can understand it ?

Comment 3

[Scott Cantor]

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

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]

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]

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]

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]

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]

Attachment: 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]

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]

(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]

"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]

Ok, thank you for clearing that up (especially the part with the apache server hosting the SP).

Comment 14

[Matthias Versen [:Matti]]

marking invalid based on comment#12.
Scott, thank you very much for the help !

Comment 15

[Hideki Sakamoto]

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]

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.