Connect version 4.20 broke local http access?

The impetus for this change is, of course, Android Pie:

https://www.thesslstore.com/blog/https-will-now-be-the-default-for-all-android-p-apps/

My understanding is that it's possible to add exceptions for domains/IP addresses in the network security config. We're evaluating what we can do without exposing security holes that the new HTTPS requirements on these mobile platforms are attempting to address. 

I agree with the point made by Flowstate, but I don't know that we'll be able to go that far. I'd like to get a better understanding of what's needed vs. what would be nice to have. For example, would allowing an exception for localhost address the majority of the issues discussed in this thread? I know this doesn't help the home automation apps that are talking over private networks, but it would allow anyone using apps that leverage NanoHTTPD to get back up and working.

The impetus for this change is, of course, Android Pie:

https://www.thesslstore.com/blog/https-will-now-be-the-default-for-all-android-p-apps/

My understanding is that it's possible to add exceptions for domains/IP addresses in the network security config. We're evaluating what we can do without exposing security holes that the new HTTPS requirements on these mobile platforms are attempting to address. 

I agree with the point made by Flowstate, but I don't know that we'll be able to go that far. I'd like to get a better understanding of what's needed vs. what would be nice to have. For example, would allowing an exception for localhost address the majority of the issues discussed in this thread? I know this doesn't help the home automation apps that are talking over private networks, but it would allow anyone using apps that leverage NanoHTTPD to get back up and working.

This does indeed not help for the home automation apps, but that does not mean we are out-of-options:

The article also states that specific workarounds can be made in Android P:

This change will apply to each every app that will be made available on Android P. Granted, there are some specific workarounds for apps or users that may require an HTTP connection. A specific declaration will need to be made in the app’s manifest if any HTTP connections are required. Users will be able to control this via Android P’s Network Security Configuration file. Is this something to look into?

Or something else which would be better:: allow a self signed certificate for the 192.168.x.x networks?  a "no-check-certificate" and/or "private-key"  option to the webrequest, which can be used for specific use cases ?

I don't understand the point here. If you use HTTPS, then you have to have a trusted certificate, for both Apple and Android, as far as I can tell. 

You can't have a trusted certificate for localhost unless you get users to manually trust your self-signed certificate, or unless someone like Lets Encrypt decides to hand out certificates for localhost, which they won't, for obvious reasons.

To further illustrate the point, most web browsers treat HTTPS with a untrusted certificate as even worse than HTTP -- the former is blocked (with an inconvenient opt-out procedure) while the latter just gives a warning (for now). 

Just something to look at and consider.  If it's HTTP/HTTPS, maybe there's a easier way around the certificate problem.

You cannot have a valid certificate for localhost. So no TLS (https) at all.

Hopefully I'm not way off base here, but my understanding is that the problem isn't about running an HTTPS server per se, it's about the inability to (practically) make an HTTPS connection to localhost, with a trusted certificate. For example, if you use a browser to make an HTTPS connection to a website with an untrusted self-signed certificate, you still get a security warning. 

No certificate authority is going to hand out a trusted certificate for localhost, so afaik the only alternative would be to use a self-signed certificate, and ask all your end users to trust it manually (by installing your CA cert manually), which seems pretty onerous.