Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-20431] Android: Google Play security alert for insecure TrustManager

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2016-03-21T02:10:46.000+0000
Affected Version/sRelease 5.1.2
Fix Version/sn/a
ComponentsAndroid
Labelsandroid, httpclient
ReporterLuca Sartori
AssigneeHieu Pham
Created2016-02-18T14:43:17.000+0000
Updated2018-08-06T17:57:44.000+0000

Description

Few days ago is appeared this message in google developer console for an app that i published several months ago: _Security alert Your app is using an unsafe implementation of the X509TrustManager interface with an Apache HTTP client, resulting in a security vulnerability. Please see this Google Help Center article for details, including the deadline for fixing the vulnerability. Please address this issue as soon as possible and increment the version number of the upgraded APK. Beginning May 17, 2016, Google Play will block publishing of any new apps or updates containing the unsafe implementation of the interface X509TrustManager._ https://support.google.com/faqs/answer/6346016 In my app i dont use https connections but simple http. How can fix this problem? Thank you in advance for reply

Comments

  1. Ygor Lemos 2016-02-18

    I have also received this security alert from Google today! It seems it needs to be fixed before May 17 otherwise all Ti new apps and updates won't be able to be uploaded to the Google Play Store.
  2. Rainer Schleevoigt 2016-02-18

    +1 I gave apps with http only connections and an app which connects with a lot of https servers with self-signed certs. Solution?
  3. Tim Poulsen 2016-02-18

    I got the same by email today: Hello Google Play Developer, Your app(s) listed at the end of this email use an unsafe implementation of the interface X509TrustManager. Specifically, the implementation ignores all SSL certificate validation errors when establishing an HTTPS connection to a remote host, thereby making your app vulnerable to man-in-the-middle attacks. An attacker could read transmitted data (such as login credentials) and even change the data transmitted on the HTTPS connection. If you have more than 20 affected apps in your account, please check the Developer Console for a full list. To properly handle SSL certificate validation, change your code in the checkServerTrusted method of your custom X509TrustManager interface to raise either CertificateException or IllegalArgumentException whenever the certificate presented by the server does not meet your expectations. For technical questions, you can post to Stack Overflow and use the tags “android-security” and “TrustManager.” Please address this issue as soon as possible and increment the version number of the upgraded APK. Beginning May 17, 2016, Google Play will block publishing of any new apps or updates containing the unsafe implementation of the interface X509TrustManager. To confirm you’ve made the correct changes, submit the updated version of your app to the Developer Console and check back after five hours. If the app hasn’t been correctly upgraded, we will display a warning. While these specific issues may not affect every app with the TrustManager implementation, it’s best not to ignore SSL certificate validation errors. Apps with vulnerabilities that expose users to risk of compromise may be considered dangerous products in violation of the Content Policy and section 4.4 of the Developer Distribution Agreement. Apps must also comply with the Developer Distribution Agreement and Content Policy. If you feel we have sent this warning in error, contact our policy support team through the Google Play Developer Help Center. Regards, The Google Play Team
  4. Michael Gangolf 2016-02-18

    The missing part is the end: {noformat} ti.modules.titanium.network.NonValidatingTrustManager; {noformat} is the problem. BUT my apps compiled and uploaded after Nov'15 don't have the problem. So the solution could be just upload an update with the latest SDK. Also they don't say what will happen with the not-updated apps. They just say they won't allow apps/updates with the problem after May 17th.
  5. Fokke Zandbergen 2016-02-18

    Weird, we do throw the exception they ask for there: https://github.com/appcelerator/titanium_mobile/blob/bc85170157d3bebc5de1d61a9fe6e34bce84a8c9/android/modules/network/src/java/ti/modules/titanium/network/NonValidatingTrustManager.java#L24
  6. Matt Poole 2016-02-18

    Fokke That file is implementing checkServerTrusted but has no body so it would never actually throw the Exception.
  7. Rainer Schleevoigt 2016-02-18

    In my playstore list I cannot see a rule which apps are evil or not. Apps without http client are good. But I have apps with a couple of SDKs and I have apps with http, self signed SSL and with "official" certs. In one app (that connects with a lot of https servers and use property 'validatesSecureCertificate : false,') is marked as 'good'. In warning on playstore I read 'apache'. Is the problem depending on server implementation?
  8. Ashraf Abu 2016-02-19

    What SDK versions are being used in the apps that get the warning?
  9. Ashraf Abu 2016-02-19

    [~titanium@webmasterei-hamburg.de] Is it possible to list which version of the Titanium SDK you are using for that?
  10. Rainer Schleevoigt 2016-02-19

    This I can see: apps without http(s) and apps compiled with SDK5.1.2.GA seems to be OK warnings. Today I will test more apps.
  11. Andrey Tkachenko 2016-02-19

    We can no longer to use self-signed certificates in production?
  12. Rainer Schleevoigt 2016-02-19

    You by using 'validatesSecureCertificate : false,'
  13. Ashraf Abu 2016-02-19

    [~falko] Will get that investigated as well as part of this ticket. Thanks for bringing up this concern.
  14. Ashraf Abu 2016-02-19

    Adding this blog post link http://www.appcelerator.com/blog/2016/02/google-security-alert-unsafe-implementation-of-the-interface-x509trustmanager/ if someone finds this ticket and needs information.
  15. Manuel Conde Vendrell 2016-02-20

    _"I think it makes good sense to have earlier SDKs available with a patch for the X509TrustManager to allow those not yet able to move up the ability to still resubmit apps to the store."_ It is a sentence from Malc Hollingsworth and I agree with him. Big or small may require staying on specific SDK versions for reasons outside of the wish for new features. Sometimes it is module compatibility or too many people working on a project part way through for a jump to newer SDKs. So a patch on all SDKs (or at least from 3.5.0, the most stable and used I think) woulf be a great idea.
  16. Fokke Zandbergen 2016-02-20

    [~mcvendrell] We are looking into patch versions of earlier SDKs as well. Titanium 3.5.1 currently is the [lowest supported version](http://docs.appcelerator.com/platform/latest/#!/guide/Titanium_Compatibility_Matrix-section-29004837_TitaniumCompatibilityMatrix-SupportedSDKReleases) but that ends in April (one year in).
  17. Ingo Muschenetz 2016-02-20

    (duplicate)
  18. Ingo Muschenetz 2016-02-20

    [~fokkezb] 3.5.1 stopped being supported a year ago. That document is out of date. We officially support the last major version for a year after release of the next major version. I would like to reiterate that this is a somewhat unique case in that this prevents you from uploading updates and new apps that flag this warning. I would liken this similarly to when Apple required all apps support 64-bit, and that required a SDK update for all iOS apps, not just Titanium ones. There are many, many reasons why an app should move to a newer SDK. That said, I would like to make this process as painless for as many people as possible.
  19. Shannon Hicks 2016-02-20

    TiSDK 5.0.2.GA was the last version that worked for me. 5.1.x+ introduced bugs that made our apps unusable. I haven't looked at any of the more recent releases, but my confidence is not particularly high that it won't require a ton of effort. Back porting to the 5.0.x branch would be ideal for me.
  20. Ingo Muschenetz 2016-02-20

    [~iotashan] which bugs are those so I can confirm they are fixed now?
  21. Shannon Hicks 2016-02-20

    I don't recall exactly off the top of my head. Seemed like there was something about ListViews, and something about collections. I know, I'm not being helpful. :(
  22. Malcolm Hollingsworth 2016-02-20

    [~ingo] With all due respect this is nothing like the iPhone 64 bit situation. When Apple announced that iOS was going moving to 64 bit it was due to Apple requirement and the betterment of the platform and a healthy lead time. This problem is nothing to do with Google and appears entirely based on an Appcelerator based issue. Guessing the Enterprise customers will jump for joy when they hear no back port update for 3.5.1. To be clear the 3.5.1 issue does not affect me, I am already transitioning the last projects to newer SDKs for entirely unrelated reasons. But I am smart enough to know that there are large projects out there that still require it. For many the move to 4.x was hampered by constant reports of problems with each release so many avoided it. This made the jump to 5.x a bigger one and for some the scale of the change midway through a large project is like asking a fuel tanker to stop and turn. This screams more like a bug fix - unintended as it might be.
  23. david hoare 2016-02-21

    I'd just like to add at least one more voice in support of the request to add the patch to 3.5.1. We have dozens of apps out there that are still running successfully on that version, and have not needed to be upgraded since publishing (though still get regular content updates). There are multiple external modules involved, and forcing them up to version 5.x just to deal with this (I hope) small issue would be a huge commitment we'd like to avoid. Thank you! David
  24. David van de Meer 2016-02-22

    Hi, I would also like to ask for a patch for 3.5.1 - We need to keep using 3.5.1 as we need to keep supporting very old versions of Android as a big chunk of our users (China userbase) are still using older versions of Android.
  25. Dan Tamas 2016-02-22

    +1 for 3.5.1
  26. Aaron Womer 2016-02-22

    Hello, we also have a few dozen apps released which receive regular updates but have been restricted from upgrading past 3.5.1 as well due to mostly Android compatibility issues. While we have slated a transition to 5.x, it would be very helpful to have a patch for 3.5.1 instead of forcing an accelerated transition.
  27. Shannon Hicks 2016-02-22

    @ingo I updated a couple projects to 5.2.0.v20160216202526 and don't seem to have any issues right now.
  28. Anna 2016-02-23

    Is it solved at Ti SDK 5.2.0??? (Today update)
  29. Fokke Zandbergen 2016-02-23

    [~amurcia] thanks for the heads-up. I've added a note to the announcement I just published to say that 5.2.0.GA does not contain a fix for this issue yet: http://www.appcelerator.com/blog/2016/02/ga-release-of-cli-5-2-titanium-5-2-and-studio-4-5/
  30. Hieu Pham 2016-02-23

    master PR: https://github.com/appcelerator/titanium_mobile/pull/7772
  31. David Loekito 2016-02-24

    i think simple fix is to make validatesSecureCertificate : true in your http client, because it false by default. Default: False when running in the simulator or on device in testing mode, and true if built for release in distribution mode. many developers use the apk from test environment and forgot to change environment to production when they were uploading it to google play. hope it helps
  32. Fokke Zandbergen 2016-02-24

    [~David.Loekito] The problem is not the actual use of the class (the property being true or false) but the presence of the class. Our fix is removing that class.
  33. Fokke Zandbergen 2016-02-24

    [~hpham] we should add a deprecation notice to getValidatesSecureCertificate so that we can remove it in 6.0
  34. Matt Poole 2016-02-24

    Not trying to make this more complicated, but figured I'd provide some information from my experience and an email exchange I had with google dev support in case it helps. In parallel with this thread, I had emailed their dev support to understand whether they detect using the class or simply having it. Her answer was a little vague (see below), however she also said to me that my latest app APKs have "fixed the problem" and I can ignore the warnings for past versions. That was interesting to me. We have a few different apps, but they are all branded versions of the same code base. The fundamental difference between the ones that got flagged and the ones that are now "fixed" is that we are now using SDK 5.1.0 while the previous builds were built with SDK 3.5.1. No changes to deploytype and we have never used the validatesSecureCertificate setting. I think above that a few others have noted some similar results with 5.x SDKs. I really don't know why the newer SDK makes a difference based on what I see in the SDK code, but it does appear to. I understand that this doesn't help those that don't want to move to SDK 5 for whatever reason, but it's another data point nonetheless. My exchange with Google: 
        Hi Matt,
    
    Thanks for contacting Google Play Developer Support. 
    
    Our team detects developer's app for unsafe implement products in all classes including production and alpha/beta tracks. Thus like you've mentioned, system will ring when any unsafe elements in your APK detected, especially when it's actually being presented to users at runtime.
    
    However I've checked your APK in our system and found that your latest version has fixed the problem already. If you sill see warning message showing in your "Alerts" tab, you can simply click the "dismiss" button right next to it.
    
    I hope this helps. Please let me know if you have any other questions.
    
    Regards,
    Jennifer
    Google Play Developer Support
    
    
    On 02/19/16 06:03:29 matt wrote:
    We received a security alert about our app today related to an 
    implementation of X509TrustManager that is deemed unsafe. 
    
    We currently use Appcelerator Titanium to build our app and it does have an 
    impl in there that allows non-validated certs, however we confirmed that we 
    are not using this impl for our calls. Appcelerator has it in there for 
    dev use I suppose. 
    
    We are of course working with Appcelerator on this primarily, but my 
    question for you is whether the detection you are doing is just detecting 
    the class in our APK regardless of whether we are using it or not or if you 
    are actually detecting apps that are using the unsafe impl at runtime. It 
    appears to be the former, but figured I'd ask anyway. Basically just want 
    to know whether the existence of it in the APK is enough to ring the alarm 
    bells. 
    
    Thanks in advance. 
    Matt
  35. Travis Crist 2016-02-26

    Is there any chance that Appcelerator can provide a PR to backport this change to the 3.5.1 Branch? If that pull request can be provided with the conflicts resolved then we can take on the effort to build a custom 3.5.1 TiSDK to resolve this in the short term for our customers. Looking to move to 5.x in the future. Thanks!
  36. Fokke Zandbergen 2016-02-27

    [~tcrist], yes it should be no problem to patch and custom build older SDKs that we don't do a patch release for.
  37. Bhavin Bhavsar 2016-02-29

    Just a feedback regarding Apps on Play store. I am having more than 150 apps on play store and i am getting above warning that after May 17th 2016 Google will block such apps. So my question is that only new apps and updates of existing apps on play store will require to be Secure other than that the current working apps need not to be updated before 17th, please correct me if i am wrong. Or is it like we need to update each and every app which is on play store before May 17th 2016. Thanks Bhavin
  38. Fokke Zandbergen 2016-02-29

    [~bhavin2887] Google [says](https://support.google.com/faqs/answer/6346016): {quote}Beginning May 17, 2016, Google Play will block publishing of any *new apps or updates* containing the unsafe implementation of the interface X509TrustManager.{quote} So existing apps should not have a problem until they need an update.
  39. Travis Crist 2016-03-01

    @Fokke Zandbergen {quote} Travis Crist, yes it should be no problem to patch and custom build older SDKs that we don't do a patch release for. {quote} I was wondering if Appcelerator could provide a properly merged PR to the 3.5.1 TiSDK. Right now as implemented the PR has merge conflicts with the 3.5.1 TiSDK. I would really like to have the expertise of an Appcelerator engineer to merge and resolve these conflicts since its in the http client which is a core class to app communication. Is it possible for Appcelerator to provide this PR but not the actual SDK so that those of us who need to add support for 3.5.1 have a clean merge to use for a custom TiSDK build. Thanks!
  40. Ingo Muschenetz 2016-03-01

    [~hpham] can you please provide this backport?
  41. Hieu Pham 2016-03-01

    3.5.X backport: https://github.com/appcelerator/titanium_mobile/pull/7789
  42. Andrey Tkachenko 2016-03-03

    I see we can't more use self signed certificates in production since this PRs.
  43. Rainer Schleevoigt 2016-03-03

    you can switch of this validation.
  44. Andrey Tkachenko 2016-03-03

    I can't turn it off due: https://github.com/appcelerator/titanium_mobile/pull/7789/files#diff-1e01f142e85df58a3e89a93008e5a21eR552
  45. Rainer Schleevoigt 2016-03-03

    Misunderstanding I think. In my last project (Freifunker) the app is connected with a couple of servers, the most of it are unofficial SSL certs . validatesSecureCertificate : false, switches off the validation, it is unsecure (I know), but ist works. The server only sends public information.
  46. Carlos Henrique Zinato 2016-03-03

    Guys, what happens if I submit an app with newest SDK and validatesSecureCertificate : false? Will Google reject it? I saw a lot of deprecated code in the documentation without any direction I should follow =/
  47. Rainer Schleevoigt 2016-03-03

    It will *not* rejected.
  48. Fokke Zandbergen 2016-03-04

    All, we have tested (submitted APKs for) a bunch of scenarios and our current findings are that for: * Titanium SDK 5.2.0.GA and 5.1.2.GA you are good with the defaults (target API level 23), regardless of whether you do development or production deployType and use validatesSecureCertificate to disable validation or not. * Titanium SDK 5.0.2.GA you are good if you [manually](http://docs.appcelerator.com/platform/latest/#!/guide/tiapp.xml_and_timodule.xml_Reference-section-29004921_tiapp.xmlandtimodule.xmlReference-SetatargetorminimumSDKlevel) target API level 22. * Titanium SDK 4.1.1.GA, 4.0.0.GA and 3.5.1.GA requires the patch in the [pending PR](https://github.com/appcelerator/titanium_mobile/pull/7789), which also means you can not use validatesSecureCertificate:false anymore. Please help us confirm these findings by uploading (no need to publish) an APK using the above configurations and wait for at least 5 hours. Keep a copy of the build log and if you *do* get a security alert, please send the build log to us. Will wait this out for a few days and then confirm our findings in a follow up blog post. Again we want to emphasis that unless you use validatesSecureCertificate:false there is no actual security issue. It's just that Google decided to warn for an unsafe class even if its not actually used. *Updated March 7:* New info on <= 4.1
  49. Dan Tamas 2016-03-04

    what about 5.0.2 ?
  50. Fokke Zandbergen 2016-03-05

    [~rborn] seems to be good with target API level 22. Could you try and confirm? We'll do some additional tests in the coming days.
  51. Dan Tamas 2016-03-05

    Thanks, I'll try
  52. roeland p 2016-03-07

    Would love to try the [Pending PR 7789](https://github.com/appcelerator/titanium_mobile/pull/7789) by Hieu in my 3.5.2XXX android SDK. I remember that with IOS code modifications I was able to navigate and update the source inside the '~/Library/Application Support/Titanium/mobilesdk/XXX_VERSION/iphone' folders. (?) I'm curious how I could do this with [Hieu's 3.5.X Pending PR7789](https://github.com/appcelerator/titanium_mobile/pull/7789) ? Or should I clone & build a custom build? Happy to test it out and publish to Google Beta Store and publish my findings. kind regards, Roeland
  53. Fokke Zandbergen 2016-03-07

    [~rpl] For Android you indeed need to do a [Custom Build](http://docs.appcelerator.com/platform/latest/#!/guide/Building_the_Titanium_SDK_From_Source) or wait for the PR to be merged and included in the next [Nightly Build](http://builds.appcelerator.com/).
  54. Brian Blankenship 2016-03-07

    @fzandbergen, can we assume your findings mean 4.1.1 and below, or is there any separate guidance for 4.1.0.GA? Thanks.
  55. Fokke Zandbergen 2016-03-07

    [~blankenshipb] I've only tested the latest of each minor. Any specific reason you need 4.1.0 instead of 4.1.1?
  56. Brian Blankenship 2016-03-07

    @fzandbergen, yes, a customer. On a side note, another customer is on 5.0.2.GA, did not set the Android API level to 22 (it was set at 21), yet did not receive the warning.
  57. Fokke Zandbergen 2016-03-07

    That's great news on the API level [~blankenshipb], thanks.
  58. Brian Blankenship 2016-03-08

    @fzandbergen, I just saw the blog post, and as mentioned yesterday, and per your request in the blog, we do see the issue in 4.1.0.GA. Please advise.
  59. Fokke Zandbergen 2016-03-08

    All, we have a new blog post with an update on this issue: http://www.appcelerator.com/blog/2016/03/update-on-recent-google-security-alerts/
  60. Fokke Zandbergen 2016-03-08

    [~blankenshipb] That you see the issue in 4.1.0.GA is in line with [our findings](http://www.appcelerator.com/blog/2016/03/update-on-recent-google-security-alerts/#we). Please upgrade to 5.x or use a CI or custom build of an older SDK with the patch linked from the blog post.
  61. Ashraf Abu 2016-03-21

    Fixes have been done to branches 3_5_X, 4_0_X and 4_1_X. Along with fixes TIMOB-20534 that was required. Resolving this issue.
  62. Eric Merriman 2018-08-06

    Cleaning up older fixed tickets from 2016 and earlier. If this ticket should not have been closed, please reopen it.

JSON Source