<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">I'm running an Installfest in Saskatoon, and one of the<br></blockquote><blockquote type="cite">deployers(responsible for penetration testing in his day job) was<br></blockquote><blockquote type="cite">curious as to why we still default to supporting access to handlers<br></blockquote><blockquote type="cite">and to content hosted on HTTP.<br></blockquote><br>A lot of people run it that way, and virtually all initial testers do.<br></div></span></blockquote><div><br></div><div>The appeal of keeping the bar as low as possible for initial testers is strong for me.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">While it's easy enough to enable<br></blockquote><blockquote type="cite">secure cookies and SSL-only access, some deployers may be overlooking<br></blockquote><blockquote type="cite">that and leaving themselves vulnerable to trivial session hijacking as<br></blockquote><blockquote type="cite">a result(particularly with checkAddress and consistentAddress<br></blockquote><blockquote type="cite">defaulting to false, though that's for arguably better reasons).<br></blockquote><br>consistentAddress does not default to false. I would prefer checkAddress<br>didn't either, but that was the community view at one time.<br></div></span></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><blockquote type="cite">Would it make sense to revisit the distribution config and/or defaults<br></blockquote><blockquote type="cite">so that deployers who wanted to support HTTP would have to make the<br></blockquote><blockquote type="cite">configuration changes, and not those who would like to ensure secure<br></blockquote><blockquote type="cite">access?<br></blockquote><br>If somebody else wants to answer all the questions, sure.<br></div></span></blockquote><div><br></div><div>If I could be as fast as you at responding to queries on the users' list... ;D</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>Probably the compromise would be to define some shorthand tokens that<br>represent baseline deployment assumptions and that would be more<br>self-evidently bad for production use, but it still implies somebody<br>making a change before production. But if you don't even do that to start<br>with, I'm not sure what I could do that would make that happen.</div></span></blockquote><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks for the thoughts,</div><div>Nate.</div></body></html>