[Rack] Noisebridge Domain Question

[Andy Isaacson]

On Thu, Dec 06, 2012 at 07:13:30PM -0800, Rubin Abdi wrote:
> Andy Isaacson wrote, On 2012-12-06 10:19:
> > If we provide a HTTP-only redirect at noisebridge.com then a MITM can
> > intercept there.
> 
> Correct me if I'm wrong, but a MITM attack can happen regardless of what
> that domain is doing, or not doing (like in its current state).

Note that I'm neglecting a SSL-MITM-with-CA-forgery attacker here, I'm
just referring to simple http-over-TCP MITM.

The noisebridge.net domain is protected against MITM by STS in some
circumstances (though unfortunately not all) even when users don't type
https:// explicitly.  Enabling a non-SSL redirect on .com and .org would
cause some legitimate use cases to be vulnerable to MITM even in STS
browsers, in an ongoing way.

Suppose we do not buy SSL certs for .com and .org.  Then the host they
point at should only listen on port 80 (not 443) to provide a less awful
user experience.  Therefore a user who visits .com must do so over HTTP,
and a MITM can interpose.  The user will observe that "the site works
OK" on .com and may continue to use the .com name, which is easily
MITMed.

By contrast, our .net site implements STS.  As a result, STS-compliant
browsers won't even *try* unencrypted HTTP even if the user explicitly
types http://www.noisebridge.net in the URL bar (it should be
transparently upgraded to https://).  In the situation where STS works,
the user cannot be MITMed even if they use a http:// link for whatever
reason.

Unfortunately STS only works under limited circumstances:
 - if the browser supports STS, and either
 - the browser has the STS whitelist (Chrome or Chromium)
 - the browser has cached the STS headers from an earlier visit

but that's a big enough population that I'd prefer to find a solution
that does not result in setting up redirectors that are insecure, and
ideally without paying the certificate mafia for more certs (but I'd be
willing to pay for certs if we can come up with a solution).

FWIW, the STS preload list is documented here:
http://dev.chromium.org/sts
http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state_static.json

-andy