This is useful because it means that traffic which bypasses the proxy
(e.g. by using TLS passthrough or similar) will still succeed! This
makes it easier to handle any issues later on.
This is really cool. Rather than just blindly disabling all TLS
validation, we now verify the cert directly against the CA you provide.
We only do extremely basic checks (some more testing required to
validate this provides even basic guarantees) so this shouldn't be
relied for rock-solid TLS validation (probably even after it's been
tested tbh) and it won't handle many real-world cases of CA validation,
but in terms of "do a local MitM while retaining the basics of TLS
protection" it should do a reasonable job, hopefully.
This reverts commit 6eec741f5c.
This doensn't actually work correctly, as connect() will return -1
(treated here as failure) for sockets that are still in progress, when
opened non-blocking, and therefore we end up logging these as failures.
We need to handle async connection state detection - that's a bit fiddly
from inside Frida, so for now let's just roll this back.
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).
Tim Perry