We previously left this in, since it's generally better to follow TLS
rules, but there's one case where it matters: when a client sends a
request without using SNI, and so the proxy may not show the right
certificate. We want to allow that, and to do so we need to ensure that
hostname checks are skipped (but only for our CA - not for any others,
which must still follow normal TLS rules).
This avoids the potential for bugs (calling the method directly does
dynamic lookup based on argument types, which may not match the called
method in ambiguous cases, e.g. int vs double are indistinguishable in
JS) and improves performance (skipping any dynamic method lookup).
This shouldn't significantly affect any normal usage (for Frida
scripts, redistribution _is_ distribution of the source code) but limits
the ability of others to directly turn these scripts into proprietary
closed source products elsewhere.
This seems to be used internally by some Android TLS connections - note
that this is OkHttp (v2 I think), but vendored into com.android and used
internally, not as a separate module.
Looks like they're actually the same implementation, it's just that
TrustKit inlined OkHttp's version.
These aren't required, as they doesn't implement certificate pinning,
and it's trivial to work around with any functional MitM setup: you
just have to return valid certs with the right hostnames. No need to
mess with that, best to check it properly, so dropped.
WebViews use the system trust successfully, so as soon as you inject
into the default TrustedCertificateIndex, they start trusting the
certificate happily.
Previously, all three allowed _any_ cert - they now delegate to our
pre-configured TrustManager that allows only the one trusted cert
(protecting against a meta-mitm). In addition, Appmattus now covers two
entirely new cases that were missed before (for HttpsUrlConn and manual
TLS validation).
This is covered more effectively by our injection of our system
certificate into the default trust store for all Conscrypt
implementations via the index.
Capturing just a few ports makes sense for device-wide capture, but for
targeted interception it makes more sense to intercept absolutely
everything and handle issues separately (or not at all).
This isn't required, because our system certificate injection
prepopulates the index used by all trust managers anyway, so they trust
our cert regardless. As configured, the previous hook just trusted _all_
certificates, exposing 3rd party MitM risk - better to keep it strict
for just our certificate where we can.
This only applied to a specific backport of Apache's HttpClient to
Android, from 2014, so this is pretty niche anyway.
Regardless of that, this doesn't actually do cert pinning - it just
disables all normal checks entirely. These scripts are intended to be
used for a working interception setup, so those shouldn't be required.
AbstractVerifier (in every version I can find) doesn't support check for
a specific cert or CA at all.
This is a notably different approach to the past certificate unpinning
setup. Through this new mechanism, we trust just one additional
certificate (instead of disabling cert verification entirely) and handle
just the standard Android certificate trust (we'll integrate unpinning
into this later).
This uses a hardcoded cert for now just for testing, but that will of
course be configurable in future.
Tim Perry