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

21–30 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#21

Post by Aachen »

iJohnDoe wrote: post #18
moralestapia wrote: post #11

Earlier quoted context omitted.

No, HTTP would expose any sensitive information. It's just clear text.

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?

The benefit is that it:

1. hides any private information anywhere in the request, URL or otherwise, API key or otherwise. Maybe you're fine if someone knows you used Bing (revealed through DNS lookups), but not what query you entered (encrypted to be decryptable only by Bing servers). An API key is obviously secret but something as oft-innocuous as search queries can also be private.

2. disallows someone on the network path from injecting extra content into the page. This can be an ISP inserting ads or tracking (mobile carriers have been playing with extra HTTP headers containing an identifier for you for advertising reasons iirc) or a local Machine-in-the-Middle attack where someone is trying to attack another website you've visited that used https.

Re: API Shouldn't Redirect HTTP to HTTPS

#22

Post by ozim »

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

That is an awful idea - in post Snowden world you encrypt all traffic period.

Then you have post Jia Tan world - if there is even slightest remote possibility, you just don't want to be exposed.

Just like washing hands after peeing, just do HTTPS and don't argue.

Re: API Shouldn't Redirect HTTP to HTTPS

#23

Post by moralestapia »

hn_throwaway_99 wrote: post #19
Aachen wrote: post #6

Earlier quoted context omitted.

I'm not even sure I'd find it desirable for nodejs fetch() to quietly store state somewhere on my server without asking me: I wouldn't know to back that file up, it may be trashed regularly depending on the infrastructure, it could mess with version control by creating a local working directory change, or it might run into an error condition if it is on a read-only filesystem (either crashing or being unable to use t…

I think the original question "Okay.. does nodejs fetch respect HSTS?" goes into the "not even wrong" bucket, for the reasons you point out. HSTS really only makes sense from a browser perspective (or, rather, a "permanently installed, stateful client" perspective). For an API like fetch it doesn't even make sense as a question IMO.

>For an API like fetch it doesn't even make sense as a question IMO.

Why not?

Re: API Shouldn't Redirect HTTP to HTTPS

#24

Post by g15jv2dp »

akira2501 wrote: post #2

> Servers can now send HSTS along with the initial HTTP-to-HTTPS redirection response > Node.js's built-in fetch happily and quietly followed those redirects to the HTTPS endpoint. Okay.. does nodejs fetch respect HSTS?

How would that even work? It's up to the developer to consider the response and act correctly on it.

Re: API Shouldn't Redirect HTTP to HTTPS

#26

Post by yjftsjthsd-h »

iJohnDoe wrote: post #18
moralestapia wrote: post #11

Earlier quoted context omitted.

No, HTTP would expose any sensitive information. It's just clear text.

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#28

Post by Aachen »

hn_throwaway_99 wrote: post #19
Aachen wrote: post #6

Earlier quoted context omitted.

I'm not even sure I'd find it desirable for nodejs fetch() to quietly store state somewhere on my server without asking me: I wouldn't know to back that file up, it may be trashed regularly depending on the infrastructure, it could mess with version control by creating a local working directory change, or it might run into an error condition if it is on a read-only filesystem (either crashing or being unable to use t…

I think the original question "Okay.. does nodejs fetch respect HSTS?" goes into the "not even wrong" bucket, for the reasons you point out. HSTS really only makes sense from a browser perspective (or, rather, a "permanently installed, stateful client" perspective). For an API like fetch it doesn't even make sense as a question IMO.

I would say it does make sense as a nice upgrade path for services that don't yet support https but you'd like to switch as soon as they enable it, or if you're forgetful or lazy and didn't type https:// in front of the link you were given or so

Whether that's still common enough to warrant the extra complexity in the fetch function is not something I'm qualified to judge

Post reply on HN