Revisiting the Defaulting of cookieProps, handlerSSL, etc.

[Cantor, Scott]

On 6/14/12 12:27 PM, "Nate Klingenstein" <ndk at internet2.edu> wrote:

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

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

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

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.

-- Scott