Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Hi all,

I don't believe there is anything to be done on the Shibboleth side of things – but I wanted to let others know and perhaps someone will have some info that I don’t. But I am looking to log a bug with Apple.

So this is an issue that has popped up with the latest version of Safari for OSX (5.1.5 released March 26th) and one of our Shibboleth setups. I have included the diagram for ease of visualisation (http://moshpit.net.au/images/ReverseProxy.png) – the dashed
lines are the Shibboleth SSO process through the browser (and not indicative of actual communication between the servers and the IdP). The reason we have the reverse proxy is because the permissions on the intranet are user controlled and we have had confidential
data exposed to the internet previously due to user misconfiguration – so the reverse proxy is a way of enforcing a minimum level of authentication before getting access to internal resources without using a VPN and still allowing users to control access.

The load balancer/site selector will direct external traffic to the Reverse Proxy – the reverse proxy makes request with an internal address and the whole process just works

What appears to be occurring with the new Safari - is that there are 2 form POSTs that occur automatically (using javascript) from the IdP in the whole process of gaining access to the Intranet (one to the Reverse Proxy and one to the Staff Intranet) -
the latest version of Safari is submitting the contents of the first POST both times – instead of the expected behaviour of submitting the contents of the second form on the second POST. You can see this definitely occurring when you trace the traffic.

So a session is successfully created with the Reverse Proxy and then the Intranet throws a Binding error because it is receiving post data for Shibboleth-proxy.sso instead of Shibboleth.sso. If I try and access the original URL again – I will get through
because there is a existing Session with the Reverse Proxy and it then only needs to do a single POST to the Intranet (which then has the correct data). If I switch off javascript and click the submit buttons manually – the whole process works fine. Every
other browser works fine as well (including previous versions of Safari and Safari for iOS).

I was hoping to be able to reproduce the issue with a simple PHP application and using redirects and javascript – therefore eliminating Shibboleth from the equation but unfortunately I have been unsuccessful so far – so believe I may be missing something
else in the process as well. Maybe it's related to mod_proxy or maybe it's related to the size of the POST data – so still have some further testing to do I think.

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

* Aaron Roots <[hidden email]> [2012-04-02 08:19]:
> I don't believe there is anything to be done on the Shibboleth side
> of things – but I wanted to let others know and perhaps someone will
> have some info that I don’t. But I am looking to log a bug with
> Apple.

RE: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

> What appears to be occurring with the new Safari - is that there are 2 form
> POSTs that occur automatically (using javascript) from the IdP in the whole
> process of gaining access to the Intranet (one to the Reverse Proxy and one
> to the Staff Intranet) - the latest version of Safari is submitting the contents
> of the first POST both times - instead of the expected behaviour of
> submitting the contents of the second form on the second POST. You can see
> this definitely occurring when you trace the traffic.

I reported that something was being observed by people running gateway-based SAML deployments a couple of weeks ago (though I didn't mention the gateway part, that hadn't been established as the trigger).

The thing that has to be verified is that the IdP is expiring the page that returns the form containing the javascript in each case. If it expires the form, then the browser is clearly at fault, and there's a very serious bug. If it doesn't expire the form, this is Safari being Safari, and it isn't the first time I've seen it do things like this.

I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
no-cache", or "Expires: 0" are what is needed to expire the page - but
feel I should confirm.

The HTML content served in both forms is correct on the IdP side capture -
Safari web inspector unfortunately does not show the HTML content when
javascript is enabled (when javascript is disabled - Safari web inspector
shows the same content as the IdP - but the process works with javascript
disabled works).

And as I said before - the POST to the SP show the exact same content in
both POSTs (where the second POST should be different)

>> What appears to be occurring with the new Safari - is that there are 2
>>form
>> POSTs that occur automatically (using javascript) from the IdP in the
>>whole
>> process of gaining access to the Intranet (one to the Reverse Proxy and
>>one
>> to the Staff Intranet) - the latest version of Safari is submitting the
>>contents
>> of the first POST both times - instead of the expected behaviour of
>> submitting the contents of the second form on the second POST. You can
>>see
>> this definitely occurring when you trace the traffic.
>
>I reported that something was being observed by people running
>gateway-based SAML deployments a couple of weeks ago (though I didn't
>mention the gateway part, that hadn't been established as the trigger).
>
>The thing that has to be verified is that the IdP is expiring the page
>that returns the form containing the javascript in each case. If it
>expires the form, then the browser is clearly at fault, and there's a
>very serious bug. If it doesn't expire the form, this is Safari being
>Safari, and it isn't the first time I've seen it do things like this.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>[hidden email]

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

On 4/2/12 10:06 PM, "Aaron Roots" <[hidden email]> wrote:
>
>I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
>no-cache", or "Expires: 0" are what is needed to expire the page - but
>feel I should confirm.

Yes, there's nothing else it can do.

I don't really understand what you posted in terms of the design here. All
I wonder is, why does this work with two different SPs in a row? I don't
see why that's any different, but the only deployments that seem to see
this bug are ones that are doing things I don't understand very clearly. I
guess it must have something to do with having intervening
request/response pairs between the forms.

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Cheers for the clarification Scott.

I can understand the confusion on the design - I run into the same
discussions around the office about why we are doing it this way.

Basically it boils down to a business/security requirement - that we are
not allowed to directly expose the intranet server on the internet.
However they also want it available through a VPN or authenticated proxy.
The VPN option would require configuration and support of users' machines
- so we selected the authenticated reverse proxy as the easiest to support
solution that met the requirements.

Then there was of course a choice of Authentication mechanisms that we
could have used on the reverse proxy - and we could have used file-based
or LDAP basic auth. But Shibboleth is so awesome - why would we choose
anything else.

Safari issue aside - the Shibboleth Reverse Proxy process/setup works
really well and is completely unobtrusive for the end user - especially
when compared to the previous solution we had in place (which involved URL
rewriting, fake landing pages, and a process diagram that rivalled the
Shibboleth expert demo:
http://www.switch.ch/aai/demo/2/resources/expert_complete.htm) - best of
all it was that complicated and non-standard that it had many bugs we
could not fix. I would completely recommend the Shibboleth Reverse Proxy
setup to someone facing the same requirements - of course on the hope that
Apple will sort out the Safari issue in the future.

>On 4/2/12 10:06 PM, "Aaron Roots" <[hidden email]> wrote:
>>
>>I believe that the headers "Cache-Control: no-cache, no-store", "Pragma:
>>no-cache", or "Expires: 0" are what is needed to expire the page - but
>>feel I should confirm.
>
>Yes, there's nothing else it can do.
>
>I don't really understand what you posted in terms of the design here. All
>I wonder is, why does this work with two different SPs in a row? I don't
>see why that's any different, but the only deployments that seem to see
>this bug are ones that are doing things I don't understand very clearly. I
>guess it must have something to do with having intervening
>request/response pairs between the forms.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>[hidden email]

>* Aaron Roots <[hidden email]> [2012-04-02 08:19]:
>> I don't believe there is anything to be done on the Shibboleth side
>> of things ­ but I wanted to let others know and perhaps someone will
>> have some info that I don¹t. But I am looking to log a bug with
>> Apple.
>
>To complete the loop (Tom S has just set a pointer from there to
>here): Here's the start of a related thread, mentioned (but not
>referenced) by Scott on this list earlier:
>https://www.terena.org/mail-archives/tf-emc2/msg02135.html>-peter
>--
>To unsubscribe from this list send an email to
>[hidden email]

Re: Safari 5.1.5, Shibboleth, and an interesting Reverse Proxy setup

Thanks for the update. I'm still under the impression that there isn't any
standard Shibboleth behavior that is vulnerable to this bug, but if that's
not the case, please let us know with the security reporting form.

(I know it's not our bug regardless, but if there were something we did
that was vulnerable to it, and we could work around it, it may still be
justifiable.)