3 ms·
Don't have HTTP available at all
by blahyawnblah 2y ago
Don't have HTTP available at all
- lxgr 2y agoThat's literally what the article suggests: > A great solution for failing fast would be to disable the API server's HTTP interface altogether and not even answer to connections attempts to port 80.
- davedx 2y agoIt also says > We didn't have the guts to disable the HTTP interface for that domain altogether, so we picked next best option: all unencrypted HTTP requests made under /api now return a descriptive error message along with the HTTP status code 403. So close and yet … their misconfigured clients will still be sending keys over unencrypted streams. Doh
- hn_throwaway_99 2y ago> So close and yet … their misconfigured clients will still be sending keys over unencrypted streams. Doh And how does disabling the HTTP interface altogether prevent that? In that case, any sensitive credentials are still already sent by the client before the server can do anything.
- whoopdedo 2y agoNot if the server refuses a connection on port 80. addendum: How quickly can a server write a 403 response and close the connection and can it be done before the client is able to write the entire HTTP request? My guess is not fast enough.
- lxgr 2y agoI'd be surprised if most HTTP clients even looked at the response code before writing at least the entire HTTP request (including authentication headers) out to the TCP send buffer. And if they do that, even if they immediately close the TCP socket upon seeing the 403, or even shut down their process, I believe most socket implementations would still write out the queued send buffer (unless there's unread inbound data queued up at the time of unclean socket close, in which case at least Linux would send an RST). And with "TCP fast open", it would definitely not work.
- piperswe 2y agoIf the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down
- wild_egg 2y agoTCP handshake failure prevents the client from being able to send any data, no?
- lxgr 2y agoOften, but not always: https://en.wikipedia.org/wiki/TCP_Fast_Open https://en.wikipedia.org/wiki/TCP_Fast_Open
- aniviacat 2y agoWould disabling HTTP change that? Would TCP figure out the connection isn't working before the api keys are sent?
- haileys 2y agoYes disabling HTTP would prevent keys being sent if the remote end isn't listening, unless TCP Fast Open is in use, which it is not by default.
- davedx 2y agoThis is better, and the only way to really prevent the primary problem. Why would an API be on HTTP at all?
- Aachen 2y agoWhy is it better? I can't think of large differences. What comes to mind are two human factors that both speak against it: - Having an HTTP error page informs the developer they did something wrong and they can immediately know what to fix, instead of blindly wondering what the problem is or if your API is down/unreliable - That page, or a config comment, will also inform the sysadmin that gets hired after you retire comfortably that HTTP being disabled is intentional. Turning something off that is commonly on might be a time bomb waiting for someone who doesn't know this to turn it back on Edit: Just saw this reason, that's fair (by u/piperswe) https://news.ycombinator.com/item?id=40505545 https://news.ycombinator.com/item?id=40505545 > If the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down If that immediately errors out on the first try, though, what is the risk of the key being intercepted? The dev would never put that in production, so I'm not sure how the pros and cons stack up. I also loved this suggestion from u/zepton which resolves that concern: https://news.ycombinator.com/item?id=40505525 https://news.ycombinator.com/item?id=40505525 invalidate API keys submitted insecurely
- davedx 2y agoWhy spend effort on this at all? Just don't run anything on HTTP. Devs don't need hand holding. Should you run your API on `localhos` in case they typo the hostname? Why does everything have to be so complicated?
- rascul 2y agoThe argument I've heard against not having HTTP at all is that potentially someone might be able to run something malicious on port 80 for that address that the admin is not aware of. People can make up their own minds if that's a good argument or not.
- HL33tibCe7 2y agoThat’s a terrible argument. If someone can run something on port 80, they have root on the machine, at which point can do whatever they want (including getting rid of whatever existing process was listening on port 80 and replacing it with their own).