Revisiting the Defaulting of cookieProps, handlerSSL, etc.

[Nate Klingenstein]

>> I'm running an Installfest in Saskatoon, and one of the
>> deployers(responsible for penetration testing in his day job) was
>> curious as to why we still default to supporting access to handlers
>> and to content hosted on HTTP.
>
> A lot of people run it that way, and virtually all initial testers do.

The appeal of keeping the bar as low as possible for initial testers  
is strong for me.

>> While it's easy enough to enable
>> secure cookies and SSL-only access, some deployers may be overlooking
>> that and leaving themselves vulnerable to trivial session hijacking  
>> as
>> a result(particularly with checkAddress and consistentAddress
>> defaulting to false, though that's for arguably better reasons).
>
> consistentAddress does not default to false. I would prefer  
> checkAddress
> didn't either, but that was the community view at one time.

I'd forgotten that and that's great, but I don't think it really helps  
in the most common session cookie theft environment, e.g. wireless  
networks that are then NAT'ted to the Internet.

>> Would it make sense to revisit the distribution config and/or  
>> defaults
>> so that deployers who wanted to support HTTP would have to make the
>> configuration changes, and not those who would like to ensure secure
>> access?
>
> If somebody else wants to answer all the questions, sure.

If I could be as fast as you at responding to queries on the users'  
list... ;D

> Probably the compromise would be to define some shorthand tokens that
> represent baseline deployment assumptions and that would be more
> self-evidently bad for production use, but it still implies somebody
> making a change before production. But if you don't even do that to  
> start
> with, I'm not sure what I could do that would make that happen.

I like the suggestion of these tokens in addition to the current fully  
customizable model.  While you're right about still requiring active  
cogitation, I see value in making it easier for deployers to feel flip  
all of the relevant security bits(whose flipping could be  
consolidated) and feel confident they got them all; right now there  
are a few different changes and I could imagine people missing one.

I'm content to use the "initial testers" and "question deluge" answers  
as reason enough on the defaults, but would encourage others to weigh  
in.

Thanks for the thoughts,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20120614/c0e03202/attachment.html