3 ms·

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 tr

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.

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.