API Shouldn't Redirect HTTP to HTTPS • Hacker News Board

Re: API Shouldn't Redirect HTTP to HTTPS

#61

Post by Dylan16807 » Tue, May 28, 2024, 9:04 PM UTC

Aachen wrote: post #16

lxgr wrote: post #8

Completely agree, and arguably why stop at API servers? Depending on server-side HTTP -> HTTPS redirects for security reinforces/rewards bad practices (linking to HTTP, users directly entering HTTP etc.), in a way that makes users vulnerable to one of the few remaining attack vectors of "scary public Wi-Fis".

We are. Slowly, due to lots of legacy, but surely getting there. See the small steps over the years where it was first an add-on to force https-only mode (HttpsEverywhere, 2011), then browsers started showing insecure symbols for http connections (e.g. in 2019: https://blog.mozilla.org/security/2019/10/15/improved-securi... ), and more recently I think browsers are starting to try https before http when you don't spe…

Chrome's version of trying https first sure is annoying though.

If a site is down entirely, when chrome can't connect to port 443 it confidently declares that "the connection is not secure because this site does not support https" and gives a "continue" button. Then when you click "continue" nothing happens for a while before it finally admits there's nothing responding at all.

So it gives a misleading error and takes longer to figure out if a site is actually down.

Re: API Shouldn't Redirect HTTP to HTTPS

#62

Post by croes » Tue, May 28, 2024, 9:04 PM UTC

Maybe shttp would have been better than https to reduce typo errors or maybe even something completely different from http.

Re: API Shouldn't Redirect HTTP to HTTPS

#63

Post by superkuh » Tue, May 28, 2024, 9:05 PM UTC

ozim wrote: post #22

superkuh wrote: post #5

Or better: actually provide the API on HTTP and HTTPS if your use case allows it (ie, non-commercial/institutional, just something for human people).

That is an awful idea - in post Snowden world you encrypt all traffic period. Then you have post Jia Tan world - if there is even slightest remote possibility, you just don't want to be exposed. Just like washing hands after peeing, just do HTTPS and don't argue.

If that's your threat model then CA TLS is going to make things even worse for you because now the nation state pressure can be centralized and directed through the CA.

There are trade-offs but HTTP has it's place. HTTP is far easier to set up, more robust, far more decentralized, supports far more other software, and has a longer lifetime. For humans who aren't dealing with nation state threat models those attributes make it very attractive and useful.

We should not cargo cult the requirements for a multi-national business that does monetary transactions and sends private information with a website run by a human person for recreation and other humans. There is more to the web than commerce and we should design for human persons as well as corporate persons.

Re: API Shouldn't Redirect HTTP to HTTPS

#64

Post by haileys » Tue, May 28, 2024, 9:08 PM UTC

aniviacat wrote: post #52

davedx wrote: post #34

Earlier quoted context omitted.

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

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#65

Post by toomim » Tue, May 28, 2024, 9:09 PM UTC

croes wrote: post #62

Maybe shttp would have been better than https to reduce typo errors or maybe even something completely different from http.

Ah... you know, that idea sounds not too shtty to me.

Re: API Shouldn't Redirect HTTP to HTTPS

#66

Post by Wowfunhappy » Tue, May 28, 2024, 9:11 PM UTC

x86a wrote: post #10

superkuh wrote: post #5

Or better: actually provide the API on HTTP and HTTPS if your use case allows it (ie, non-commercial/institutional, just something for human people).

I don't think this is ever a good idea. Even for non-enterprise use cases, you wouldn't want some public hotspot to be able to inject random garbage into responses, even if not done with malicious intent.

• It allows retro computers to connect.

• It allows very low power embedded devices to connect without extra overhead.

• It's not a real security concern if you're on a private network.

Re: API Shouldn't Redirect HTTP to HTTPS

#67

Post by znpy » Tue, May 28, 2024, 9:13 PM UTC

zepton wrote: post #54

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

I've been thinking for about 5 minutes about this comment and what to write but i've come to the conclusion that this is really not the best thing to do, but the correct thing to do.

It's not different levels of good or bad... everything else is wrong.

Re: API Shouldn't Redirect HTTP to HTTPS

#68

Post by lxgr » Tue, May 28, 2024, 9:13 PM UTC

wild_egg wrote: post #60

hn_throwaway_99 wrote: post #44

Earlier quoted context omitted.

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

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

Re: API Shouldn't Redirect HTTP to HTTPS

#69

Post by ikisusi » Tue, May 28, 2024, 9:14 PM UTC

I hope that providers whose APIs responded and interacted fully over unencrypted HTTP would go back to their historical access logs and check how widespread using plaintext HTTP is. If they don't have access logs for their API then they could just sample next 24 hours for API accesses.

Popular providers have so many API users today that even a rare mistake could expose quite many users in absolute numbers. Would rather have providers to check this out rather than have this poor practice abused by the next DNS hijacking malware affecting home routers.

Re: API Shouldn't Redirect HTTP to HTTPS

#70

Post by lxgr » Tue, May 28, 2024, 9:20 PM UTC

whoopdedo wrote: post #55

hn_throwaway_99 wrote: post #44

Earlier quoted context omitted.

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