FireFox3 shib redirection issue

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

FireFox3 shib redirection issue

Ray Steers
We are having issues with FF3 not working correctly when attempting to log in to our shib 1.3 protected app. It works perfectly in all other browsers.

After the IdP login page authenticates the username and password, upon redirection back to our app the user will get a blank white page. You cannot
view source on this page but if you do a file save in the browser you can see that it is really the /etc/shibboleth/sessionError.html template filled
out with the datetime stamp the the error:

"SAML 1.x Browser/POST handler does not support HTTP method (GET)"

the apache error logs on a successful shib login (FF2, IE6, IE7) look like this:

85.130.6.120 - - [30/Sep/2008:22:41:19 -0700] "GET /238 HTTP/1.1" 302 494
85.130.6.120 - - [30/Sep/2008:22:50:42 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 302 316

but an unsuccessful FF3 login attempt looks like this:

66.213.255.190 - - [19/Sep/2008:10:52:33 -0700] "GET /238/ HTTP/1.1" 302 494
66.213.255.190 - - [19/Sep/2008:10:52:52 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 200 1093

you can see that the 302 redirection code is now a 200 OK code and the 1093 bytes equal the size of the error msg page.

Has anyone had any experience like this? It's been driving me nuts for quite a while now. The behavior is the same across thousands of users from
major medical research Universities across the country. They upgrade to FF3 and this happens. It does not matter which IdP/cert/cookie/etc. as far as
i can tell.

Also if i turn the error log in apache up to debug then I get this:

Apache function (ap_get_brigade) failed while reading profile submission.

Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
> We are having issues with FF3 not working correctly when attempting to log
> in to our shib 1.3 protected app. It works perfectly in all other
browsers.

Well, it works fine in FF3 also, so the problem here is most likely your
server and/or your local network configuration. Since the server doesn't
care what the browser is, generally, you would want to acquire a packet
trace to identify what FF3 is sending differently.

I don't think 2.x will fix this, but it's almost a certainty that there
won't be a fix for 1.3 and you should verify that the problem still exists.

> but an unsuccessful FF3 login attempt looks like this:
>
> 66.213.255.190 - - [19/Sep/2008:10:52:33 -0700] "GET /238/ HTTP/1.1" 302
494
> 66.213.255.190 - - [19/Sep/2008:10:52:52 -0700] "POST
> /Shibboleth.sso/SAML/POST HTTP/1.1" 200 1093
>
> you can see that the 302 redirection code is now a 200 OK code and the
1093
> bytes equal the size of the error msg page.

That error message cannot occur unless it reports the method as GET. So it's
doing something it isn't logging.

> Also if i turn the error log in apache up to debug then I get this:
>
> Apache function (ap_get_brigade) failed while reading profile submission.

I'm not logging the actual error code returned by that function, which I can
fix (in 2.2), but it's really a sanity check that shouldn't fail, and I
can't fix it if it does. I can't make Apache give me the POST, all I can do
is ask for it. If it fails, I throw an exception that has that message in
it. Since your error page doesn't have that message, Apache is apparently
turning the failed POST into a GET, for reasons I can't explain.

First, you need to use the latest SP. Then, if you have a proxy, or any
other kind of firewallish device between your clients and the web server, my
advice is to get it out of the way and try it again. If that doesn't help,
I'd get a packet trace.

As a last resort, there's always artifacts, but many older IdPs won't
support them.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

R Andrew Johnston
In reply to this post by Ray Steers

Hi Ray,

Is it intentional that the GET requests are for different
Request-URIs?

--
andrew


On Mon, 12 Jan 2009, Ray Steers wrote:

>
> the apache error logs on a successful shib login (FF2, IE6, IE7) look like this:
>
> 85.130.6.120 - - [30/Sep/2008:22:41:19 -0700] "GET /238 HTTP/1.1" 302 494
> 85.130.6.120 - - [30/Sep/2008:22:50:42 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 302 316
>
> but an unsuccessful FF3 login attempt looks like this:
>
> 66.213.255.190 - - [19/Sep/2008:10:52:33 -0700] "GET /238/ HTTP/1.1" 302 494
> 66.213.255.190 - - [19/Sep/2008:10:52:52 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 200 1093
>
> you can see that the 302 redirection code is now a 200 OK code
> and the 1093 bytes equal the size of the error msg page.
>

Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Ray Steers
In reply to this post by Cantor, Scott E.
Scott-

thanks for taking the time to answer.

ok so stupid question but how would i get a packet trace?

we are attempting to build a 2.0 SP but currently don't have the manpower to get it done soon enough. But I will try with testshib if i need to.

there is a firewall in place, i can try to find an open IP and stick it in a dmz and run the server there but i don't think that is the problem.

i tried artifacts but couldn't get the system to work at all like that even in FF2. perhaps i didn't do it right.

also i think that I may be the only person using mod_shib with mod_jk AND mod_gnutls. perhaps i can get the test server to use mod_ssl instead, do
you think that could be an issue?

i was looking at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html and found:

     "Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client."

which made me think that FF3 might have "fixed" or changed some redirection behavior. I have found some posts about redirection differences that
might relate: http://jacky.seezone.net/2008/04/29/1983/ but i may be way off base here.

one of our dev guys had said something about FF3 not allowing cross-site cookies in the same way FF2 does and that might have something to do with
something?

I have a bunch of universities that I am using shib with all in production environments, so I am a bit afraid of switching to the 2.0 SP code.

>> We are having issues with FF3 not working correctly when attempting to log
>> in to our shib 1.3 protected app. It works perfectly in all other
> browsers.
>
> Well, it works fine in FF3 also, so the problem here is most likely your
> server and/or your local network configuration. Since the server doesn't
> care what the browser is, generally, you would want to acquire a packet
> trace to identify what FF3 is sending differently.
>
> I don't think 2.x will fix this, but it's almost a certainty that there
> won't be a fix for 1.3 and you should verify that the problem still exists.
>
>> but an unsuccessful FF3 login attempt looks like this:
>>
>> 66.213.255.190 - - [19/Sep/2008:10:52:33 -0700] "GET /238/ HTTP/1.1" 302
> 494
>> 66.213.255.190 - - [19/Sep/2008:10:52:52 -0700] "POST
>> /Shibboleth.sso/SAML/POST HTTP/1.1" 200 1093
>>
>> you can see that the 302 redirection code is now a 200 OK code and the
> 1093
>> bytes equal the size of the error msg page.
>
> That error message cannot occur unless it reports the method as GET. So it's
> doing something it isn't logging.
>
>> Also if i turn the error log in apache up to debug then I get this:
>>
>> Apache function (ap_get_brigade) failed while reading profile submission.
>
> I'm not logging the actual error code returned by that function, which I can
> fix (in 2.2), but it's really a sanity check that shouldn't fail, and I
> can't fix it if it does. I can't make Apache give me the POST, all I can do
> is ask for it. If it fails, I throw an exception that has that message in
> it. Since your error page doesn't have that message, Apache is apparently
> turning the failed POST into a GET, for reasons I can't explain.
>
> First, you need to use the latest SP. Then, if you have a proxy, or any
> other kind of firewallish device between your clients and the web server, my
> advice is to get it out of the way and try it again. If that doesn't help,
> I'd get a packet trace.
>
> As a last resort, there's always artifacts, but many older IdPs won't
> support them.
>
> -- Scott
>
>
>


Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

Ray Steers
In reply to this post by R Andrew Johnston
oh wow i can't believe i didn't see that trailing slash difference.
thanks i'll look into that and see if it is consistent across the logs.


>
> Hi Ray,
>
> Is it intentional that the GET requests are for different
> Request-URIs?
>
> --
> andrew
>
>
> On Mon, 12 Jan 2009, Ray Steers wrote:
>>
>> the apache error logs on a successful shib login (FF2, IE6, IE7) look like this:
>>
>> 85.130.6.120 - - [30/Sep/2008:22:41:19 -0700] "GET /238 HTTP/1.1" 302 494
>> 85.130.6.120 - - [30/Sep/2008:22:50:42 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 302 316
>>
>> but an unsuccessful FF3 login attempt looks like this:
>>
>> 66.213.255.190 - - [19/Sep/2008:10:52:33 -0700] "GET /238/ HTTP/1.1" 302 494
>> 66.213.255.190 - - [19/Sep/2008:10:52:52 -0700] "POST /Shibboleth.sso/SAML/POST HTTP/1.1" 200 1093
>>
>> you can see that the 302 redirection code is now a 200 OK code
>> and the 1093 bytes equal the size of the error msg page.
>>
>
>


Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

Peter Schober
In reply to this post by Ray Steers
* Ray Steers <[hidden email]> [2009-01-13 18:36]:
> ok so stupid question but how would i get a packet trace?

Turn off ssl and use tcpdump(1) toghether with a protocol analyzer
(e.g. wireshark)?
Also I expect there to be proxy servers that allow to simply build
your own man-in-the-middle attack (by providing them with the cert/key
pair of the server thery're proxying to).

> which made me think that FF3 might have "fixed" or changed some
> redirection behavior. I have found some posts about redirection
> differences that might relate

I really think if FF3 breaks HTTP 302s *someone* else on this list
would have noticed? My Foxens certainly behave.

> one of our dev guys had said something about FF3 not allowing
> cross-site cookies in the same way FF2 does and that might have
> something to do with something?

Shibboleth only uses host cookies, not domain cookies, and I don't
know what "cross-site cookies" should be (if an HTTP User-Agent
presented cookies set in example-A.org to example-B.org then maybe we
wouldn't neet Shibboleth).

> I have a bunch of universities that I am using shib with all in
> production environments, so I am a bit afraid of switching to the
> 2.0 SP code.

Short of a show of hands for people using both shib2 and FF I think
you're on the wrong track (but what do I know).
cheers,
-peter

--
[hidden email] - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
In reply to this post by Ray Steers
> ok so stupid question but how would i get a packet trace?

Peter mentioned one way, I also use ssldump at times, which can handle SSL
inbound and get a tcpdump compatible trace.

What I'm trying to say is that this probably isn't something the SP can fix.
It's a low-level HTTP or TCP issue that's causing the server to fail to
return the posted data from the client. I can't fix that where I'm located
in the stack, barring somebody stepping up with a lot of Apache expertise to
explain why the code I have is wrong.

I happen to know that there are other cases in which Apache fails to sync
with the client, causing timeouts or truncation, even with standard CGI. It
happens under very rare and specific network configs, but it happens to be
common to OSU's network, so I'm quite aware of it. I also can't fix it. It
might be related to your issue and might not be.

The only fix on the SAML end is to switch to artifacts. My IdP doesn't
happen to support that, so I'm stuck in my particular case.

> we are attempting to build a 2.0 SP but currently don't have the manpower
to
> get it done soon enough. But I will try with testshib if i need to.

That isn't going to help you much. The bug is in your network. FF3 is known
to work fine with the SP. I use it as my default browser.

> there is a firewall in place, i can try to find an open IP and stick it in
a
> dmz and run the server there but i don't think that is the problem.

I'm willing to bet you a beer that it is, particular if it's a very stateful
firewall doing packet inspection or proxying.

> i tried artifacts but couldn't get the system to work at all like that
even
> in FF2. perhaps i didn't do it right.

Artifacts work fine, they just aren't widely used.
 
> also i think that I may be the only person using mod_shib with mod_jk AND
> mod_gnutls. perhaps i can get the test server to use mod_ssl instead, do
> you think that could be an issue?

No idea, but yeah, I wouldn't exactly say that's well tested. Again, would
be very likely to work better with 2.x since there can't be any SSL
conflicts in that version.
 
> which made me think that FF3 might have "fixed" or changed some
redirection
> behavior. I have found some posts about redirection differences that
> might relate: http://jacky.seezone.net/2008/04/29/1983/ but i may be way
off
> base here.

While 303 is a more technically correct code, I can't be doing User Agent
tests to determine what code to use. 302 is the historical one people tend
to use. In this case, were the client to treat that as a request to POST to
the location, you have to understand the flow here:

POST to IdP -> returns form
Form autosubmit to /Shibboleth.sso/SAML/POST -> 302 to URL from relay
state/target
GET to resource URL

You are NOT seeing a POST to the resource URL. That would be the "change"
you're implying. Instead you're seeing a POST to the SP that Apache fails
and then somehow invokes as a GET on the server side (no client request
logged as a GET). It's a mess.

> one of our dev guys had said something about FF3 not allowing cross-site
> cookies in the same way FF2 does and that might have something to do with
> something?

No.

> I have a bunch of universities that I am using shib with all in production
> environments, so I am a bit afraid of switching to the 2.0 SP code.

You should be more afraid of running 1.3 long term, not of switching.
Moreover, there is no 1.3.2 planned, and if there were a fix for this issue,
I still wouldn't be doing one just for that. So you can anticipate that if
there is a fix, you'd have to be running snapshot code, or upgrading to 2.x
to get a fix.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
In reply to this post by Peter Schober
> I really think if FF3 breaks HTTP 302s *someone* else on this list
> would have noticed? My Foxens certainly behave.

It has been on my TODO list to add some kind of option to use 303 instead. I
would not take that leap myself, but it is the technically correct code.

One problem is that a lot of the server APIs tend to "abstract" redirection,
and if you tell them "send a redirect", they return a 302.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Ray Steers
In reply to this post by Cantor, Scott E.
well you owe me a beer. I set up the exact same stuff with no firewall at all and got the same behavior.
FF2 works fine, FF3 does not.

>> there is a firewall in place, i can try to find an open IP and stick it in
> a
>> dmz and run the server there but i don't think that is the problem.
>
> I'm willing to bet you a beer that it is, particular if it's a very stateful
> firewall doing packet inspection or proxying.
>

guess I am onto having to grab the tcp stream and analyze it. that sounds fun....

Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Ray Steers
In reply to this post by Cantor, Scott E.
ok i now owe you a beer again.
Turns out it was the mod_gnutls module. when I used mod_ssl it works fine.
that should have been the first thing I did. Now I just have to figure out how to run multiple shib protected apps on the same server with different
urls without using mod_gnutls.

thanks for all the help people.

>> also i think that I may be the only person using mod_shib with mod_jk AND
>> mod_gnutls. perhaps i can get the test server to use mod_ssl instead, do
>> you think that could be an issue?
>
> No idea, but yeah, I wouldn't exactly say that's well tested. Again, would
> be very likely to work better with 2.x since there can't be any SSL
> conflicts in that version.


Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
In reply to this post by Ray Steers
Ray Steers wrote on 2009-01-16:
> well you owe me a beer. I set up the exact same stuff with no firewall at
> all and got the same behavior.
> FF2 works fine, FF3 does not.

Is your URL accessible? I can easily trace the activity from my client.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
In reply to this post by Ray Steers
Ray Steers wrote on 2009-01-16:
> Turns out it was the mod_gnutls module. when I used mod_ssl it works fine.
> that should have been the first thing I did. Now I just have to figure out
> how to run multiple shib protected apps on the same server with different
> urls without using mod_gnutls.

You'll have to run that by me again. Are you trying to use some kind of
"startTLS" approach to get away with multiple certificates on the same
IP/port? There is no way to do that with mod_ssl, that's for sure.

Can you determine whether mod_cgi alone with mod_gnutls works if you try
some posts? Basically is it a bug in mod_shib (that I probably don't know
how to fix, but still) or a bug in mod_gnutls?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Ray Steers
ok here goes:

I am running mod_shib, mod_jk, and mod_gnutls all at the same time.

We have a java web app that runs inside a Tomcat container. and we run multiple
apps (sometimes as many as 20) inside the container.

Normally without shib those apps are accessible at urls like:
(they could be completely different tlds, instead of all cayuse424.com's fyi)

https://benaroyaresearch.cayuse424.com:8443/262
https://fullerton.cayuse424.com:8443/265
https://udel.cayuse424.com:8443/259
https://udel-casdev.cayuse424.com:8443/260

if you were to check you would see that those all resolve to app8.cayuse424.com (69.30.48.148)
and are therefore all inside the same container. you could get to them like this if you wanted:

https://app8.cayuse424.com:8443/262
https://app8.cayuse424.com:8443/265
https://app8.cayuse424.com:8443/259
https://app8.cayuse424.com:8443/260

but since they need to be front-ended by apache on port 443 to do shib,
I used mod_gnutls along with mod_jk to do both SNI and a JkMount

since mod_ssl cannot do this i used mod_gnutls.

so somewhere in the interaction of mod_gnutls and FF3 something is happing to change the redirect
from a POST to a GET. (i guess)

I was going to go thorough all the mod_gnutls settings and see if i could find something.
and also post to their board as well.

> Ray Steers wrote on 2009-01-16:
>> Turns out it was the mod_gnutls module. when I used mod_ssl it works fine.
>> that should have been the first thing I did. Now I just have to figure out
>> how to run multiple shib protected apps on the same server with different
>> urls without using mod_gnutls.
>
> You'll have to run that by me again. Are you trying to use some kind of
> "startTLS" approach to get away with multiple certificates on the same
> IP/port? There is no way to do that with mod_ssl, that's for sure.
>
> Can you determine whether mod_cgi alone with mod_gnutls works if you try
> some posts? Basically is it a bug in mod_shib (that I probably don't know
> how to fix, but still) or a bug in mod_gnutls?
>
> -- Scott
>
>
>


Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

Peter Schober
* Ray Steers <[hidden email]> [2009-01-17 04:42]:
> Normally without shib those apps are accessible at urls like:
> (they could be completely different tlds, instead of all
> cayuse424.com's fyi)

The usual seperate A records or alternatively CNAMEs with all
hostnames in an x.509v3 SubjectAltNameextension are out of the
question?

> but since they need to be front-ended by apache on port 443 to do shib,
> I used mod_gnutls along with mod_jk to do both SNI and a JkMount
>
> since mod_ssl cannot do this i used mod_gnutls.

I didn't know about SNI but it seems there's support for this in
openssl (and possibly mod_ssl) for over a year now:
http://cvs.openssl.org/chngview?cn=16435
http://www.mail-archive.com/dev@.../msg39105.html

Maybe try recompiling part of your stack with this extension enabled?
Probably asking on the mailing lists first won't hurt.

cheers,
-peter
--
[hidden email] - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

Ray Steers
Peter-

> The usual seperate A records or alternatively CNAMEs with all
> hostnames in an x.509v3 SubjectAltNameextension are out of the
> question?

We have a lot of domains and getting new certs for all would not work.

> I didn't know about SNI but it seems there's support for this in
> openssl (and possibly mod_ssl) for over a year now:
> http://cvs.openssl.org/chngview?cn=16435
> http://www.mail-archive.com/dev@.../msg39105.html
>
> Maybe try recompiling part of your stack with this extension enabled?
> Probably asking on the mailing lists first won't hurt.

I found this link from one of the 2 you cited above: https://sni.velox.ch/

and it was updated just last week so I was able to work my way through it.
I remember finding this page a year ago and it was not mature enough to
get working at the time which is why i went with the mod_gnutls solution.

I did finally get a whole new apache compiled with this new patched mod_ssl
and got it working with mod_jk and mod_shib and sure enough it did the trick.
Works in FF3 just fine. Loads multiple certs to SNI capable browsers.

I am now wondering if this is a bug in mod_gnutls and if I should report it.

Thanks for your help!

Ray Steers
Technical Operations Manager
Cayuse, Inc.
Park Plaza West, Bldg III, Suite 654
10700 SW Beaverton Hillsdale Hwy
Beaverton, OR 97005
off 503-297-2108 x216 fax 503-297-0414 cell 503-916-9608
http://www.cayuse.com
Reply | Threaded
Open this post in threaded view
|

Re: FireFox3 shib redirection issue

Peter Schober
* Ray Steers <[hidden email]> [2009-01-18 03:04]:
> I did finally get a whole new apache compiled with this new patched
> mod_ssl and got it working with mod_jk and mod_shib and sure enough
> it did the trick.  Works in FF3 just fine. Loads multiple certs to
> SNI capable browsers.

Great! Glad it all worked out.

Cheers,
-peter

--
[hidden email] - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

Cantor, Scott E.
In reply to this post by Ray Steers
Ray Steers wrote on 2009-01-17:
> I did finally get a whole new apache compiled with this new patched
> mod_ssl and got it working with mod_jk and mod_shib and sure enough it
> did the trick. Works in FF3 just fine. Loads multiple certs to SNI
> capable browsers.

I note for the record that a typical site probably can't use this based on
the list of browsers that support SNI, which excludes such obviously common
cases as XP with IE6 or 7 (the only released/supported versions) and
arguably Firefox 1.

http://en.wikipedia.org/wiki/Server_Name_Indication

Too bad, maybe in a couple years.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: FireFox3 shib redirection issue

peter williams-3
Interesting to know if http://blogs.iis.net/thomad/archive/2008/01/25/ssl-certificates-on-sites-with-host-headers.aspx is true.

In Shib, inband PKI control signals within cert chains are not SUPPOSED to be enforced (apparently) when pulling metadata. Surely the openssl library distributed and used by Shib SP could be patched to conform with the profile (and ignore PKI signals)?

What we could now do is take a $15 public-CA issued cert, use the key to mint a new cert using openssl cert minting tools with multiple cn attribute values, use the version 1 format for said cert, and expect a Shib-conforming SAML entity resolving https URL in a metadata context to ignore the fact that the SSL cert chain offered by an IDP serving metadata has a v3-EE cert authenticating the v1 cert.

This would be cool for an openid-like usage of the Shib IDP. Each user could have their own entityID, and it could have URL form. Each user could be hosting their customized SAML metadata at their vanity URL, supported by https. The user's choice of SAML metadata then points to the user's sso endpoint at the IDP. So long as the SP doing discovery parses all 5 thousand values in the cn field of the serer cert, one cert for 5k https endpoints can support serving the metadata for all 5k users, each one routed there using the users own vanity URL.

Would be interesting to know if Apache refuses to even accept/serve an SSL chain of that form (a v1 cert tagged on the end of a classical v3 cert chain), or will even deliver handle certs with large cn= value multi-valued fields.

Would be interesting to know if openssl ssl client by default will process multiple cn= values, and what the practical limit is. (X.509 itself has no limits, though SSL record layer definition will impose a byte limit on an individual SSL3-certificate message, per handshake).

> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Sunday, January 18, 2009 11:40 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] FireFox3 shib redirection issue
>
> Ray Steers wrote on 2009-01-17:
> > I did finally get a whole new apache compiled with this new patched
> > mod_ssl and got it working with mod_jk and mod_shib and sure enough
> it
> > did the trick. Works in FF3 just fine. Loads multiple certs to SNI
> > capable browsers.
>
> I note for the record that a typical site probably can't use this based
> on
> the list of browsers that support SNI, which excludes such obviously
> common
> cases as XP with IE6 or 7 (the only released/supported versions) and
> arguably Firefox 1.
>
> http://en.wikipedia.org/wiki/Server_Name_Indication
>
> Too bad, maybe in a couple years.
>
> -- Scott
>