5 ms·

They mention that 'Default Timeouts' have been disabled. Urging users to 'Act according to your threat model!'. I'm not sure I understand. How is not having th

by haarts 9y ago

They mention that 'Default Timeouts' have been disabled. Urging users to 'Act according to your threat model!'. I'm not sure I understand. How is not having these timeouts a security thread? Someone could potentially open up enough HTTP connections to starve others from having the opportunity to do so?

titanomachy 9y ago
Yeah, you could take all the file descriptors by opening a whole bunch of connections.
mholt 9y ago
This is true; but slowloris attacks don't require opening as many connections. We've seen one or two instances where buggy (or malicious?) clients were slowlorising Caddy instances; but we were too eager to enable timeouts by default I think.
- zzzcpan 9y ago
  No, not having timeouts is rather bad practice. There are a lot of clients out there that never close connections for various reasons. And since TCP doesn't use healthchecks and most systems by default have limits on the number of descriptors per process, your web server in default configuration will simply leak descriptors and memory over time until the whole thing stops working. The only sane choice here is to have timeouts enabled everywhere and explicitly allow them to be disabled, not the other way around.
  - mholt 9y ago
    Believe me, we wanted to do this, but it broke a lot of WebSocket connections and other legitimate, long-lived connections. It confused many users. It's hard to know what is legitimate and what is not. I wish we could configure timeouts on a per-request basis but not without some serious hacking around the net/http lib for now. I do encourage setting timeouts when you are able to. It's easy, for example: timeouts 30s I have heard of occasions where people have done this and it made their servers breathe again. At this point it's just up to your discretion/judgment.
    - zzzcpan 9y ago
      If I remember correctly, websockets have ping/pong support on both ends for that. So to handle them properly you have to detect connection upgrades and then start issuing ping requests to clients periodically, closing their connections if they fail to respond in time, but still using timeouts everywhere.
    - Sphax 9y ago
      Yeah, after an upgrade of Caddy on my server the syncthing ui broke. Not sure why but with timeouts the ui just doesn't work. It was a little surprising but I think it's more a problem syncthing should solve.

by haarts 9y ago

titanomachy 9y ago

Yeah, you could take all the file descriptors by opening a whole bunch of connections.

mholt 9y ago

This is true; but slowloris attacks don't require opening as many connections. We've seen one or two instances where buggy (or malicious?) clients were slowlorising Caddy instances; but we were too eager to enable timeouts by default I think.

zzzcpan 9y ago
No, not having timeouts is rather bad practice. There are a lot of clients out there that never close connections for various reasons. And since TCP doesn't use healthchecks and most systems by default have limits on the number of descriptors per process, your web server in default configuration will simply leak descriptors and memory over time until the whole thing stops working. The only sane choice here is to have timeouts enabled everywhere and explicitly allow them to be disabled, not the other way around.
- mholt 9y ago
  Believe me, we wanted to do this, but it broke a lot of WebSocket connections and other legitimate, long-lived connections. It confused many users. It's hard to know what is legitimate and what is not. I wish we could configure timeouts on a per-request basis but not without some serious hacking around the net/http lib for now. I do encourage setting timeouts when you are able to. It's easy, for example: timeouts 30s I have heard of occasions where people have done this and it made their servers breathe again. At this point it's just up to your discretion/judgment.
  - zzzcpan 9y ago
    If I remember correctly, websockets have ping/pong support on both ends for that. So to handle them properly you have to detect connection upgrades and then start issuing ping requests to clients periodically, closing their connections if they fail to respond in time, but still using timeouts everywhere.
  - Sphax 9y ago
    Yeah, after an upgrade of Caddy on my server the syncthing ui broke. Not sure why but with timeouts the ui just doesn't work. It was a little surprising but I think it's more a problem syncthing should solve.