Delay network errors to prevent port scanning

[annevk]

See https://www.ietf.org/proceedings/96/slides/slides-96-saag-1.pdf for details.

I'm not entirely sure what the best way to do this is. Perhaps just include a recommendation somewhere that all network errors are delayed to make port scanning harder.

(Note that although the slides mention WebSocket, it's likely to be more generally applicable.)

Reportedly Firefox already throttles network errors.

[mcmanus]

as I mentioned at the mic - there are positive use cases involving errors that need to be included in the analysis here.. failover, etc.

happy-eyeballs looks a lot like port scanning.

and its not enough to delay errors.. you need to make errors and success operate in a fixed time as some errors are faster than success (TCP RST) and some are slower (unbound ports that don't generate ICMP) and the definition of how long success takes covers the range of about 1ms to 2000ms.

not an easy problem - perhaps not worthwhile?

[annevk]

@mcmanus @mnot mentioned Firefox already has mitigations, is that not the case? I think at the very least we should acknowledge the existence of this problem in the security section and maybe also mention https://en.wikipedia.org/wiki/Happy_Eyeballs and such as to why it's a non-trivial problem.

[mcmanus]

The linked presentation specifically talks about websockets and the rate limits built into that spec - and then talks about workers being able to bypass the rate limit - Firefox doesn't allow that (because the limit is global).

But that's a small detail - the issue, to the extent this is an issue at all, is much broader that websockets.

I'm not convinced this is a huge exposure, but its certainly worth a little text explaining what same-origin protects you against and what it doesn't.