Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API Shouldn't Redirect HTTP to HTTPS

jviide.iki.fi

Post reply on HN
Print view View original

181–190 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#181

Post by rocqua »

jedberg wrote: post #126
pixl97 wrote: post #108

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. Probably best to listen on 80 and trash the token right then as the majority of the time there won't be a MITM and breaking the application will force the developer to change to https

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

Re: API Shouldn't Redirect HTTP to HTTPS

#182

Post by rocqua »

loa_in_ wrote: post #171
xyst wrote: post #148

Revoking an API key upon a single http request assumes you have a competent team. Have worked with people that have committed sensitive credentials into public repositories, used PRODUCTION secrets for testing, and of course sharing secrets in plain text over IM and group chats. The number of times I have had to deal with password or secret key resets because of this is way too high. I remember working with a guy tha…

It assumes nothing like that. It provides you and your team with a safe opportunity to learn and grow. Revoking a key like this is a problem that's solution is at worst a dozen clicks away fix. The alternative, leaking keys can be much worse. So go and reset those creds for the guy who made a mistake happily and be grateful. He had an opportunity to learn.

It might be optimistic to say that rolling over to a new key is 'at most a dozen clicks'.

Hardcoded keys are a big one. But even just hunting down all config where the key needs to change can be a major hassle. Is there some ci yaml that expects a runner to have the key in a .env file that only runs on major release? Good chance you won't realize that key exists.

Still a great idea to revoke those keys. But it will damage some customers in the short term. And they will be angry, as people often are when you demonstrate their mistake.

Re: API Shouldn't Redirect HTTP to HTTPS

#183

Post by Brian_K_White »

danparsonson wrote: post #131
Brian_K_White wrote: post #130

Earlier quoted context omitted.

You have to mitm in order to evesdrop on an encrypted channel. If you do nothing but evesdrop, isn't it still mitm? You had to actively replace & spoof the two endpoints, but that is just a technicality required by the encryption, in the end you still only evesdropped, yet it was still called mitm. So, mere evesdropping is mitm. So, how is evesdropping on unencrypted traffic or wifi traffic meaningfully different tha…

> You have to mitm in order to evesdrop on an encrypted channel. OK but we're talking about evesdropping HTTP, which is unencrypted.

So what? My point was the encryption doesn't matter, it's just the reason you have to impersonate in order to merely evesdrop sometimes.

Re: API Shouldn't Redirect HTTP to HTTPS

#184

Post by bruce511 »

sdsd wrote: post #35

My personal website (darigo.su) doesn't have HTTPS. I just deployed it a few months ago and haven't really done much with it yet. I guess I'll have to get around to it eventually, but I find charm in small old sites that haven't implemented modern protocol stuff. My site also uses and tags all over the place. Maybe I'll do some more quirky anachronisms, like only serve the site via HTTP 1.0 or something. Who knows. S…

I see this a lot. You've just made a small non-interactive site, and there's nothing secret. So why bother either https?

Well, firstly, I'd say, make ot https for fun. It's pretty simple to do, makes itself automatic, and costs no money. Just exploring this route can be very illuminating.

Secondly it prevents your site from being altered by the outside. There's a lot of equipment between your site and the client. Being HTTP allows it to be altered along the way.

Gor example, and thd least serious, is that your ISP can inject adverts onto your page. Most ISPs don't do this, but quite a few do.

Second, a malicious user could inject additional text onto upur pages, proclaiming your love for a political party, some racial or misogynistic slur, or whatever.

Third, you're sending a signal to all that you either don't understand the security risks, or don't care about them. This can have consequences (reputationally) if you are in, or going into, a computing career.

Making it HTTPS can be fun too!

Re: API Shouldn't Redirect HTTP to HTTPS

#185

Post by thaumasiotes »

Brian_K_White wrote: post #130
thaumasiotes wrote: post #75

Earlier quoted context omitted.

> Public unencrypted (or weakly WEP encrypted) wifi, with clients connecting to HTTP websites. Other clients on the same wifi network can read the unencrypted HTTP packets over the air. That's sniffing. The other two are MITM. The sniffer isn't in the middle of anything; you never speak to him.

You have to mitm in order to evesdrop on an encrypted channel. If you do nothing but evesdrop, isn't it still mitm? You had to actively replace & spoof the two endpoints, but that is just a technicality required by the encryption, in the end you still only evesdropped, yet it was still called mitm. So, mere evesdropping is mitm. So, how is evesdropping on unencrypted traffic or wifi traffic meaningfully different tha…

> because generally you do still talk to who you thought you were, just not directly.

...that's the requirement. The indirection of someone interposing themselves between you and the party you're trying to speak to is what is referred to by the phrase "man in the middle".

There is no phrase "man to the side". If you don't represent yourself as being the party they want to talk to, you aren't performing a man-in-the-middle attack.

Re: API Shouldn't Redirect HTTP to HTTPS

#186

Post by hirsin »

Dylan16807 wrote: post #61
Aachen wrote: post #16

Earlier quoted context omitted.

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 take…

This is only enabled for a small percent of people at random, otherwise just folks in the advanced protection program.

Re: API Shouldn't Redirect HTTP to HTTPS

#187

Post by 4death4 »

grantism wrote: post #161
amscanne wrote: post #153

Earlier quoted context omitted.

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

What's stopping the MITM just copying that header?

Even if the copy the header, they can only perform a replay attack, which is an improvement over leaking an API key. Also, you could include a timestamp in the signature to limit the amount of time it could be replayed.

Re: API Shouldn't Redirect HTTP to HTTPS

#189

Post by josephcsible »

alberth wrote: post #139
athyuttamre wrote: post #105

Great article! We've updated the OpenAI API to 403 on HTTP requests instead of redirecting. $ curl http://api.openai.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 123" \ -d '{}' { "error": { "type": "invalid_request_error", "code": "http_unsupported", "message": "The OpenAI API is only accessible over HTTPS. Ensure the URL starts with 'https://' and not 'http://'.", "param"…

Doesn’t returning a 403 on HTTP break HSTS? https://security.stackexchange.com/questions/122441/should-h... Doesn’t HSTS require only responding to a user via HTTP S (even for error codes).

What about this then? When the request is made over insecure HTTP, revoke the API key used, but then send the usual redirect response for HSTS. Then, when/if the request gets repeated over HTTPS, notice the key is revoked and so respond to that one with 403.

Re: API Shouldn't Redirect HTTP to HTTPS

#190

Post by numpad0 »

bruce511 wrote: post #177
Townley wrote: post #170

Earlier quoted context omitted.

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

Of course. But I think the poster above was referring to just posting random keys to the server. In other words I don't have your key, or any key, but I have "all of them". The correct response to this though is that "there are lots of keys, and valid keys are sparse." In other words the jumper of valid keys that could be invalidated in this way is massively smaller than the list of invalid keys. Think trillions of t…

It's wrong that clients are authenticated with just the random generated username. But it's also what everyone do.
Post reply on HN