Certificate verify failed: self-signed certificate in certificate chain

[aktayozan]

using this command:

frida -U \ -l ./config.js \ -l ./native-connect-hook.js \ -l ./android/android-proxy-override.js \ -l ./android/android-system-certificate-injection.js \ -l ./android/android-certificate-unpinning.js \ -l ./android/android-certificate-unpinning-fallback.js \ -f com.bumble.app

with Android 11, I get this result:

== Redirecting all TCP connections to 192.168.0.105:8080 == Spawnedcom.bumble.app. Resuming main thread! [Android Emulator 5554::com.bumble.app ]-> == Proxy system configuration overridden to 192.168.0.105:8080 == == Proxy configuration overridden to 192.168.0.105:8080 == == System certificate trust injected == == Certificate unpinning completed == [+] TLS error auto-patcher Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:80 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:80 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:80 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:3:4d:79:62]:80 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443 Manually intercepting connection to [0:0:0:0:0:0:0:0:0:0:ff:ff:1f:de:43:cf]:443

But mitmproxy can not intercept requests, getting Certificate verify failed: self-signed certificate in certificate chain for this request :

GET https://dns.google.com/resolve?name=bma.bumble.com HTTP/1.1 User-Agent: Dalvik/2.1.0 (Linux; U; Android 11; sdk_gphone_x86 Build/RSR1.201013.001) Host: dns.google.com Connection: Keep-Alive Accept-Encoding: gzip

Response: Certificate verify failed: self-signed certificate in certificate chain

[pimterry]

I think what you're saying is that there's an error after that dns.google.com request, right? Or do you mean there's an upstream issue in that request after the connection is accepted? Or something else?

If you can see the full URL and headers then the request has clearly been intercepted, so the certificate issue must refer to some other step somewhere.

Can you share a screenshot of whichever errors you're seeing?

I've done a quick bit of digging myself out of curiosity, and on my setup (with HTTP Toolkit) I can intercept those DNS requests fine, and everything seems to work OK, but the app never starts. Looking elsewhere, there's requests to fclcdn.com which contain errors about certificate validation (even though no connections fail - it looks like the connections may stay open and just send nothing, even if they don't like the cert).

Looking more closely at the traffic, I think the issue (for both mitmproxy & HTTP Toolkit) is that the client isn't sending a server name at all in this connection, so we don't know what hostname to include in the resulting certificate, and basic hostname checks fail. Notably this looks intentional, e.g. when connecting to 31.222.67.207 (the IP I see for bma.bumble.com) with openssl s_client directly - you receive a *.bumble.com certificate even though the hostname name isn't specified in the connection.

I added a quick patch to work around all that (by making all overloads for com.android.okhttp.internal.tls.OkHostnameVerifier.verify() just return true for now - hacky but effective) and the traffic is now sent, but it's notably not HTTP. From a quick skim, I think these is raw protobuf being sent over TCP - you'll need a way to extract and interpret that.

I'll look into a proper fix for hostname verifiers to handle this better soon. If you're seeing the same issue as me (it'd help if you could share more details about the error) then that might help, but you'll still need to work out how to handle the protobuf afterwards.

[HumairaFasih]

(EDIT: Moved to https://github.com/httptoolkit/frida-interception-and-unpinning/issues/61)

[aktayozan]

With your new update i can able to capture raw datas, now i will try to handle protobuf requests. But the app still not starting.

[aktayozan]

I figured out how to capture and parse protobuf datas, just need to figure out why the app still refusing to start.

[pimterry]

Ok, great. If you now have working protobuf traffic going back and forth, I think any further steps are probably not related to networking & interception, so I'm going to close this issue.

If you do find any more network-related details or any other ways the scripts could be improved, do please share more info here and I'll extend them to cover that automatically in future. Thanks for reporting this, being able to improve the hooks around OkHostnameVerifier is a great improvement for everybody!