undefined | Better HN

0 pointsdavedx1y ago0 comments

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

0 comments

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

piperswe1y ago

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

whoopdedo1y ago

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.

lxgr1y ago

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.

wild_egg1y ago

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

lxgr1y ago

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

1 more reply

aniviacat1y ago

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

haileys1y ago

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.

j / k navigate · click thread line to collapse

0 comments

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

piperswe1y ago

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

whoopdedo1y ago

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.

lxgr1y ago

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 with "TCP fast open", it would definitely not work.

wild_egg1y ago

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

lxgr1y ago

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

1 more reply

aniviacat1y ago

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

haileys1y ago

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.

j / k navigate · click thread line to collapse