I observed that some of the secure certificates are failed to installed in android device. The message shows the certificate get installed successfully. But it does not get listed in "Trusted Credentials" list. But I could not identify the reason for it.
Can some one give me help me to identify the reason behind this failure.
I spent a lot of time trying to find an answer to this (I need Android to see StartSSL certificates). Conclusion: Android 2.1 and 2.2 allow you to import certificates, but only for use with WiFi and VPN. There is no user interface for updating the list of trusted root certificates, but there is discussion about adding that feature. It’s unclear whether there is a reliable workaround for manually updating and replacing the cacerts.bks file.
Details and links: http://www.mcbsys.com/techblog/2010/12/android-certificates/. In that post, see the link to Android bug 11231--you might want to add your vote and query to that bug.
Related
I would like to get the list of all revoked certificates list downloaded on an Android device? I know that this class allows you to check if a certificate is revoked or not, but I want to get the whole list of revoked certificates. Is it possible? Does Android store such a list or it uses OCSP to check the certificates?
It would appear that Android does not store a certificate revocation list (or at least if it does then it doesn't use it). There's a reddit thread from a few years ago that brings this up and discusses the pros/cons of it, but the essence of it is that if you go to https://revoked.grc.com/ (which should throw an error if your browser checks for revoked certificates) on mobile Chrome, you'll be notified that your browser doesn't check for revoked certificates.
From the page above (revoked.grc.com, which you shouldn't be able to see unless you're using a browser without a CRL):
The mobile Android platform currently offers no certificate revocation checking of its own, so Android apps (including all users of Google's Chrome browser) are vulnerable to malicious certificate abuse. The only way to use Android securely today is with Firefox, which brings along its own certificate security.
A couple more sources I found (again a few years old, but they still seem to be relevant and accurately describe the current situation):
An issue on the OkHttp (an Android http client) github discussing whether to add certificate revocation checks, where they decide not to
The CommonsBlog, discussing the lack of certificate revocation checks on Android
A Chromium issue about the lack of a CRL, where one of the developers states that it won't be added and presents the justification:
Marking this WontFix for two reasons:
1) Revocation checking is the responsibility of Android and the related SSL APIs. Android itself does not and has never performed revocation checking [...]
2) Revocation checking generally doesn't work (as a security feature), and especially for mobile, greatly affects performance (negatively) and privacy (negatively)
I developed an app using the platform codename one, after submit the app in Play Store I received the following warning email:
*"We detected that your app(s) listed at the end of this email are using an unsafe implementation of the WebViewClient.onReceivedSslErrorHandler. You can also see the list of affected apps, as well as details such as version numbers and class names, on the Alerts page in your Developer Console.
Your current implementation ignores all SSL certificate validation errors, making your app vulnerable to man-in-the-middle attacks. An attacker could change the affected WebView's content, read transmitted data (such as login credentials), and execute code inside the app using JavaScript.
What’s happening
Beginning November 25, 2016, Google Play will block publishing of any new apps or updates that contain this vulnerability. Your published APK version will remain unaffected, however any updates to the app will be rejected unless you address this vulnerability.
Action required
To properly handle SSL certificate validation, change your code to invoke SslErrorHandler.proceed() whenever the certificate presented by the server meets your expectations, and invoke SslErrorHandler.cancel() otherwise.
If you are using a 3rd party library that’s responsible for this, please notify the 3rd party and work with them to address the issue.
After making changes, sign in to your Developer Console and submit the updated version of your app.
Check back after five hours - we’ll show a warning message if the app hasn’t been updated correctly."*
I was researching but unfortunately I didn't find anything about that. I think that maybe is an internal issue of the platform but not sure. What do you think?
Thanks in advance.
Not properly validating the certificate of a SSL connection is a serious issue because this way you effectively weaken the protection offered by SSL a lot and allow easy man in the middle attacks. This way an attacker might sniff the transferred data and even modify the data.
Thus the issue should be fixed.
But with the currently shown information it is impossible to say if the error is in your (unknown) code or some (unknown) third party library or in the wrong usage of a third partly library. But a common cause for such errors is that one is trying to use a self-signed certificate and switches off validation for this purpose. Another common cause is the intention to switch off validation for development only but then inadvertently fail to enable it again for production.
You can look thru the sources of the Codename One port and see that there is no usage of that method:
https://github.com/codenameone/CodenameOne/blob/master/Ports/Android/src/com/codename1/impl/android/AndroidImplementation.java#L3768
So there is no such violation within Codename One as far as I can tell. There are thus two options I can think of:
Google is wrong - wouldn't be the first time with those guys... +
I submitted a Codename One Android app just the other day and didn't get such an error
You added a 3rd party cn1lib/extension/native code to your project which you can verify by looking under android/native or within the lib directory to see if you have anything in the former or a .cn1lib file in the latter.
The developer console for android has functionality for reporting runtime crashes if users decide to report a crash. Other frameworks has similar features that sends crash-reports without involving the user.
Does anyone know of a way to report installations or upgrades that has failed? With android 5.0 I am getting more and more user-reports of failed installs, but it is hard to obtain logs from non-technical users of my app.
You cannot detect whether or not an installation has failed yourself, because there is no way to execute code before your app is actually installed. So the logical app to do such a thing would be the market app triggering the install (i.e. Google Play). This not only knows when each installation starts, but also knows all details about the apk to report to the right developer.
Unfortunately however, Google play does not support this currently (as far as I know) and hence you cannot detect failed installs.
On older Android phones you could ask users is to install a "logcat app" and email the logs to you for analysis, but this will only work for devices older than Jelly bean. (Read this Link)
The best solution I can come up with (Mac only) is to ask users to install AndroidTool, press one button to generate a bugreport and email that to you. Not great, but for now the best you can do.
You can build an api that reports successful installation. Just call the api in onCreate of first activity. I don't think there is need to collect log on why the installation failed, is it needed ? You can do the same for upgrade, call an api one time from upgraded code.
Can anyone give me a hint if it is possible to ask Android to include (or 'trust') additional Root CA in their OS ( which will be updated during next update and pre installed on the new instances)?
At this moment each website which use SSL certificate for https which is signed by our Certificate Authority is asking for trusting this website by showing
untrusted connection warning
Of course installing certificate manually solve the problem, but this is not the case considering number of operation which user has to make in order to use the website without concerns that he is being attacked by some kind of men in the middle attack.
For the record we have pass audits made by the independent organizations.
Root Certificate Policy - The Chromium Projects says:
If you are a root CA, the following contacts should be used:
...
Android: Please file a bug at
http://code.google.com/p/android/issues/entry . Note that, similar to
Linux, the certificates included within the Android sources may be
further altered by device manufacturers or carriers, pursuant to their
local programs.
We run a web application with a Java Script- and an Android front end. We use Google IDs with OAuth for authentication. Everything worked find until today authenticaiton suddenly stopped working. There was no new software version deployed or any operational changes. Now, when a user tries to log on via the browser application, Google issues
401. That’s an error.
Error: disabled_client
The OAuth client was disabled.
Request Details
scope=openid profile email
response_type=code
redirect_uri=https://***.net/signin-google
state=***
client_id=******.apps.googleusercontent.com
That’s all we know.
When logging in via Android App, authentication fails too, GoogleAuthUtil.getToken raises an unspecific exception.
I couldn't find much information when googling for this error message. Some say, one should try to change the application name in the consent screen. This didn't help in my case.
In developer console I noticed, that I cannot create a new Client ID for this project. I always get a technical error ("Server Error Whoops! Our Bad.") with a tracking number. Seems to be related.
I have a total of 7 Client IDs registered for this project and 3 public API access keys.
Is it possible, that Google explicitly disabled our project? That's how it actually feels. For what reason? I didn't get any notification. Our product is an application for access control, nothing special or illegal here.
Any ideas? This is a production environment, so for us the problem is absolutely severe.
Thanks for any help!
In the meantime we found out, that our Android App was removed from the Play Store and we got following notification:
This is a notification that your application, <...>, with package ID <...>, has been removed from the Google Play Store.
REASON FOR REMOVAL: Violation of the Personal and Confidential Information provision of the Content Policy.Please refer to the policy help article for more information.
We don't allow unauthorized publishing or disclosure of people's private and confidential information, such as credit card numbers, government identification numbers, driver's and other license numbers, non-public contacts, or any other information that is not publicly accessible.
We are very careful about the data inside our application and we take privacy and security extremely seriously as the hole app is about security and our customer's trust is absolutely essential. However, we recently introduced a feature that periodically sends the LogCat output to our servers for debugging reasons. Our app is in an early preview state which we make clear in the app description. It's used by a very limited number of people as it can only be used with a special piece of hardware we provide. The LogCat output only contains data from the app itself, no confident data of any kind. We published a couple of related apps and not all have the feature even included but all were suspended. However, we guess that this feature is the reason for removing.
Edit
In the meantime we wrote an appeal via the form provided on Google Play. The ban was removed from Google Play and the related Google OAuth Client shortly after.
We were informed, that our App collects names of running tasks and sends them to our servers, which is not the case. However, we used the crittercism library and the crittercism docs suggest to require the "GET_TASKS" permission, what we did. I don't think, that Crittercism is considered as dangerous as it's used by lots of applications. But maybe the combination of a Logging Service on the one hand and the GET_TASKS permission on the other hand, although not dangerous in our case, triggered some automatic rules at Google.
To fix this we simply removed Crittercism and all related permission requirements as it wasn't very useful for us anyways.