3 ms·
> So close and yet … their misconfigured clients will still be sending keys over unencrypted streams. Doh And how does disabling the HTTP interface altogether
by 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