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