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

91–100 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#91

Post by smaudet »

x86a wrote: post #10
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).

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.

> Even for non-enterprise use cases

I don't think non-enterprise, non machine use cases should be automatically handles, though. Attempting client upgrade is better than not, but we should be more clear about whether our devices are acting safely, i.e. calling out the change, and in the case of http local usage, reminding to use visible, out of band verification methods.

Of course this only works if the default is secure, but I am glad that browser still let me go unencrypted when I really need to, I prefer the giant warning banners...

Re: API Shouldn't Redirect HTTP to HTTPS

#92

Post by amanzi »

Interesting - I hadn't considered this before, but makes perfect sense. Feels like it's something that's easy to miss, as lots of APIs are hosted behind generic web application firewalls that often have automatic HTTPS redirection as a base rule.

Re: API Shouldn't Redirect HTTP to HTTPS

#93

Post by pzmarzly »

NewJazz wrote: post #9
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?

I'm not aware of any general programming language http clients that honor HSTS.

libcurl supports HSTS, but the client has to specify a file where the state should be stored https://curl.se/docs/hsts.html

Many languages/libraries use libcurl in some shape or form, but whether they set up an on-disk HSTS store or not - I don't know either.

Re: API Shouldn't Redirect HTTP to HTTPS

#94

Post by HL33tibCe7 »

dfabulich wrote: post #39

The author includes a surprising response from "Provider B" to the HackerOne report. > Provider B: Reported on 2024-05-21 through their HackerOne program. Got a prompt triage response, stating that attacks requiring MITM (or physical access to a user's device) are outside the scope of the program. Sent back a response explaining that MITM or physical access was not required for sniffing. Awaiting response. I think Pr…

MITM generally refers to someone who can intercept and modify traffic, i.e. they sit “in the middle”, between you and your recipient, reading/modifying/relaying traffic.

“Passive eavesdropper” is often used to describe what you talk about. Someone on an unencrypted WiFi network sniffing your traffic isn’t really “in the middle” at all, after all.

Re: API Shouldn't Redirect HTTP to HTTPS

#95

Post by gsich »

hiatus wrote: post #77
lxgr wrote: post #68

Earlier quoted context omitted.

Often, but not always: https://en.wikipedia.org/wiki/TCP_Fast_Open

> TFO has been difficult to deploy due to protocol ossification; in 2020, no Web browsers used it by default.[2]

It's in use by Android for DNS over TLS. Ossification issues are exaggerated.

Re: API Shouldn't Redirect HTTP to HTTPS

#96

Post by bigstrat2003 »

lxgr wrote: post #8

Completely agree, and arguably why stop at API servers? Depending on server-side HTTP -> HTTPS redirects for security reinforces/rewards bad practices (linking to HTTP, users directly entering HTTP etc.), in a way that makes users vulnerable to one of the few remaining attack vectors of "scary public Wi-Fis".

The push for "TLS all the things" was already a massive overreach that actively made security worse overall, because it further ingrained the user tendency to click through scary browser warnings (all for the sake of encrypting things that were fine in plaintext). And you want to go even further? No thank you.

Re: API Shouldn't Redirect HTTP to HTTPS

#97

Post by bigstrat2003 »

ozim wrote: post #22
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.

Dogma is how religion works, not engineering. If someone doesn't believe the benefit is worth the cost, they can and should question the practice. Blind obedience to a dogma of "just do HTTPS" is not a reasonable approach.

Re: API Shouldn't Redirect HTTP to HTTPS

#98

Post by smaudet »

taftster wrote: post #59
codepoet80 wrote: post #38

Earlier quoted context omitted.

You’ve already been shouted down, but thank you for daring to suggest this. I maintain APIs and proxies for APIs for legacy devices, and will continue to suggest that some kinds of APIs remain appropriate for HTTP access. Never do your banking this way, obviously, but where is the harm in allowing older devices to access content in a read-only fashion?

Hypothetically speaking, plain HTTP transport even for "read only" content, can be a problem if it can be manipulated in transit. Let's take a weather service. Seems like weather information is a read-only immutable fact and should not be something that needs protection from MITM attacks. You want to reach the largest audience possible and your authoritative weather information is used throughout the world. One day,…

> an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic

I think this is the most convincing argument, but, I think that some data doesn't care if it is not confidential. The weather is perhaps more pointed, but I think for large protected binaries (either executable or inscrutable, e.g. encrypted or sig protected archives), its a bit moot and possibly only worse performing.

However, also remember that https does not protect all data, just the application portion - adversaries can still see, map, and measure traffic to bobthebaker.com and sallyswidgets.biz. To truly protect that information, https is the wrong protocol, you need something like Tor or similar bit mixing.

Re: API Shouldn't Redirect HTTP to HTTPS

#99

Post by valec »

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.

not my problem!

Re: API Shouldn't Redirect HTTP to HTTPS

#100

Post by taftster »

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

Earlier quoted context omitted.

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.

Ah yes, apologies. Again, it's not strictly part of the HTTP request, but part of the TLS handshake around it. And only part of the TLS handshake as part of SNI, if supported (which is true by default).

> "Server Name Indication payload is not encrypted, thus the hostname of the server the client tries to connect to is visible to a passive eavesdropper."

https://en.wikipedia.org/wiki/Server_Name_Indication

So you're right, this is more aligned to the HTTP request than the DNS resolution of hostname that I mentioned. Strictly speaking, it's not part of HTTP per se (it's part of TLS), but still, it's in the same request in the most common definition, as you are saying.

Post reply on HN