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

261–270 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#261

Post by loa_in_ »

xyst wrote: post #242
loa_in_ wrote: post #171

Earlier quoted context omitted.

It assumes nothing like that. It provides you and your team with a safe opportunity to learn and grow. Revoking a key like this is a problem that's solution is at worst a dozen clicks away fix. The alternative, leaking keys can be much worse. So go and reset those creds for the guy who made a mistake happily and be grateful. He had an opportunity to learn.

There’s the guy that made _a_ mistake. Then there’s the guy who continues to make the same mistake over and over again. That second person is way to common in companies that hire from the bottom of the barrel.

The thing with these kinds of mistakes is that if the service doesn't revoke the key and "cause problems" immediately, then there's no feedback to learn from. It's a fail-fast situation that's usually a better outcome anyway.

Re: API Shouldn't Redirect HTTP to HTTPS

#263

Post by freedomben »

josephcsible wrote: post #189
alberth wrote: post #139

Earlier quoted context omitted.

Doesn’t returning a 403 on HTTP break HSTS? https://security.stackexchange.com/questions/122441/should-h... Doesn’t HSTS require only responding to a user via HTTP S (even for error codes).

What about this then? When the request is made over insecure HTTP, revoke the API key used, but then send the usual redirect response for HSTS. Then, when/if the request gets repeated over HTTPS, notice the key is revoked and so respond to that one with 403.

If your goal is to waste people's time, cause them to question their sanity, and guarantee that they're way too pissed off when they finally figure out what happened that instead of teaching others about how important it is too use HTTPS from the start, they talk about how awful your API is and how much they hate your company for a terrible design, then yes this sounds like a good plan.

Re: API Shouldn't Redirect HTTP to HTTPS

#264

Post by brobinson »

jensenbox wrote: post #252

After all this chatter, I am considering blocking all outgoing traffic to port 80 in my local firewall This would prevent my fat fingers from ever even making the mistake. BLOCK outgoing port 80 How bad would that be? Would I be shooting myself in the foot somehow? Perhaps I would do it on the egress rule for where my requesting service is running like in ECS.

It would block requests to OCSP responders, for one.

Re: API Shouldn't Redirect HTTP to HTTPS

#265

Post by freedomben »

Hizonner wrote: post #154
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"…

Why not just stop listening on port 80, period?

I've done that myself and have consumed many others who have done it, and I don't think it's better. Much better to get a response that tells you to use https for the API. (for browser also a redirect is a must for UX, though our context here is API)

Re: API Shouldn't Redirect HTTP to HTTPS

#266

Post by freedomben »

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

Thank you for sharing! I think this sort of thing is what makes HN great.

Have you rolled this out to prod yet? Did you check how many users this might effect? I can imagine some (probably amateur) apps are going to break when this hits, so some notice might be nice.

I'm not asking those questions critically, mainly wanting to facilitate a full discussion around the pros and cons (I think the pros are are much stronger personally).

Re: API Shouldn't Redirect HTTP to HTTPS

#267

Post by fwip »

Titan2189 wrote: post #138
Eduard wrote: post #134

Earlier quoted context omitted.

that's more secure, but still not bulletproof: A MITM (e.g. a router along a multi-hop route between the victim client and StackExchange) could silently drop the unsafe HTTP requests and maliciously repackage it as an HTTPS request, thereby circumventing the revocation. Also: even if an insecure HTTP request isn't dropped / makes it through to StackExchange's endpoint eventually (and thereby triggering the API key re…

I'd argue your reasoning is incorrect. By the time your service is developed you would have already changed it to https, as during development every time you tried your API keys sent via http got disabled. So an in-the-wild MITM would never get to see your http request

The MITM can be between the developer's machine and Stack Overflow, e.g: the classic Evil Cafe Wifi.

Re: API Shouldn't Redirect HTTP to HTTPS

#268

Post by samatman »

hn_throwaway_99 wrote: post #175
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.

Why do you think 403 is the wrong error code? Based on the spec it seems entirely appropriate to me: > HTTP 403 provides a distinct error case from HTTP 401; while HTTP 401 is returned when the client has not authenticated, and implies that a successful response may be returned following valid authentication, HTTP 403 is returned when the client is not permitted access to the resource despite providing authentication…

I thought the best response from the article was the 426 Upgrade Required. That way you can throw in an Upgrade: https field in the response. It makes it immediately clear that something weird is going on. 403s are common, my first thought would be a badly-configured API key which lacks the expected permissions.

Re: API Shouldn't Redirect HTTP to HTTPS

#269

Post by samatman »

HL33tibCe7 wrote: post #102
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…

To me, HTTPS is worth it alone to eliminate the possibility of the ISPs of people reading my site from injecting shit (ads, trackers, etc.) into the responses I send to them. It’s completely trivial to set up, there’s really no downside at this point.

This is the somewhat depressing but accurate answer. HTTPS doesn't mean you are communicating sensitive or private data, it means you want the client to see what you send them, and not something else.
Post reply on HN