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

131–140 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#131

Post by danparsonson »

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…

> You have to mitm in order to evesdrop on an encrypted channel.

OK but we're talking about evesdropping HTTP, which is unencrypted.

Re: API Shouldn't Redirect HTTP to HTTPS

#132

Post by dramm »

Yes, great article. And now can we convince folks with http+https websites to shut down http access and only offer https. I've seen simple mistakes like only partial redirects happening. Large numbers of internal links that still go to the http site, and some of those not redirect, etc. (you would think they are simple to find and just clean up), etc. And it is frustrating when sites like some online forums may be interesting targets for password theft.

Re: API Shouldn't Redirect HTTP to HTTPS

#133

Post by prettymuchnoone »

sdsd wrote: post #127
OJFord wrote: post #123

Earlier quoted context omitted.

When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Secure site not available Most likely, the web site simply does not support HTTPS. However, it’s also possible that an attacker is involved. If you continue to the web site, you should not enter any sensitive info. If you continue, HTTPS-Only mode will be turned off temporarily for the site. [Cont…

>When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing? >for the price of a free Let's Encrypt cert you can del…

> Neither desktop firefox nor chrome seem to do this by default

they do, you probably just checked the "i'm sure this is safe" button

posted a pic on the imageboard hehe

Re: API Shouldn't Redirect HTTP to HTTPS

#134

Post by Eduard »

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

Re: API Shouldn't Redirect HTTP to HTTPS

#135

Post by sdsd »

prettymuchnoone wrote: post #133
sdsd wrote: post #127

Earlier quoted context omitted.

>When a user visits your site with a modern browser in default configuration they'll get an error page along the lines of: Neither desktop firefox nor chrome seem to do this by default, at least on my Mac (actually I think I'm wrong about Firefox on desktop as well, thanks to a guestbook signer!). Maybe it's a Firefox mobile thing, rather than a modernity thing? >for the price of a free Let's Encrypt cert you can del…

> Neither desktop firefox nor chrome seem to do this by default they do, you probably just checked the "i'm sure this is safe" button posted a pic on the imageboard hehe

Thanks for visiting! Receiving guestbook comments is such a delight. Does Chrome also give you this warning on desktop?

Re: API Shouldn't Redirect HTTP to HTTPS

#136

Post by plorkyeran »

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…

I have never seen this happen in Chrome. I just tried it to make sure I wasn't crazy and it did indeed go straight to telling my that the connection timed out without showing a security error first.

Re: API Shouldn't Redirect HTTP to HTTPS

#137

Post by prettymuchnoone »

sdsd wrote: post #135
prettymuchnoone wrote: post #133

Earlier quoted context omitted.

> Neither desktop firefox nor chrome seem to do this by default they do, you probably just checked the "i'm sure this is safe" button posted a pic on the imageboard hehe

Thanks for visiting! Receiving guestbook comments is such a delight. Does Chrome also give you this warning on desktop?

nope

Re: API Shouldn't Redirect HTTP to HTTPS

#138

Post by Titan2189 »

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…

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

Re: API Shouldn't Redirect HTTP to HTTPS

#139

Post by alberth »

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 HTTPS (even for error codes).

Re: API Shouldn't Redirect HTTP to HTTPS

#140

Post by Jach »

rascul wrote: post #83
Wowfunhappy wrote: post #66

Earlier quoted context omitted.

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

> • It's not a real security concern if you're on a private network. I'm not convinced that private networks should be assumed secure by default.

I setup a photo viewing web service running locally on my home computer, now I can access my photos over HTTP from my phone when I'm out and about. Both devices are on the same Tailscale network. If I can't trust in the security of that, HTTPS isn't going to help me, and the security of viewing my photos is the least of my concerns. But sure, in other contexts (like an enterprise company), some thought should be given to what's possible when the attacker is inside the corporate VPN since that's all too easy.
Post reply on HN