TLSv1.2 support missing

Recently I changed my webserver configuration so that TLSv1.2 is the only protocol being offered. In the very same moment FDroid cannot find my repo anymore.

If I revert the configuration on the webserver so that it also offers TLSv1.0 all is fine again

We obviously didn't implement TLS support ourselves, it comes from Android.

What Android version are you using?

Maybe we need to explicitly enable it like so: https://stackoverflow.com/questions/16531807/android-client-server-on-tls-v1-2

I have the issue on Android 4.4.4 (latest available cm11 from freexperia for Sony Z1 compact).

Now I installed Cyanogen 12.1-20150712-NIGHTLY-amami (Android 5.1.1) and it works with the TLSv1.2-only webserver config.

Apparently TLS 1.1/1.2 are enabled by default on 20+, but available in 16+:

https://developer.android.com/reference/javax/net/ssl/SSLSocket.html

We probably want to enable them in 16+ explicitly. Patches welcome, it should be pretty straightforward.

I wonder why they aren't enabled on 16+ by default though...

Added ~18502 label

Other apps have fixed this already, e.g. see https://github.com/bitfireAT/davdroid/commit/f69f449b44133620bf4374900a4b6db05bcc7eed

We have fixes for this, and related issues like removing broken TLS ciphers, in our NetCipher library. There is are NetCipher versions of HttpURLConnection depending on how strict the TLS settings are. As long as the code is only using URLConnection, which I think FDroid is, then it would be easy to make this switch, see NetCipher.getHttpsURLConnection(). We'll be getting the jars into jcenter soon, so that'll make it even easier.

I personally think that FDroid should use the strictest version, but some people's old DIY HTTPS might not work then, for example, if they have only SSLv3 enabled or only old ciphers.

Strictly speaking, if people add repos with the fingerprints, HTTPS is just an extra layer so we don't need the strictest version. But if you want to use it and perhaps add an option to lower it - or deal with users who have problems with it - that sounds fine too.

Yes, the HTTPS is not needed to guarantee that the APKs are delivered unmodified, that's what the signed repo metadata does best. But the HTTPS connection provides privacy protection, preventing network observers from seeing which apps are being downloaded, updated, etc. HTTPS also serves as a backup in case of bugs in the metadata signing.

I've got this working with NetCipher, it turns out it was a good example case to test some ideas for the library. Pull request coming soon.

Milestone changed to 0.97

Reassigned to @eighthave

Fixed by 2c88703588a

Status changed to closed

hmm, why didn't the commit message close this? I guess only closes works, not fixes?

Both work usually. I'm attributing this to gitlab being kinda broken at the time.

Reopening since netcipher was temporarily reverted.

Status changed to reopened

Milestone removed

FWIW, reverted due to #431 (closed).

@eighthave in case you forgot, just a reminder that we had to disable NetCipher due to a regression it introduced. See above.

Milestone changed to 0.101

Milestone changed to %0.102

Status changed to closed

fixed by 4598a78bfdbd636438d6ea882c66a7f9daa9a3a7