6 ms·

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 t

by Eduard 2y ago

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 revocation), a MITM with a shorter trip time to SE's servers could race for wrecking havoc until the revocation happens. Nevertheless, SE's revocation tactic contributes positively to a defense in depth strategy.

Titan2189 2y ago
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
- throw__away7391 2y ago
  That's a very good point, I agree. You're always going to run a service at least once.
- fl0ki 2y ago
  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.
  - sfn42 2y ago
    Won't those people have the same experience? The app won't work until they configure it securely
    - fl0ki 2y ago
      It appears the trick they've found is to disable TLS on both ends :)
    - ljm 2y ago
      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
- fwip 2y ago
  The MITM can be between the developer's machine and Stack Overflow, e.g: the classic Evil Cafe Wifi.
lofenfew 2y ago
There's absolutely nothing you can do to prevent an active MITM attack over HTTP
- amscanne 2y ago
  Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?
  - grantism 2y ago
    What's stopping the MITM just copying that header?
    - gruez 2y ago
      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.
      - dcow 2y ago
        Some of these include a nonce and/or are deployed over TLS to prevent replay attacks and avoid sending bearer tokens over the wire. AWS sig v4 and RFC7616 come to mind.
    - 4death4 2y ago
      Even if the copy the header, they can only perform a replay attack, which is an improvement over leaking an API key. Also, you could include a timestamp in the signature to limit the amount of time it could be replayed.
      - dcow 2y ago
        Sign a nonce.
    - amscanne 2y ago
dotancohen 2y ago
> that's more secure, but still not bulletproof I've never heard of bulletproof ever actually being achieved in IT security. Not even air gaps.
- adrianN 2y ago
  You tend to only hear about the systems where security was successfully broken, not the systems nobody managed to penetrate.
- vitiral 2y ago
  The thing about bullet proof is that nothing is bulletproof when you have a big or fast enough bullet
  - lukan 2y ago
    Yes, but what is meant, that it provides protection against common calibers. So you can have bullet proof security in IT. That does not mean it is blast proof, or acid resistant, or prevents someone using a backup key on the second entrance. It is just a metapher saying this security is very solid. Might be true, or not, but that nothing is 100% secure is quite known.
UncleMeat 2y ago
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 where we are happy building systems that improve security posture even if they don't fix everything.
- tessierashpool 2y ago
  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.
  - JohnFen 2y ago
    > we had (and still have today) all the technology required to build genuinely secure systems. True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been. Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willing to work with for a particular use case. There's a reason that most people don't secure their houses by removing all windows and installing vault doors.
    - j5155 2y ago

by Eduard 2y ago

Titan2189 2y ago

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

throw__away7391 2y ago
That's a very good point, I agree. You're always going to run a service at least once.
fl0ki 2y ago
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.
- sfn42 2y ago
  Won't those people have the same experience? The app won't work until they configure it securely
  - fl0ki 2y ago
    It appears the trick they've found is to disable TLS on both ends :)
  - ljm 2y ago
    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
fwip 2y ago
The MITM can be between the developer's machine and Stack Overflow, e.g: the classic Evil Cafe Wifi.

lofenfew 2y ago

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

amscanne 2y ago
Have the authentication header effectively be a signed hash of relevant headers and the full URL, rather than a simple bearer token?
- grantism 2y ago
  What's stopping the MITM just copying that header?
  - gruez 2y ago
    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.
    - dcow 2y ago
      Some of these include a nonce and/or are deployed over TLS to prevent replay attacks and avoid sending bearer tokens over the wire. AWS sig v4 and RFC7616 come to mind.
  - 4death4 2y ago
    Even if the copy the header, they can only perform a replay attack, which is an improvement over leaking an API key. Also, you could include a timestamp in the signature to limit the amount of time it could be replayed.
    - dcow 2y ago
      Sign a nonce.
  - amscanne 2y ago

dotancohen 2y ago

> that's more secure, but still not bulletproof I've never heard of bulletproof ever actually being achieved in IT security. Not even air gaps.

adrianN 2y ago
You tend to only hear about the systems where security was successfully broken, not the systems nobody managed to penetrate.
vitiral 2y ago
The thing about bullet proof is that nothing is bulletproof when you have a big or fast enough bullet
- lukan 2y ago
  Yes, but what is meant, that it provides protection against common calibers. So you can have bullet proof security in IT. That does not mean it is blast proof, or acid resistant, or prevents someone using a backup key on the second entrance. It is just a metapher saying this security is very solid. Might be true, or not, but that nothing is 100% secure is quite known.

UncleMeat 2y ago

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 where we are happy building systems that improve security posture even if they don't fix everything.

tessierashpool 2y ago
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.
- JohnFen 2y ago
  > we had (and still have today) all the technology required to build genuinely secure systems. True, but if we actually did that, it would make those systems very unpleasant to use. The age-old tradeoff of security vs convenience is still as much a force today as is always has been. Having technically the tightest possible security is not always the right answer. The right answer is whatever balance people are willing to work with for a particular use case. There's a reason that most people don't secure their houses by removing all windows and installing vault doors.
  - j5155 2y ago