EXTERNAL: OSError: [Errno 48] Address already in use

[Dan Stromberg]

On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer <hjp-python at hjp.at> wrote:

> On 2018-06-28 18:04:16 -0700, Dan Stromberg wrote:
> > On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa <marko at pacujo.net>
> wrote:
> > Start an echo server process P that listens on tcp/5555.
> >
> > Initiate a connection from a client machine to process P at tcp/5555. It
> > works as expected.
> >
> > Kill P.
> >
> > Initiate a connection from a client machine to process P at tcp/5555.  It
> > gives a connection refused as expected.
> >
> > If someone else comes along soon after and starts a different echo server
> > process Q at tcp/5555 on the same server, it starts up immediately if P
> > used SO_REUSEADDR.
> >
> > Then initiate a connection from the same (or different) client machine to
> > process P (which no longer exists).  Q gets the data intended for P.
>
> I don't think this is the issue TIME_WAIT is intended to prevent.
>

It handles more than one thing.

Firstly, why would this security issue stop to be a security issue after
> two minutes?


It's a mitigation of both problems we've discussed.


> Secondly, it depends on the attacker not knowing about
> SO_REUSEADDR, which seems overly optimistic.
>
Not really, no.  People on remote machines know little about process
bounces.  And it's pretty easy to write a script that will check if a
process is up repeatedly, starting a daemon when its not.  And you don't
have to know about SO_REUSEADDR to write that script.

What TIME_WAIT is IMHO intended to prevent is mixing up two TCP
> connections:
>
Yes, it does this too.

This can be prevented by not restarting the server until all packets for
> old connections are guarantueed to have expired.
>

Yes, and not using SO_REUSEADDR helps this happen.


> In practice this scenario is pretty unlikely: Not only has the client
> have to get the same client port, it also needs to get the sequence
> numbers (which are 32 bit numbers chosen at random at connection time)
> just right.
>

Right, it's a mitigation.

OTOH, having to wait 2 minutes before you can restart your server is a
> nuisance. Therefore, everybody uses SO_REUSEADDR.
>
During development, it's a good practice to setsockopt SO_REUSEADDR.

In production, different rules may or may not apply.  On multiuser systems,
it's more important than on most of today's single-purpose virtual machines.

Some people feel that "security issues" must all be religiously 100%
avoided completely, or they'll offend the computer gods.  This evidences a
lack of understanding about the practical aspects of security issues.
Security is very much a spectrum - multidimensional even.