On Thu, Dec 6, 2012 at 10:38 AM, Danny O'Brien <span dir="ltr"><<a href="mailto:danny@spesh.com" target="_blank">danny@spesh.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Dec 6, 2012 at 10:19 AM, Andy Isaacson <<a href="mailto:adi@hexapodia.org">adi@hexapodia.org</a>> wrote:<br>
> On Thu, Dec 06, 2012 at 12:54:29AM -0800, James Sundquist wrote:<br>
>> On 12/5/2012 11:02 AM, Rubin Abdi wrote:<br>
>> >It would be great if (*.)<a href="http://noisebridgenet.org" target="_blank">noisebridgenet.org</a> and .com at just port 80<br>
>> >would do an http redirect over to <a href="http://noisebridge.net:443" target="_blank">noisebridge.net:443</a>, ignoring anything<br>
>> >coming into port 443. If I was asked to make a guess I would say that<br>
>> >the majority of hits to those two TLDs would be for port 80 and not 443.<br>
>> >If someone's hitting 443 they're simply sorely misinformed and are most<br>
>> >likely educated enough to try knocking on 80 next.<br>
>><br>
>> For me, access through https is far less important than the website<br>
>> simply connecting to somewhere other than an error message.  Getting<br>
>> Port 80 working sounds like a reasonable place to start.<br>
><br>
> <a href="http://noisebridge.net" target="_blank">noisebridge.net</a> is secure by default; we only provide service over HTTPS<br>
> due to Strict Transport Security headers and the Chrome STS list.  As a<br>
> result if someone types "<a href="http://noisebridge.net" target="_blank">noisebridge.net</a>" in the URL bar they're<br>
> protected over HTTPS even if they didn't ask for it.<br>
><br>
> If we provide a HTTP-only redirect at <a href="http://noisebridge.com" target="_blank">noisebridge.com</a> then a MITM can<br>
> intercept there.<br>
><br>
> This isn't a complete dealbreaker, but it is unfortunate.<br>
><br>
<br>
</div>We're kind of a poster child for doing https right, with our<br>
certificate pinned in Chrome, and no http redirects. I'm open to<br>
arguments as to why we should break that for resolving<br>
<a href="http://noisebridge.com" target="_blank">noisebridge.com</a>, but honestly, I don't really see why resolving<br>
<a href="http://noisebridge.com" target="_blank">noisebridge.com</a> is important yet. <a href="http://noisebridge.net" target="_blank">noisebridge.net</a> is the address, and<br>
going to <a href="http://noisebridge.com" target="_blank">noisebridge.com</a> does what going to the wrong web site<br>
normally does.<br></blockquote><div><br></div><div>If this is a worthy goal, and something we'd like to stick with (I think so), then there is no reason to add the redirects.</div><div><br></div><div>They'd only be useful for users that don't know our domain and we'd just like to opportunistically redirect.</div>
<div>I don't see any great harm in redirecting them to the correct domain, though it's totally a point at which someone could be MITMing and redirecting to <a href="http://nosebridge.net">nosebridge.net</a>. :p</div>
<div><br></div><div><br></div><div>I see two types of users and use cases here though:</div><div>- Average web user just wants access to the Noisebridge site. Doesn't care about TLS security.</div><div>- Hacker cares about crafting the most secure connections and verifying data integrity. Just because.</div>
<div><br></div><div>I think we could appease both groups by running the redirectors</div><div>.</div><div>If you're in camp #1, noisebridge.{popular TLD} works, and if you're in camp #2, then the user probably cares enough to enter the right domain.</div>
<div>It's not like we're not already redirecting on <a href="http://noisebridge.net">noisebridge.net</a>, TCP/80 anyway. Though Chromium users will probably go TLS first with the STS pinning.</div><div><br></div><div>
--j</div></div><br></div>