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

251–260 of 310 posts

Re: API Shouldn't Redirect HTTP to HTTPS

#251

Post by fl0ki »

This makes sense, and I wondered for a moment why I hadn't noticed the issue in any of our projects. I realized it's because we just don't expose HTTP in the first place, whether for API or UI purposes. However, that doesn't mean there's no danger.

I believe it's still possible for a client to leak its credentials if it makes a bare HTTP/1 call to an actual HTTPS endpoint. The server only gets a chance to reject its invalid TLS handshake after it's already sent headers that may contain sensitive information. After all, the TCP negotiation did go through, and the first layer 7 packet is the bare HTTP headers.

Of course the port numbers should help here, but that's not guaranteed in an environment where port numbers are assigned dynamically and rely on service discovery.

Serving exclusively HTTP/3 should close this gap but requires all clients to be ready for that. I know many internal deployments do this, but it's not a universal solution yet.

Re: API Shouldn't Redirect HTTP to HTTPS

#252

Post by jensenbox »

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.

Re: API Shouldn't Redirect HTTP to HTTPS

#253

Post by fl0ki »

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

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 defaults in the service's configuration is natural and intuitive.

I make sure my example configurations are as close to what will be needed in production as possible, including not just TLS but at least one "mutual TLS" validation. I even sync these back from production if it turns out something had to be changed, so the examples in the repository and built artifact are in line with production.

Yet I routinely find at least some of these disabled in at least some production deployments, presumably because the operator saw a shortcut and took it.

Let's rework Murphy's original law: if there are multiple ways to deploy something and one of those will be a security disaster, someone will do it that way.

Re: API Shouldn't Redirect HTTP to HTTPS

#254

Post by ozim »

superkuh wrote: post #63
ozim wrote: post #22

Earlier quoted context omitted.

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.

If that's your threat model then CA TLS is going to make things even worse for you because now the nation state pressure can be centralized and directed through the CA. There are trade-offs but HTTP has it's place. HTTP is far easier to set up, more robust, far more decentralized, supports far more other software, and has a longer lifetime. For humans who aren't dealing with nation state threat models those attribute…

Were you familiar with Snowden revelations?

How NSA was just putting gear in ISPs or nodes where are internet gateways to pass all traffic through their automated tooling?

It was not monetary or business it is not “threat model” thing. Having all traffic encrypted is a must for basic human freedom.

Re: API Shouldn't Redirect HTTP to HTTPS

#255

Post by noirscape »

bruce511 wrote: post #249
noirscape wrote: post #215

Earlier quoted context omitted.

Honestly, hard disagree. I get the push for HTTPS, but setting up HTTPS nowadays isn't fun. It's more or less 4 steps; 1. Install and run certbot (+the DNS plugin for your DNS provider). 2. Find an nginx config file on the internet that only includes the necessary ciphers to work on modern devices. Then include that config file + lines to your cert paths that certbot spits out into your nginx config. 3. Set up a gene…

I'm not sure if you're being sarcastic here or not? I mean you listed "reboot" as a whole step... which suggests sarcasm (at least to me)... Anyway, all the steps together take what - all of 5 minutes? - that's if you do DNS Challenges. If you do HTTP challenges it doesn't even take that. So you're saying this 5 minutes isn't worth the effort? That it's somehow too hard?

It's worth the effort, I just wouldn't use the descriptor of it being "fun". It's busywork equivalent to pointing nginx at your PHP socket. It's not fun, you're just wrangling a config file until it does what you want and the modern browsing landscape disproportionately demands HTTPS everywhere even for sites that arguably aren't really helped by it.

Re: API Shouldn't Redirect HTTP to HTTPS

#256

Post by ants_everywhere »

mbreese wrote: post #162
ants_everywhere wrote: post #151

Earlier quoted context omitted.

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.

Good point.

I guess this might depend a little on the implementation. In some cases the http endpoint may exist but may only be accessible to a sidecar container via localhost. For example, if the sidecar terminates https.

Re: API Shouldn't Redirect HTTP to HTTPS

#257

Post by superkuh »

ozim wrote: post #254
superkuh wrote: post #63

Earlier quoted context omitted.

If that's your threat model then CA TLS is going to make things even worse for you because now the nation state pressure can be centralized and directed through the CA. There are trade-offs but HTTP has it's place. HTTP is far easier to set up, more robust, far more decentralized, supports far more other software, and has a longer lifetime. For humans who aren't dealing with nation state threat models those attribute…

Were you familiar with Snowden revelations? How NSA was just putting gear in ISPs or nodes where are internet gateways to pass all traffic through their automated tooling? It was not monetary or business it is not “threat model” thing. Having all traffic encrypted is a must for basic human freedom.

It is a human freedom thing. Having to get continued permission to host a visit-able website from a CA is very un-free. That's why HTTP+HTTPS is so good. The best of both worlds with the downsides of neither.

Passive massive surveillance is by definition not doing active MITM targeting.

Re: API Shouldn't Redirect HTTP to HTTPS

#258

Post by sfn42 »

fl0ki wrote: post #253
Titan2189 wrote: post #138

Earlier quoted context omitted.

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

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

Re: API Shouldn't Redirect HTTP to HTTPS

#259

Post by gpvos »

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.

It should, but additional server-side mitigations are good for defense in depth. There may be people using a different client-side library, maybe because they use a different programming language.

Re: API Shouldn't Redirect HTTP to HTTPS

#260

Post by fl0ki »

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

It appears the trick they've found is to disable TLS on both ends :)
Post reply on HN