Is OkHttp too eager in its blocking of non-HTTPS traffic on localhost? #8031
Comments
|
I think we are doing the right thing, it shouldn't be up to libraries to decide which hosts are safe to connect to. The app developer can configure this.
It can't really, when you make a connection, you get a list of Dns hosts, then make socket connections. It's not really guaranteed to be correct if the OS makes socket level decisions about when to allow connections. Since OkHttp makes a raw socket connection, and then applies TLS on top, when would Android make this decision? HTTP Client libraries need to implement the isCleartextTrafficPermitted check themselves, otherwise they are routing around Android security. An example from Ktor ktorio/ktor#3725
This isn't the same OkHttp. Both Grpc and Android have old forked copies of OkHttp 2. |
|
Thank you very much for quick response @yschimke! I learn a lot from it. I guess I'll try using the old OKHttp2 for now. In the long term, would it make sense to add an exclusion (in the snippet above) to OkHttp for e.g. |
|
No, I don't think OkHttp should override the network-security-config that the developer has put in place. |
|
Instead, your users should configure that thing to permit cleartext connections to localhost. |
Hi! First of all, thanks to all creators & maintainers of this awesome library.
Use case
I'm building a testing framework on top of JUnit4,
AndroidJUnitRunner, and Android Test Orchestrator. Now as you probably know, two apps are involved during instrumentation testing on Android – the app under test and the instrumentation app, and they run in the same process.Since I need two-way communication between these two apps, I went with gRPC (which works over HTTP/2 by default and uses OkHttp under the hood – correct me if I'm wrong). It has worked fine.
Problem
Because of reasons not important to this issue, I had to replace the existing gRPC networking with "plain" HTTP clients and servers. I chose to use OkHttp for the client running in the instrumentation app.
Here's how I build the client:
then I'm making a simple GET request to
http://localhost:8081.Unfortunately, when the client tries to make the request, the call fails because of Android security policy. Now, I know about
<network-security-config>and that I can setandroid:usesCleartextTraffic="true"inAndroidManifest– but I really can't do that, since it'd be a breaking change for users of my testing framework. And it's quite ugly.Stacktrace
After looking into the stacktrace, I found this code:
okhttp/okhttp/src/jvmMain/kotlin/okhttp3/internal/connection/RealRoutePlanner.kt
Lines 199 to 209 in d602ba2
And I think it's too eager in blocking unencrypted HTTP traffic? Shouldn't it be Android OS to decide whether to throw the SecurityException, not OkHttp?
This use case (HTTP traffic on localhost) was working fine when using gRPC.
Questions
localhostworked when OkHttp was used as a transport for gRPC, but fails when used standalone?HttpURLConnection, which since Android 5.0 is OkHttp under the hood?The text was updated successfully, but these errors were encountered: