On Sat, Jun 30, 2018 at 11:19 AM, Peter J. Holzer <hjp-pyt...@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 <ma...@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. -- https://mail.python.org/mailman/listinfo/python-list