Hacker News Reader

Comment by blahyawnblah | Hacker News Reader

Don't have HTTP available at all

That'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.

It 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

> 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.

If the client can't open a TCP connection to port 80, there's no unencrypted path to send the API keys down

TCP handshake failure prevents the client from being able to send any data, no?

Often, but not always: https://en.wikipedia.org/wiki/TCP_Fast_Open

> TFO has been difficult to deploy due to protocol ossification; in 2020, no Web browsers used it by default.[2]

It's in use by Android for DNS over TLS. Ossification issues are exaggerated.

Would disabling HTTP change that? Would TCP figure out the connection isn't working before the api keys are sent?

Yes 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.

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).

This is better, and the only way to really prevent the primary problem. Why would an API be on HTTP at all?

Why 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

> 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?

Why does everything have to be so complicated?

Reply on news.ycombinator.com