[Rack] Noisebridge Domain Question

[Andy Isaacson]

On Thu, Dec 06, 2012 at 11:31:53PM -0800, Rubin Abdi wrote:
> Danny O'Brien wrote, On 2012-12-06 22:08:
> >> 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).
> > Nah, redirecting allows a specific attack -- it's the specific reason
> > for HSTS and pinning, both of which Noisebridge is (kind of weirdly) a
> > specifically good example of. For a long time, it was basically just
> > us and Paypal doing things correctly.
> 
> Explain the attack? If someone wants to spoof DNS in some form and spit
> out a new IP address for noisebridge.com, I don't see any reason why
> that wouldn't work if noisebridge.com doesn't currently go anywhere.

If noisebridge.com doesn't work, people don't use it.  Some few people
will try to use it by accident, and if they do that on an evil network,
the attacker might proxy noisebridge.net content to them and
successfully MITM.  But by ensuring that noisebridge.com does not work
normally, we have done everything we can to avoid encouraging people to
use it.

So the attack that's enabled by the .com redirector is:

 - the .com redirector is not SSL
 - the user gets used to the .com redirector working and doesn't learn
   to carefully go to .net
 - the user uses the .com redirector (which after all, works under
   normal circumstances!) on an evil network and gets MITMed.

By contrast, without a .com redirector,

 - noisebridge does not host a non-SSL domain
 - users know due to experience that noisebridge.net is the right URL
 - STS headers or preload tell the browser to never try HTTP first,
   always use HTTPS.
 - user uses the noisebridge.net URL on an evil network and is protected
   from MITM by SSL.

Even in my ideal scenario, if the user tries the noisebridge.com URL on
an evil network they can be MITMed, which is unfortunate, but not
something we can help.  (At least we registered the domains so they
can't be squatted.)  But at least we didn't teach the user that the
insecure .com forwarder "works most of the time".

-andy