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

81–90 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#81

Post by cqqxo4zV46cp »

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#82

Post by Dylan16807 »

jraph wrote: post #72
Dylan16807 wrote: post #61

Earlier quoted context omitted.

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'm highly surprised by this. It seems very dumb and I have never seen anything like this, though I never use Chrome and very rarely fire Chromium for testing something. Is there something to read about this, like a dev ticket?

There might be but I'm not aware of any tickets. But if you open chrome and navigate to 192.168.20.20 you should see it. Or any domain that resolves to a non-responsive IP, if you have one in mind.

Re: API Shouldn't Redirect HTTP to HTTPS

#83

Post by rascul »

Wowfunhappy wrote: post #66
x86a wrote: post #10

Earlier quoted context omitted.

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.

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

Re: API Shouldn't Redirect HTTP to HTTPS

#84

Post by taftster »

yjftsjthsd-h wrote: post #26
iJohnDoe wrote: post #18

Earlier quoted context omitted.

Does HTTPS also hide the URL request in most logging systems? You can always see the domain (api.example.com) but you cannot see the URL? The benefit being it hides an API key if included in the URL?

Yes, it hides the URL, although sadly not the domain.

It hides the domain too, in the literal HTTP request.

What it doesn't hide is the DNS lookup for that domain. You still have to translate a hostname into an IP address.

This might be a concern for certain uses. But at least it's on another port and protocol and not directly related to the HTTP request itself.

Re: API Shouldn't Redirect HTTP to HTTPS

#85

Post by comex »

znpy wrote: post #67
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.

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#86

Post by smaudet »

eddd-ddde wrote: post #47

Now that I think about it, interfaces such as Js fetch should make it an error to use http without explicitly allowing in an option. It seems to easy to make an error and end up in a situation like the post explains.

Hmm. I think, perhaps, release versions should need this, without a flag.

For testing/prototyping, it is invaluable to turn off all the security to rule out security misconfiguration instead of application error.

If your API is non-sensitive/relies on out of band security (like large files with checksums), you may still not want https, so there should be some configuration to turn it off. And for "integrations" like jsdelivr, perhaps https libraries should follow this rule, while http ones can have the flag off...

Then, if you mix the two (http and https) perhaps they can provide an noticeable alert to the user rather than failing silently...

Re: API Shouldn't Redirect HTTP to HTTPS

#87

Post by TeMPOraL »

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.

It's definitely not improving security when, in order for a website to interact with an API that both are hosted on my private network, possibly even on the same machine, I need to set up publicly accessible DNS entries and/or hosting my own resolver. That and CORS makes local-first anything a huge PITA.

Re: API Shouldn't Redirect HTTP to HTTPS

#88

Post by yjftsjthsd-h »

taftster wrote: post #84
yjftsjthsd-h wrote: post #26

Earlier quoted context omitted.

Yes, it hides the URL, although sadly not the domain.

It hides the domain too, in the literal HTTP request. What it doesn't hide is the DNS lookup for that domain. You still have to translate a hostname into an IP address. This might be a concern for certain uses. But at least it's on another port and protocol and not directly related to the HTTP request itself.

No, HTTPS has the domain in plaintext. There is a plan to fix this (Encrypted Client Hello), but AFAIK it's not widely used yet.

Re: API Shouldn't Redirect HTTP to HTTPS

#89

Post by sdsd »

layer8 wrote: post #46
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…

That’s fine, but rather unrelated to the article, which is about the situation that you have an API served via HTTPS, and the question of whether you should also have a redirect from HTTP to HTTPS in that case, or rather return an HTTP error.

Yeah, I should have clarified. Nothing to do with the article really, just a random thought. Sorry if too off-topic!

Re: API Shouldn't Redirect HTTP to HTTPS

#90

Post by sdsd »

cqqxo4zV46cp wrote: post #73
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…

A HTTP website presents an opportunity for an attacker to MITM a payload that is ultimately executed in a user’s browser. Beyond ‘getting a moustache tattoo on your finger’ quirkiness, HTTP-only websites are really inexcusable beyond some very niche cases.

>Beyond ‘getting a moustache tattoo on your finger’ quirkiness

In that case, seems totally worth it. I, like moustache finger tattoos, am aggressively opposed to worrying about being perceived as cool. I will just have to live with being inexcusable.

Post reply on HN