[zepton]

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.

[Eduard]

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 revocation), a MITM with a shorter trip time to SE's servers could race for wrecking havoc until the revocation happens.

Nevertheless, SE's revocation tactic contributes positively to a defense in depth strategy.

[UncleMeat]

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.

[Titan2189]

I'd argue your reasoning is incorrect. By the time your service is developed you would have already changed it to https, as during development every time you tried your API keys sent via http got disabled. So an in-the-wild MITM would never get to see your http request

[lofenfew]

There's absolutely nothing you can do to prevent an active MITM attack over HTTP

[dotancohen]

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

[znpy]

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.

[comex]

One of the approaches mentioned in the article is to just not listen on port 80. Supposedly that’s equally good because the connection should get aborted before the client has the chance to actually send any API keys.

But is that actually true? With TCP Fast Open, a client can send initial TCP data before actually learning whether the port is open. It needs a cookie previously received from the server to do so, but the cookie is not port-specific, so – assuming the server supports Fast Open – the client could have obtained the cookie from a prior connection over HTTPS or any other valid port. That’s the impression I get from reading the RFC, anyway. The RFC does mention that clients should distinguish between different server ports when caching refusals by the server to support Fast Open, but by that point it’s too late; the data may have already been leaked.

[cryptonector]

Well, nothing you do on the server side will protect a client willing to use http: when an MITM is present: the client can still connect to the MITIM, give away its credentials, and your server won't know.

Still, I agree that this is a very good way to teach your users to not start with http:! And that this is what one should do.

[ChrisTorng]

The client-side library should disable HTTP by default to ensure that raw data never leaves the local environment, thereby avoiding any leakage.

[rattray]

(I develop client SDKS)

It could make sense for first-party SDKs for an API to block http access to the first-party API domain, but that should be unnecessary – typically users would use the default base URL hardcoded in the client library, and only replace it if they're going through some other proxy.

When they _do_ go through some other proxy, it's commonly in an internal network of some kind, where http is appropriate and should not be blocked.

[gpvos]

It should, but additional server-side mitigations are good for defense in depth. There may be people using a different client-side library, maybe because they use a different programming language.

[ljm]

What about things like unencrypted websockets? Or raw TCP/UDP connections?

[beeboobaa3]

Used to? Did they stop? Did they give a reason why?

[op00to]

I love this.

[mid-kid]

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

[Thiez]

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

[dirigeant]

If someone steals API keys and invalidate them by sending HTTP requests instead of using them, you can only thank them.

[mrmanner]

You need to actually send them the API key, so not really.

[afiori]

To do that you need to guess or steal the API keys.

[vitiral]

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

[ajsnigrutin]

I mean... it is a lot easier to do, than to program a procedure to revoke an api key.

[paulddraper]

Technically correct.

[freehorse]

Best kind of correct.

[makeitdouble]

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

[Townley]

If a malicious party has access to the API key, it should be revoked regardless

[CGamesPlay]

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.

[Cthulhu_]

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.