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

Re: API Shouldn't Redirect HTTP to HTTPS

#231

Post by superkuh » Wed, May 29, 2024, 12:10 PM UTC

cqqxo4zV46cp wrote: post #81

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

How is this better in literally any way other than it makes things (in 2024, only very slightly) easier from an ops perspective, and panders to some nerdy fetish for simple ‘read it over wireshark’ protocols? HTTPS-only should be the default. Plain-text information delivery protocols that can easily be MITMd are unsuitable for almost all uses. This just feels like contrarianism.

I guess I have to respond with the same thing over and over because there are so many people saying the same thing without reading the replies.

HTTP is better because: it lasts forever without mantainence, it's easier to learn set up with no third parties required, all software can access a HTTP website, it's low resource requirements, and HTTP+HTTPS is perfectly fine.

Whereas CA TLS only lasts a year or two without mantainence, is so complex to set up and keep running that a literal ecosystem of programs (acme, acme2, etc) exist to hide that complexity, only software within the last ~few years can access CA TLS websites because of TLS version sunsetting and root cert expirations and the like, and everyone centralizing in the same CA makes it extremely easy to apply political/social pressures for censorship in a CA TLS only browser world. Additionally requiring third party participating to set up a website makes it harder for people to learn how to run their own and it requires more compute resources.

CA TLS only feels like it should be "required" when the person can't imagine a web browser that doesn't automatically run all untrusted code sent to it. When the only types of websites the person can image are commercial or institutional rather than personal and the person believes all the web should cargo cult the requirements of commerce. Personal websites involving no monetary or private information transactions don't actually need to worry about targeted MITM and there's no such thing as open wireless access points anymore.

Re: API Shouldn't Redirect HTTP to HTTPS

#232

Post by Thiez » Wed, May 29, 2024, 12:11 PM UTC

mid-kid wrote: post #224

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.

This sounds like a great way to cause Denial-of-Service attacks.

Denial of service by blocking API keys is really your happy case when someone malevolent has your API keys.

Re: API Shouldn't Redirect HTTP to HTTPS

#233

Post by UncleMeat » Wed, May 29, 2024, 12:14 PM UTC

Eduard wrote: post #134

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.

that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…

Nothing could possibly be bulletproof. You sent a key over the wire unencrypted. You were in trouble before the data even got to the server to do anything about it.

This approach is a practical choice based on the reality that the bulk of unencrypted traffic is not being actively mitmed and is at most being passively collected. Outside of actually developing cryptosystems, security tends to be a practical affair where we are happy building systems that improve security posture even if they don't fix everything.

Re: API Shouldn't Redirect HTTP to HTTPS

#234

Post by UncleMeat » Wed, May 29, 2024, 12:20 PM UTC

zzo38computer wrote: post #206

lxgr wrote: post #122

Earlier quoted context omitted.

What scary browser warnings do you regularly get when visiting HTTPS sites? It’s also not just about avoiding transmitting HTML etc. in plaintext; somebody being able to inject arbitrary scripts into sites you otherwise trust is bad as well. But as I've said above, I think the HTTP -> HTTPS redirect should have never happened at the HTTP level. If we'd done it in DNS or at least as a new HTTP header ("optional TLS av…

Scripts other than those that the user had specifically allowed, can also be a problem, whether or not it is with TLS. With TLS, only the server operator can add malicious scripts; without TLS, spies can also do so; either way, it can do so. Specifying availability of TLS (and, perhaps, which ciphers are usable, in order to avoid the use of insecure ciphers) by DNS would do, if you can (at the client's option) acquir…

If you are saying that people click through certificate warnings then people definitely would just permit whatever script. The number of people who will say "yeah its okay that this is a self-signed cert" and also say "no, I have a strict allowlist of verified scripts from this server that I allow to run" is miniscule.

Re: API Shouldn't Redirect HTTP to HTTPS

#235

Post by vitiral » Wed, May 29, 2024, 12:24 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.

Careful, someone might use that as an API! https://xkcd.com/1172/

Re: API Shouldn't Redirect HTTP to HTTPS

#236

Post by vitiral » Wed, May 29, 2024, 12:26 PM UTC

dotancohen wrote: post #218

Eduard wrote: post #134

Earlier quoted context omitted.

that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…

> that's more secure, but still not bulletproof I've never heard of bulletproof ever actually being achieved in IT security. Not even air gaps.

The thing about bullet proof is that nothing is bulletproof when you have a big or fast enough bullet

Re: API Shouldn't Redirect HTTP to HTTPS

#237

Post by vitiral » Wed, May 29, 2024, 12:29 PM UTC

CGamesPlay wrote: post #176

makeitdouble wrote: post #169

Earlier quoted context omitted.

Wouldn't this open the door to revoking random API keys sent maliciously ?

This is just a run-of-the-mill DoS attack, with the astronomically unlikely jackpot of additionally invaliding a random unknown user's API key when you get a hit.

Astronomically is an understatement. If they made 1000 requests per second they might have a 1% chance of revoking a key before the heat death of the universe.

Cracking hashing requires large parallel processing, something you can't do if you're API limited

Re: API Shouldn't Redirect HTTP to HTTPS

#238

Post by Cthulhu_ » Wed, May 29, 2024, 12:31 PM UTC

makeitdouble wrote: post #169

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.

Wouldn't this open the door to revoking random API keys sent maliciously ?

If the API key is a UUID or similar in complexity, they'd have to send 5.3 undecillion API keys to make sure all of them were invalidated.

So yes, it would open the door to revoking random API keys, but that's not a bad thing; when using an API key, you should be ready to rotate it at any point for any reason.

Re: API Shouldn't Redirect HTTP to HTTPS

#239

Post by zeroimpl » Wed, May 29, 2024, 12:37 PM UTC

rocqua wrote: post #181

jedberg wrote: post #126

Earlier quoted context omitted.

> If someone is in your path they can just fake listen to 80 and intercept, then forward your call to 443. They can do that whether or not you are listening on port 80 though.

That was OPs point. Not listening on port 80 won't help against an active MitM.

But listening on port 80 and revoking the key also won’t help either as the active MitM would have been smart enough to internally proxy to port 443 or return some other fake response.

The real point is to break the application during development before the first MitM. Either approach does that equally well.

Re: API Shouldn't Redirect HTTP to HTTPS

#240

Post by davedx » Wed, May 29, 2024, 12:38 PM UTC

Aachen wrote: post #40

davedx wrote: post #32

Earlier quoted context omitted.

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…

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?