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

161–170 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#161

Post by grantism »

amscanne wrote: post #153
lofenfew wrote: post #142

Earlier quoted context omitted.

There's absolutely nothing you can do to prevent an active MITM attack over HTTP

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

What's stopping the MITM just copying that header?

Re: API Shouldn't Redirect HTTP to HTTPS

#162

Post by mbreese »

ants_everywhere wrote: post #151
marcosdumay wrote: post #147

Earlier quoted context omitted.

If anybody is looking to copy in a public API, please return 400 and don't misuse a standard code.

400 is usually for a malformed request. It seems like in this case the request is well formed, it's just not allowed. 403 seems reasonable if the user isn't authorized to make a request to the URL, which they aren't. Some APIs return redirects which also seems pretty reasonable.

But that also implies that some user would be authorized to make a request to the HTTP port (or that the resource does exist, which in this case it doesn’t).

IMO, 400 is more accurate, but really either could be acceptable, so long as the client is notified of the error. But, I wouldn’t automatically redirect the client. That’s what we are trying to avoid.

Re: API Shouldn't Redirect HTTP to HTTPS

#163

Post by booi »

Pesthuf wrote: post #157
Hizonner wrote: post #154

Earlier quoted context omitted.

Why not just stop listening on port 80, period?

It’s a good option, but you can’t give users a reason for the failure. They might even assume your service is broken.

I stopped listening on port 80 for everything… nobody’s complained yet! Maybe because they can’t find the service though.

Re: API Shouldn't Redirect HTTP to HTTPS

#164

Post by gruez »

grantism wrote: post #161
amscanne wrote: post #153

Earlier quoted context omitted.

Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?

What's stopping the MITM just copying that header?

There's complicated authentication schemes around hmac that tries to do this, but if you're putting that much effort into it you might as well give up and use https.

Re: API Shouldn't Redirect HTTP to HTTPS

#165

Post by perlpimp »

"This unencrypted part of the communication flow has its flaws. Third parties in shared networks, as well as network intermediaries, could sniff passwords and other secrets from the initial HTTP traffic or even impersonate the web server with a MITM attack."

A strawman fallacy.

Re: API Shouldn't Redirect HTTP to HTTPS

#166

Post by 1vuio0pswjnm7 »

As a non-developer, ordinary computer user "providing service" for one user (yours truly) it's easy for me to configure the TLS forward proxy listening on the loopback to send _all_ HTTP requests, from _any_ application, including ones sent to port 80, via HTTPS. This I find preferable to letting a browser try to convert HTTP to HTTPS, e.g., "HTTPS Everywhere", or letting a developer do it with a redirect. Personally, I compile clients without linking to a TLS library. They are smaller without it and I do not have to worry about every author having correctly added TLS support. When SSL/TLS changes, applications using it often need to be updated, and some authors have made mistakes, socat being one example that comes to mind. I do 100% of TLS negotiation using a single program: the proxy. Every HTTP request on the home network goes to the proxy.

Re: API Shouldn't Redirect HTTP to HTTPS

#167

Post by bhawks »

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"…

You may want to disable path resolution as well.

http://api.openai.com/v1/chat/completions/../bar responds with error messages about http://api.openai.com/v1/chat/bar which might suggest some path traversal vulnerability that could be exploited.

Generally an API client is not going to need .. to be resolved in a path. It should return 400 - Bad Request (deceptive routing).

Re: API Shouldn't Redirect HTTP to HTTPS

#168

Post by Titan2189 »

chrismorgan wrote: post #158

npm is misusing 426 Upgrade Required. https://httpwg.org/specs/rfc9110.html#status.426 : > The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8). https://httpwg.org/specs/rfc9110.html#field.upgrade : > The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transpo…

How is this not more upvoted? HTTP Code 426 sounds like the best code to send?

Re: API Shouldn't Redirect HTTP to HTTPS

#170

Post by Townley »

makeitdouble wrote: post #169
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.

Wouldn't this open the door to revoking random API keys sent maliciously ?

If a malicious party has access to the API key, it should be revoked regardless
Post reply on HN