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.
Tried a few different routes, this seems most promising - works fairly
quickly (~100ms, measured from the remote client), and should be
reliable for all plausible implementations of ProxySelector, which
should cover both default & proxy-overriding implementations.
Definitely needs a configurable route (most likely we'll go through
Android properties here, I think? There's a few possiblities) and this
notably doesn't handle Flutter, which ignores all Java's proper APIs for
this (but I think I have some plans for that...)
This is crazy, but it seems to work! The case in point example here is
Vimeo, which is heavily obfuscated (so we can't reliably match method or
class names) but uses OkHttp internally, which uses the standard
exception types. We can spot those, so we do retrospective patching: the
first time a certificate validation fails, we disable the method that
threw the exception.
We'll still get one initial failure, but after that everything works
nicely. Wild.
Tim Perry