I agree that APIs shouldn't automatically redirect HTTP to HTTPS, but I also think that client libraries shouldn't follow redirects by default.
API Shouldn't Redirect HTTP to HTTPS
71–80 of 310 posts
Re: API Shouldn't Redirect HTTP to HTTPS
#72Earlier 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'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?
Re: API Shouldn't Redirect HTTP to HTTPS
#73My 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.
Re: API Shouldn't Redirect HTTP to HTTPS
#74The 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 love this.
Re: API Shouldn't Redirect HTTP to HTTPS
#75The 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…
> 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.
Re: API Shouldn't Redirect HTTP to HTTPS
#76Or just add your domain to the hsts preload list and never have to worry about this.
Please look into the myriad scenarios in which HSTS is not honoured.
As usual, any comment stating that people should “just” do x, is wrong.
Re: API Shouldn't Redirect HTTP to HTTPS
#77Earlier quoted context omitted.
TCP handshake failure prevents the client from being able to send any data, no?
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]
Re: API Shouldn't Redirect HTTP to HTTPS
#78Earlier quoted context omitted.
>For an API like fetch it doesn't even make sense as a question IMO. Why not?
Because the way HSTS works fundamentally implies a stateful client, and because it was fundamentally created to solve a human problem (i.e. humans entering in URLs directly in the address bar). It really doesn't make sense with a non-stateful client, and it isn't intended for cases where someone isn't manually entering in the URL to hit. E.g. fetch is often loaded in transient situations - it really shouldn't be upda…
I agree with you on things like CORS, but HSTS would actually solve the problem stated in this thread quite gracefully.
Client fetches http, notices the header, retries https then ... ok no, lol. But I guess it's still of some use to let clients know "this should always happen through https" and make them fail if that's not the case.
Edit: yeah I got it, client fetches http, notices the header and then explicitly fails because HSTS is there.
Re: API Shouldn't Redirect HTTP to HTTPS
#79The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.
Technically correct.
Re: API Shouldn't Redirect HTTP to HTTPS
#80Don't have HTTP available at all
The argument I've heard against not having HTTP at all is that potentially someone might be able to run something malicious on port 80 for that address that the admin is not aware of.
People can make up their own minds if that's a good argument or not.