> 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.
> 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
> 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.
Not 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.
I'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.
The 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.
That’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).
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
> 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 invalidate API keys submitted insecurely
Why 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?
