7 ms·

Or better: actually provide the API on HTTP and HTTPS if your use case allows it (ie, non-commercial/institutional, just something for human people).

x86a 2y ago
I don't think this is ever a good idea. Even for non-enterprise use cases, you wouldn't want some public hotspot to be able to inject random garbage into responses, even if not done with malicious intent.
- Wowfunhappy 2y ago
  • It allows retro computers to connect. • It allows very low power embedded devices to connect without extra overhead. • It's not a real security concern if you're on a private network.
  - rascul 2y ago
    > • It's not a real security concern if you're on a private network. I'm not convinced that private networks should be assumed secure by default.
    - TeMPOraL 2y ago
      It's definitely not improving security when, in order for a website to interact with an API that both are hosted on my private network, possibly even on the same machine, I need to set up publicly accessible DNS entries and/or hosting my own resolver. That and CORS makes local-first anything a huge PITA.
    - Control8894 2y ago
      Perhaps, but the other realistic option is a self-signed cert. Since browsers refuse to implement any kind of TOFU or otherwise 'trust history', a self-signed cert is pretty much exactly equivalent to no TLS at all.
    - Jach 2y ago
      I setup a photo viewing web service running locally on my home computer, now I can access my photos over HTTP from my phone when I'm out and about. Both devices are on the same Tailscale network. If I can't trust in the security of that, HTTPS isn't going to help me, and the security of viewing my photos is the least of my concerns. But sure, in other contexts (like an enterprise company), some thought should be given to what's possible when the attacker is inside the corporate VPN since that's all too easy.
  - zzo38computer 2y ago
    Yes, I think these are valid reasons. If you are still concerned, you can make API keys that have been registered by TLS to require TLS, while those that haven't, do not require TLS. (However, the note about private networks only applies if you run the service yourself. Sometimes this will be the case, though. Even then, the administrators can configure it to use TLS if this is desired.)
- smaudet 2y ago
  > Even for non-enterprise use cases I don't think non-enterprise, non machine use cases should be automatically handles, though. Attempting client upgrade is better than not, but we should be more clear about whether our devices are acting safely, i.e. calling out the change, and in the case of http local usage, reminding to use visible, out of band verification methods. Of course this only works if the default is secure, but I am glad that browser still let me go unencrypted when I really need to, I prefer the giant warning banners...
moralestapia 2y ago
No, HTTP would expose any sensitive information. It's just clear text.
- iJohnDoe 2y ago
  Does HTTPS also hide the URL request in most logging systems? You can always see the domain (api.example.com) but you cannot see the URL? The benefit being it hides an API key if included in the URL?
  - Aachen 2y ago
    The benefit is that it: 1. hides any private information anywhere in the request, URL or otherwise, API key or otherwise. Maybe you're fine if someone knows you used Bing (revealed through DNS lookups), but not what query you entered (encrypted to be decryptable only by Bing servers). An API key is obviously secret but something as oft-innocuous as search queries can also be private. 2. disallows someone on the network path from injecting extra content into the page. This can be an ISP inserting ads or tracking (mobile carriers have been playing with extra HTTP headers containing an identifier for you for advertising reasons iirc) or a local Machine-in-the-Middle attack where someone is trying to attack another website you've visited that used https.
  - yjftsjthsd-h 2y ago
    Yes, it hides the URL, although sadly not the domain.
    - taftster 2y ago
      It hides the domain too, in the literal HTTP request. What it doesn't hide is the DNS lookup for that domain. You still have to translate a hostname into an IP address. This might be a concern for certain uses. But at least it's on another port and protocol and not directly related to the HTTP request itself.
      - yjftsjthsd-h 2y ago
justin_oaks 2y ago
I'll disagree on these grounds: 1) HTTP can be modified by a man in the middle 2) It's better to default to requests and responses being private, even if you're only using a non-commercial/institutional service. You could say "The person chose to send requests to HTTP instead of HTTPS" and assume that the consumer of the API didn't care about privacy but, as the article points out, it's easy to typo http instead of https.
ozim 2y ago
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.
- superkuh 2y ago
  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 attributes make it very attractive and useful. We should not cargo cult the requirements for a multi-national business that does monetary transactions and sends private information with a website run by a human person for recreation and other humans. There is more to the web than commerce and we should design for human persons as well as corporate persons.
  - ozim 2y ago
    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.
    - superkuh 2y ago
      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.
  - ric2b 2y ago
    ISP's have been known to inject ads into HTTP pages, and ads are the least malicious thing that could be done by an ISP or wifi hotspot. HTTP MITM is way too cheap and accessible to pretend you're not vulnerable to it constantly or that you need to be a target, you don't.
codepoet80 2y ago
You’ve already been shouted down, but thank you for daring to suggest this. I maintain APIs and proxies for APIs for legacy devices, and will continue to suggest that some kinds of APIs remain appropriate for HTTP access. Never do your banking this way, obviously, but where is the harm in allowing older devices to access content in a read-only fashion?
- taftster 2y ago
  Hypothetically speaking, plain HTTP transport even for "read only" content, can be a problem if it can be manipulated in transit. Let's take a weather service. Seems like weather information is a read-only immutable fact and should not be something that needs protection from MITM attacks. You want to reach the largest audience possible and your authoritative weather information is used throughout the world. One day, an intermediary system is hijacked which carries your traffic, and your weather information can be rewritten in transit. Your credibility for providing outstanding data is compromised when you start serving up weather information that predicts sunny skies when a tornado watch is in effect. Additionally, you have now leaked information related to the traffic of your users. Even if the request is just vanilla HTTP-only, an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic. They also inject a javascript payload into your traffic that starts computing bitcoin hashes and you are blamed for spreading malware. In general, HTTPS protects both your interests and those of your users, even for benign data that doesn't necessarily need to sit behind "an account" or a "web login".
  - smaudet 2y ago
    > an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic I think this is the most convincing argument, but, I think that some data doesn't care if it is not confidential. The weather is perhaps more pointed, but I think for large protected binaries (either executable or inscrutable, e.g. encrypted or sig protected archives), its a bit moot and possibly only worse performing. However, also remember that https does not protect all data, just the application portion - adversaries can still see, map, and measure traffic to bobthebaker.com and sallyswidgets.biz. To truly protect that information, https is the wrong protocol, you need something like Tor or similar bit mixing.
cqqxo4zV46cp 2y ago
How is this better in literally any way other than it makes things (in 2024, only very slightly) easier from an ops perspective, and panders to some nerdy fetish for simple ‘read it over wireshark’ protocols? HTTPS-only should be the default. Plain-text information delivery protocols that can easily be MITMd are unsuitable for almost all uses. This just feels like contrarianism.
- superkuh 2y ago
  I guess I have to respond with the same thing over and over because there are so many people saying the same thing without reading the replies. HTTP is better because: it lasts forever without mantainence, it's easier to learn set up with no third parties required, all software can access a HTTP website, it's low resource requirements, and HTTP+HTTPS is perfectly fine. Whereas CA TLS only lasts a year or two without mantainence, is so complex to set up and keep running that a literal ecosystem of programs (acme, acme2, etc) exist to hide that complexity, only software within the last ~few years can access CA TLS websites because of TLS version sunsetting and root cert expirations and the like, and everyone centralizing in the same CA makes it extremely easy to apply political/social pressures for censorship in a CA TLS only browser world. Additionally requiring third party participating to set up a website makes it harder for people to learn how to run their own and it requires more compute resources. CA TLS only feels like it should be "required" when the person can't imagine a web browser that doesn't automatically run all untrusted code sent to it. When the only types of websites the person can image are commercial or institutional rather than personal and the person believes all the web should cargo cult the requirements of commerce. Personal websites involving no monetary or private information transactions don't actually need to worry about targeted MITM and there's no such thing as open wireless access points anymore.
  - ric2b 2y ago
    HTTP MITM doesn't need to be targeted, it could just as well be a crypto-miner script injected into every HTML response that passes through some box. People need to stop pretending that HTTP injection is complicated enough to only happen in targeted scenarios, it's not, it's completely trivial.

x86a 2y ago

I don't think this is ever a good idea. Even for non-enterprise use cases, you wouldn't want some public hotspot to be able to inject random garbage into responses, even if not done with malicious intent.

Wowfunhappy 2y ago
• It allows retro computers to connect. • It allows very low power embedded devices to connect without extra overhead. • It's not a real security concern if you're on a private network.
- rascul 2y ago
  > • It's not a real security concern if you're on a private network. I'm not convinced that private networks should be assumed secure by default.
  - TeMPOraL 2y ago
    It's definitely not improving security when, in order for a website to interact with an API that both are hosted on my private network, possibly even on the same machine, I need to set up publicly accessible DNS entries and/or hosting my own resolver. That and CORS makes local-first anything a huge PITA.
  - Control8894 2y ago
    Perhaps, but the other realistic option is a self-signed cert. Since browsers refuse to implement any kind of TOFU or otherwise 'trust history', a self-signed cert is pretty much exactly equivalent to no TLS at all.
  - Jach 2y ago
    I setup a photo viewing web service running locally on my home computer, now I can access my photos over HTTP from my phone when I'm out and about. Both devices are on the same Tailscale network. If I can't trust in the security of that, HTTPS isn't going to help me, and the security of viewing my photos is the least of my concerns. But sure, in other contexts (like an enterprise company), some thought should be given to what's possible when the attacker is inside the corporate VPN since that's all too easy.
- zzo38computer 2y ago
  Yes, I think these are valid reasons. If you are still concerned, you can make API keys that have been registered by TLS to require TLS, while those that haven't, do not require TLS. (However, the note about private networks only applies if you run the service yourself. Sometimes this will be the case, though. Even then, the administrators can configure it to use TLS if this is desired.)
smaudet 2y ago
> Even for non-enterprise use cases I don't think non-enterprise, non machine use cases should be automatically handles, though. Attempting client upgrade is better than not, but we should be more clear about whether our devices are acting safely, i.e. calling out the change, and in the case of http local usage, reminding to use visible, out of band verification methods. Of course this only works if the default is secure, but I am glad that browser still let me go unencrypted when I really need to, I prefer the giant warning banners...

moralestapia 2y ago

No, HTTP would expose any sensitive information. It's just clear text.

iJohnDoe 2y ago
Does HTTPS also hide the URL request in most logging systems? You can always see the domain (api.example.com) but you cannot see the URL? The benefit being it hides an API key if included in the URL?
- Aachen 2y ago
  The benefit is that it: 1. hides any private information anywhere in the request, URL or otherwise, API key or otherwise. Maybe you're fine if someone knows you used Bing (revealed through DNS lookups), but not what query you entered (encrypted to be decryptable only by Bing servers). An API key is obviously secret but something as oft-innocuous as search queries can also be private. 2. disallows someone on the network path from injecting extra content into the page. This can be an ISP inserting ads or tracking (mobile carriers have been playing with extra HTTP headers containing an identifier for you for advertising reasons iirc) or a local Machine-in-the-Middle attack where someone is trying to attack another website you've visited that used https.
- yjftsjthsd-h 2y ago
  Yes, it hides the URL, although sadly not the domain.
  - taftster 2y ago
    It hides the domain too, in the literal HTTP request. What it doesn't hide is the DNS lookup for that domain. You still have to translate a hostname into an IP address. This might be a concern for certain uses. But at least it's on another port and protocol and not directly related to the HTTP request itself.
    - yjftsjthsd-h 2y ago

justin_oaks 2y ago

I'll disagree on these grounds: 1) HTTP can be modified by a man in the middle 2) It's better to default to requests and responses being private, even if you're only using a non-commercial/institutional service. You could say "The person chose to send requests to HTTP instead of HTTPS" and assume that the consumer of the API didn't care about privacy but, as the article points out, it's easy to typo http instead of https.

ozim 2y ago

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.

superkuh 2y ago
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 attributes make it very attractive and useful. We should not cargo cult the requirements for a multi-national business that does monetary transactions and sends private information with a website run by a human person for recreation and other humans. There is more to the web than commerce and we should design for human persons as well as corporate persons.
- ozim 2y ago
  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.
  - superkuh 2y ago
    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.
- ric2b 2y ago
  ISP's have been known to inject ads into HTTP pages, and ads are the least malicious thing that could be done by an ISP or wifi hotspot. HTTP MITM is way too cheap and accessible to pretend you're not vulnerable to it constantly or that you need to be a target, you don't.

codepoet80 2y ago

You’ve already been shouted down, but thank you for daring to suggest this. I maintain APIs and proxies for APIs for legacy devices, and will continue to suggest that some kinds of APIs remain appropriate for HTTP access. Never do your banking this way, obviously, but where is the harm in allowing older devices to access content in a read-only fashion?

taftster 2y ago
Hypothetically speaking, plain HTTP transport even for "read only" content, can be a problem if it can be manipulated in transit. Let's take a weather service. Seems like weather information is a read-only immutable fact and should not be something that needs protection from MITM attacks. You want to reach the largest audience possible and your authoritative weather information is used throughout the world. One day, an intermediary system is hijacked which carries your traffic, and your weather information can be rewritten in transit. Your credibility for providing outstanding data is compromised when you start serving up weather information that predicts sunny skies when a tornado watch is in effect. Additionally, you have now leaked information related to the traffic of your users. Even if the request is just vanilla HTTP-only, an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic. They also inject a javascript payload into your traffic that starts computing bitcoin hashes and you are blamed for spreading malware. In general, HTTPS protects both your interests and those of your users, even for benign data that doesn't necessarily need to sit behind "an account" or a "web login".
- smaudet 2y ago
  > an adversary can see that your users from one region are interested in the weather and can start building a map of that traffic I think this is the most convincing argument, but, I think that some data doesn't care if it is not confidential. The weather is perhaps more pointed, but I think for large protected binaries (either executable or inscrutable, e.g. encrypted or sig protected archives), its a bit moot and possibly only worse performing. However, also remember that https does not protect all data, just the application portion - adversaries can still see, map, and measure traffic to bobthebaker.com and sallyswidgets.biz. To truly protect that information, https is the wrong protocol, you need something like Tor or similar bit mixing.

cqqxo4zV46cp 2y ago

How is this better in literally any way other than it makes things (in 2024, only very slightly) easier from an ops perspective, and panders to some nerdy fetish for simple ‘read it over wireshark’ protocols? HTTPS-only should be the default. Plain-text information delivery protocols that can easily be MITMd are unsuitable for almost all uses. This just feels like contrarianism.

superkuh 2y ago
I guess I have to respond with the same thing over and over because there are so many people saying the same thing without reading the replies. HTTP is better because: it lasts forever without mantainence, it's easier to learn set up with no third parties required, all software can access a HTTP website, it's low resource requirements, and HTTP+HTTPS is perfectly fine. Whereas CA TLS only lasts a year or two without mantainence, is so complex to set up and keep running that a literal ecosystem of programs (acme, acme2, etc) exist to hide that complexity, only software within the last ~few years can access CA TLS websites because of TLS version sunsetting and root cert expirations and the like, and everyone centralizing in the same CA makes it extremely easy to apply political/social pressures for censorship in a CA TLS only browser world. Additionally requiring third party participating to set up a website makes it harder for people to learn how to run their own and it requires more compute resources. CA TLS only feels like it should be "required" when the person can't imagine a web browser that doesn't automatically run all untrusted code sent to it. When the only types of websites the person can image are commercial or institutional rather than personal and the person believes all the web should cargo cult the requirements of commerce. Personal websites involving no monetary or private information transactions don't actually need to worry about targeted MITM and there's no such thing as open wireless access points anymore.
- ric2b 2y ago
  HTTP MITM doesn't need to be targeted, it could just as well be a crypto-miner script injected into every HTML response that passes through some box. People need to stop pretending that HTTP injection is complicated enough to only happen in targeted scenarios, it's not, it's completely trivial.