[PR] Enable TLS 1.3 by default#1282
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:
|
|
I support this change. TLS 1.3 is faster and Conscrypt lets you run it on down to Android 2.3 "Gingerbread", so compatibility isn't a problem. |
Fix #1278