tls: use ooni/oocrypto rather than ooni/go #2106
Assignees
Labels
enhancement
improving existing code or new feature
methodology
issues related to the testing methodology
ooni/probe-engine
platform/android
priority/medium
research prototype
testing
Comments
bassosimone
added
enhancement
bassosimone
added a commit
to ooni/oocrypto
that referenced
this issue
May 22, 2022
This commit adds a factory that works like tls.Client and, in particular, takes in input a crypto/tls.Config pointer. We convert the config we receive to the config defined in this module by the tls package. If we don't know how to convert specific fields and those fields have a nonzero value, then we return an error. See ooni/probe#2106, which documents the effort of integrating this code inside ooni/probe-cli.
bassosimone
added a commit
to ooni/oocrypto
that referenced
this issue
May 22, 2022
feat(tls): add stdlib-aware Client-like factory See ooni/probe#2106
bassosimone
added a commit
to ooni/oocrypto
that referenced
this issue
May 22, 2022
By doing that, we can replace code in ooni/probe-cli that performs the TLS handshake with code using this library with minimal refactoring. See ooni/probe#2106
bassosimone
added a commit
to ooni/oocrypto
that referenced
this issue
May 22, 2022
feat(tls): NewClientConnStdlib should return oohttp.TLSConn like type See ooni/probe#2106
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
May 22, 2022
I have not upgraded ooni/go yet because I am also checking whether it would be possible instead to use ooni/oocrypto as documented in the ooni/probe#2106 issue. Closes ooni/probe#2070 Closes ooni/probe#2077
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
May 22, 2022
I have not upgraded ooni/go yet because I am also checking whether it would be possible instead to use ooni/oocrypto as documented in the ooni/probe#2106 issue. Closes ooni/probe#2070 Closes ooni/probe#2077
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
May 22, 2022
See ooni/probe#2106 for context.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
May 22, 2022
Rather than building for Android using ooni/go, we're now using ooni/oocryto as the TLS dependency. Such a repository only forks crypto/tls and some minor crypto packages and includes the same set of patches that we have been using in ooni/go. This new strategy should be better than the previous one in terms of building for Android, because we can use the vanilla go1.18.2 build. It also seems that it is easier to track and merge from upstream with ooni/oocrypto than it is with ooni/go. Should this assessment be wrong, we can revert back to the previous scenario where we used ooni/go. See ooni/probe#2106 for extra context.
|
Okay, so in ooni/probe-cli#751 I've implemented the above change and I have also archived https://github.com/ooni/go (which we need to keep around to build old versions). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our current strategy to ensure better TLS fingerprint on Android relies on building for Android using the https://github.com/ooni/go fork. However, this strategy makes building for Android not very practical, because we need to build our custom Go compiler. This issue is about trying out an alternative strategy where, instead, we make OONI depend on https://github.com/ooni/oocrypto instead of
src/crypto/tls. I am not sure upfront whether this new strategy would be better. I spent some time over this weekend trying to figure out the effort of maintaining a crypto/tls fork and discovered we need to also fork some other packages (e.g.,aes). Though, I think I have come up with a reasonable procedure for tracking from upstream. As such, I am now trying to make OONI depend on this fork and see what is the effort on the probe-cli side to make this actually possible.The text was updated successfully, but these errors were encountered: