Bug: ios 17 and obsidian 1.5.7 cannot send http request now

[fyears]

I have upgraded to latest ios and obsidian, and it seems that the plugin api cannot send http (NOT https) requests now.

proof, add ribbon to trigger http request easily on ios:

    this.syncRibbon = this.addRibbonIcon(
      'dice',
      `send http`,
      async () => {
        requestUrl({
          'url': 'http://httpbin.org/get',
          throw: false
        }).then((rsp)=> {
          new Notice(JSON.stringify(rsp.json,null,2));
        }).catch(e=> {
          new Notice(e.stack);
          new Notice(e.name);
          new Notice(e.message);
        })
      }
    );

    this.syncRibbon = this.addRibbonIcon(
      'apple',
      `send https`,
      async () => {
        requestUrl({
          'url': 'https://httpbin.org/get',
          throw: false
        }).then((rsp)=> {
          new Notice(JSON.stringify(rsp.json,null,2));
        }).catch(e=> {
          new Notice(e.stack);
          new Notice(e.name);
          new Notice(e.message);
        })
      }
    );

The https request can be sent normally, the http request cannot be sent and show up the error:

[WhiteNoise]

The underlying frameworks and OSes we use are removing http use. This already happened on Android.

[kceiw]

Can you please support self signed certificate for https? See this thread [Feature Request] Allow user-supplied root certificates (weaken security)

Your team cited a link about browsers banning some root certificates. But no browsers ban self signed certificates. There are warnings though.

Since http is not supported anymore, it’s not possible to run any plug ins that talk inside a local network.

[WhiteNoise]

I am going to double check this.

[fyears]

thank you for responding this. however, (in my opinion), requesturl is an alternative to fetch to avoid cors problems, so the api itself should not block http directly.

is it impossible to workaround this now? or, at least for localhost / lan, etc. i personally prefer and encourage users to use https but some users are using http over lan, not public internet.

furthermore, actually http doesn’t work for ios but works for windows.

[fyears]

yes i think supporting self signed certificates might be a solution. right now pc and mobile obsidian both don’t support them.

(though, actually that doesn’t add much security compared with pure http)

[fyears]

hello, any updates or final decisions on the issues “not supportting http” and “consider supporting custom https certificates “?

[Licat]

So I’ve done some reading on the http situation on iOS. Apple has been pushing this really hard and unfortunately I believe this seems to have started applying when we upgraded the target iOS version support when we did the capacitor upgrade from 3 to 5.

The configuration options we now have with “App Transport Security” (the network restriction part of iOS) is either:

• Disallow http altogether
• Allow http from a specific hard-coded list of domains that is compiled and signed into the app’s Info.plist
• Disable ATS altogether, allowing http, but at the same time disable SSL certificate checks for https. Meaning invalid SSL certificates will not generate an error.

Unfortunately I don’t think a hard-coded list can help in your situation, and there is no way we can disable ATS because that disables the validation for https certificates.

If you are able to find a way to configure an iOS app to allow http but still maintain full https security then I would not mind looking into it, but as far as my research goes it doesn’t seem possible.

In your case, I would advise your users to setup let’s encrypt to create SSL certificates for free. It will help securing the connection as well. Another alternative is using CloudFlare to proxy the traffic via https.

[fyears]

hi licat,

Thank you for your research and I understand the situation and your concerns now. But I have two last questions, would you like to have a look at them?

1. will the http disallowance also apply to android, pc/mac/linux now , or in the near future?
2. most of my users use http mainly for lan, is it possible to allow http only on local ip ranges (127.x.x.x, 192.x.x.x, etc) (according to your method 2)

thanks for all your helps!

[WhiteNoise]

@fyears

• will the http disallowance also apply to android, pc/mac/linux now , or in the near future?

Android has a similar mechanism, but it was possible to selectively disable it (for now). Major operating systems will phase out http, so it is entirely possible that at some point http will stop working.

[Licat]

So it seems like completely allowing http via NSAllowsArbitraryLoadsInWebContent doesn’t actually completely invalidate SSL checking; it just disables things like weak encryption/old TLS version protection, certificate pinning, etc. However, Apple’s docs says that by using one of these ways to bypass ATS protection, the app will be subject to additional app store review where we need to communicate with the reviewer of a sufficiently acceptable reason to use it (such as the app becomes broken due a service used by the app being on an older TLS version that is outside of our control). (Here’s the relevant docs from Apple)

I think it’s not something we’d want to risk getting rejected by the app store for unfortunately.

[fyears]

Yeah sure I totally understand that.

So that’s it, I would precheck the http address in my plugin and tell users “Apple restricts http, use https”, etc.

In the same time, I would suggest you also do something similar, changging the error type and description to “http not allowed, use https” to requesturl, rather than the unclear error message “request failed” (see my screenshot). So that any dev can easily figure out what happens!

Thanks all!

[Licat]

Thanks, I will add the OS provided error message in the next release.