TLSv1 Support Dropped?

I'm the developer of Giant Bomb Video Buddy and I recently starting receiving reports that users on Android versions < 5.0 are receiving connection errors 100% of the time. I did some investigating and it appears that the issue is that giantbomb.com is now rejecting all TLSv1 cipher suites. Is this going to be the case going forward, or is it just a temporary configuration?

I ask because, if it is a permanent change, I will need to push an update that manually enables TLSv1.1 for users of Android 4.1 and newer, but drops support for users of Android v4.0.4 (which only supports TLSv1). They're in the minority, but I wanted to check before giving anyone the boot.

Edit: I've been in an HTTPS mindset lately and initially overlooked the option of having the app fall back to an unencrypted connection on devices that can't readily support TLSv1.1. That would be an alternative for older devices if TLSv1 support is gone for good.

@soup_menu: Hey there,

Due to our payment vendor (Recurly), we had to upgrade our TLS version requirements for 1.1 and above.

We should have notified our users and app developers ahead of time, but that didn't happen. Sorry for that.

Unfortunately, you will have to update your app. And, yes, unfortunately, you might want to think about allowing http fallback for old android users (maybe you just give them a prompt/warning).

Let me know if I can do anything to help you on this.

@jslack: Thanks for following up.

@harlekinrains: Hey there.

Just so you know, I read all of your comments (deleted ones). I was going to respond with a long response, but I'm going to leave it at this: I'm sorry that the change was made, and I'm sorry that more notice wasn't given, I agree with you that it's not ideal. Our payment processor wants to enforce more secure protocols to keep your data safe, which is why the TLS version was bumped up. It's a hard compromise.

Jim Porter (the creator of the current Kodi Addon which also breaks on Android devices below 5.0 (you know, like most Android set top boxes out there)) just got back to me and pointed me to a temporary fix, which he probably wont roll into his main development branch - because, leaving https out of the addon as "a way forward" also is problematic.

In addition as I mentioned before, version detection or a dynamic workaround to this issue from within Kodi is almost impossible to do as well - as everything depends on a chain of trust, that the OS can handle https handshakes to a server on which GB just decided, well - lets break backwards compatibility to every Android OS device below 5.0 - as a default.

The workaround is simple enough - just change line 31 in the giantbomb.py file

https://github.com/jimporter/giantbomb-kodi/blob/master/plugin.video.giantbomb/resources/lib/giantbomb.py#L31

and remove the s (from https). Reboot (twice if you get resolving errors on the links), and thats it.

If you dont know how to edit files on your Android set top box, or how to "make" a functioning addon zip file for Kodi, you can also still use the abandoned (as in abandoned by Whiskey Media) old XBMC/Kodi addon version 3.5.1, which also doesnt care about ssl at all.

--

This also means, that should you (Giant Bomb) decide to ever break compatibility to your api backend without encrypted (ssl) connections - all Android users on devices running anything below Android 5.0 (which is the majority of devices out there - and update ratios on Android based TV boxes are even more abysmal than on phones) are out of the loop and wont be able to access any GB content on Kodi based frontends.

Version 5.0a1 of the Kodi add-on (just released) has an advanced option to disable HTTPS, which should resolve this for people who use Kodi on older Android versions.

@soup_menu TLSv1 has been insecure for quite a while at this point and should be considered EoL, you can read more on that here: https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf, even 1.1 shouldn't be used any longer. Android 4.0 was released in 2011, if someone is still using such an old release then that is their fault and they should upgrade, it's not your job to support insecure SSL protocols. In fact it should be your job to REFUSE support of those releases to protect users. @jslack honestly I'm surprised the payment processor is even using 1.1, they should really be refusing to use anything less than 1.2.

@gravytrain: Correct, it should be. The only reason they are allowing an older implementation is for reasons like this, at least 1.1 fixes the most well known issues. Damned if we do, damned if we don't. Hopefully in the near future, it's 1.2 only.

@jslack: Good point. It's such a pain to support that kind of stuff. I always love seeing the numbers justifying support of some super old protocol for some 2% of users that are still running IE6 or whatever nonsense.

@gravytrain: Ya for sure, eventually have to move on. I just hate to break support like the guy above - I really care about the users, whether or not they believe it.

@jslack: I know duder!