API Shouldn't Redirect HTTP to HTTPS • Hacker News Board

Re: API Shouldn't Redirect HTTP to HTTPS

#271

Post by joveian » Wed, May 29, 2024, 4:20 PM UTC

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…

Consider: 4. Someone else logs unencrypted traffic for whatever reason and the attacker gets access to the log later.

MITM means that you need to be in the middle at the time of the attack and so is more limited than an attack that works on logs.

Re: API Shouldn't Redirect HTTP to HTTPS

#272

Post by ljm » Wed, May 29, 2024, 4:26 PM UTC

sfn42 wrote: post #258

fl0ki wrote: post #253

Earlier quoted context omitted.

I agree from a developer point of view, but the people configuring and deploying the application aren't always the same people developing it. As a developer I like to make many options available for debugging in various situations, including disabling TLS. This isn't controversial, every Go and Rust library I've ever seen defaults to no TLS, preferring to make it easy rather than required, so reflecting those default…

Won't those people have the same experience? The app won't work until they configure it securely

There is a non-zero number of developers out there who would sooner deploy a proxy that upgrades http to https because the thought of changing the application code wouldn’t spring to mind

Re: API Shouldn't Redirect HTTP to HTTPS

#273

Post by ljm » Wed, May 29, 2024, 4:28 PM UTC

ChrisTorng wrote: post #214

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.

The client-side library should disable HTTP by default to ensure that raw data never leaves the local environment, thereby avoiding any leakage.

What about things like unencrypted websockets? Or raw TCP/UDP connections?

Re: API Shouldn't Redirect HTTP to HTTPS

#274

Post by marcosdumay » Wed, May 29, 2024, 4:34 PM UTC

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…

Because it's not an authorization error.

You do not throw 403 if the client is authorized to access whatever resource it's trying to.

The 426 on the sibling comment is great, though. But if you don't find an error code for your case, you don't go and redefined a well defined one. You use 400 (or 500).

Re: API Shouldn't Redirect HTTP to HTTPS

#275

Post by bradley13 » Wed, May 29, 2024, 4:48 PM UTC

https is great, and I'm glad most web traffic uses it. However, sometimes you want http.

Example: when teaching low-level socket programming, plain http is the easiest place to start.

Example: when providing simple, nonsensitive, read-only info via API, the overhead of https and certificate management seems unnecessary.

Re: API Shouldn't Redirect HTTP to HTTPS

#276

Post by tracker1 » Wed, May 29, 2024, 4:49 PM UTC

inopinatus wrote: post #172

Pesthuf wrote: post #157

Earlier quoted context omitted.

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 think it's fair to assume j. random user isn't typing " http://api.example.net " into their web browser. leading www perhaps, leading api no.

You'd be surprised... generally if there's a dedicated hostname for the API, I would expect / to either display or redirect to API docs.

Also, doesn't help when you're reverse proxying /api to $API/api

Re: API Shouldn't Redirect HTTP to HTTPS

#277

Post by tracker1 » Wed, May 29, 2024, 4:54 PM UTC

justin_oaks wrote: post #7

I appreciate the author calling this out because creating an HTTP-redirect-to-HTTPS is something I'll do almost without thinking about it. "If it has HTTPS, I'll set up an HTTP redirect." Now I know that I need to think about it before setting that up. It also made me realize that cURL's default to not redirect automatically is probably intentional and is a good default. Praise be to Daniel Stenberg for this choice w…

I tend to use Caddy as a reverse proxy for personal projects... The default behavior is to redirect to https. May have to make a special rule for API instances.

Re: API Shouldn't Redirect HTTP to HTTPS

#278

Post by tracker1 » Wed, May 29, 2024, 4:56 PM UTC

tootie wrote: post #53

justin_oaks wrote: post #7

I appreciate the author calling this out because creating an HTTP-redirect-to-HTTPS is something I'll do almost without thinking about it. "If it has HTTPS, I'll set up an HTTP redirect." Now I know that I need to think about it before setting that up. It also made me realize that cURL's default to not redirect automatically is probably intentional and is a good default. Praise be to Daniel Stenberg for this choice w…

Using Cloudfront, the redirect was the only built-in option for a long time. They only added pushbutton HSTS recently. But I'd say author is correct that if you're hosting an API there's no reason to support http at all. Just send a 400 on all requests and let the client developers use common sense.

You can still return a response...

  400 - HTTP is unsupported, use HTTPS.

Re: API Shouldn't Redirect HTTP to HTTPS

#279

Post by josephcsible » Wed, May 29, 2024, 5:05 PM UTC

freedomben wrote: post #263

josephcsible wrote: post #189

Earlier quoted context omitted.

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.

If it were a generic 403, sure. But if the 403 message said something to the effect of "this API key is no longer valid because it has previously been observed over insecure HTTP", then wouldn't that be fine?

Re: API Shouldn't Redirect HTTP to HTTPS

#280

Post by tessierashpool » Wed, May 29, 2024, 5:07 PM UTC

UncleMeat wrote: post #233

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…

Nothing could possibly be bulletproof. You sent a key over the wire unencrypted. You were in trouble before the data even got to the server to do anything about it. This approach is a practical choice based on the reality that the bulk of unencrypted traffic is not being actively mitmed and is at most being passively collected. Outside of actually developing cryptosystems, security tends to be a practical affair wher…

as an old-school reader of the cypherpunks email list from before HTTPS existed, I'm still mad about this part:

Outside of actually developing cryptosystems, security tends to be a practical affair where we are happy building systems that improve security posture even if they don't fix everything.

there was a time in the 1990s when cryptography geeks were blind to this reality and thought we'd build a very different internet. it sure didn't happen, but it would have been better.

we had (and still have today) all the technology required to build genuinely secure systems. we all knew passwords were a shitty alternative. but the people with power were the corrupt, useless "series of tubes!" political class and the VCs, who obviously are always going to favor onboarding and growth over technical validity. it's basically an entire online economy founded on security theater at this point.