-
-
Notifications
You must be signed in to change notification settings - Fork 486
[PR] Enable TLS 1.3 by default #1282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
99a8a3a
to
110244b
Compare
80d5a00
to
81b7d85
Compare
@QuantumBadger I fixed all CI problems that my new code introduces, but there are some problem came from updating target Android to 33 (A bunch of error when run |
Hi @thanhminhmr, thank you for the PR! I'm currently undecided whether it's a good idea to use Conscrypt in RedReader. It would be a fundamental change to the security model -- previously we've relied on the system APIs for TLS (and other native operations like image/video decoding), with all the app's logic written in Java/Kotlin. As a result there's never been a security issue discovered in RedReader, and we've never had to release an update for security reasons. Putting Conscrypt (and hence the native BoringSSL library) inside RedReader means that:
Conscrypt seems to get updated very infrequently -- it's only had one release in the last three years. I can't find records of any BoringSSL vulnerabilities since 2018, which is either a good sign or a bad sign 😂 It's a large C/C++ project, with the notoriously vulnerable OpenSSL as the base, and frankly I'd be impressed if they had precisely zero vulnerabilities in seven years of development (when OpenSSL has had a vast number in the same time). So, I'm not yet decided, and open to arguments either way! |
On the topic of the PR itself -- it would be good to remove all the dependency updates, as these are best handled separately (and I think there's another PR open for this already). It's possible to run Lint locally using |
81b7d85
to
9679f8c
Compare
I kind of agree with your points. Introducing a security related library that are not that trustworthy is not a good thing to do. For now I think restrict OkHttp to TLSv1.2 and TLSv1.3 is a better way to do it. There is a few nuance though:
|
Fix #1278