I went through this link.
I have some couple of questions:
1. What is keystore? And what and why I need to implement?
2. What is TrustManagerFactory and what is 'X509' in this context? Please answer is there is something else other than 'X509'.
3. What details should I know or consult for from my webserver application team? Do I need to know about the any kind of certificates or something else?
My problem scenario: What I am trying to do is to retrieve some XML string over network and it have to secured because it is little bit sensitive.
I am waiting for your answers.
You may not need to study HTTPS in detail to secure your XML. To use HTTPS, you mostly just need to get an official SSL certificate for your domain, and use it in your server. Then the HTTP client, either in the browser, WebView or Java HTTPClient, will know what to do with it.
Read the Java SSL implementation, JSSE documentation for some basics and perspective.
A keystore stores keys or certificates. If the CA that issued the certificate of you server is trusted by Android (i.e., it is already installed in the system trust store), you don't need to mess around with keystores. It should just work. If it is not, you may need to create your own trust store that includes the certificate of your server if it is self-signed or that of the issuing CA if it is not.
TrustManagerFactory produces a TrustManager. It tells your app/system what certificates to trust. Technically there can be other implementations besides X.509, but in practice this is the only one in use.
See 1. Ask them who issued the certificate. Or simply access the site with your browser. If you get a warning or an error, things might get slightly complicated because most likely Android won't trust the server certificate by default either. IF not, your app should just work with an https://myserver/sevice type URL instead of an http:// one.
Related
I am developing an android application which interacts with my server. For including the SSL layer, I created a self-signed certificate for my server. So, at present when i access my server through a browser, it sends that certificate and once I save it, all works fine on browser.
But I am not sure, how can I move ahead so that my Android app will communicate effectively with the server. The thing I know so far is that I need to generate a keystore (.bks) for my android application and pass it on to TrustManager. I found various tutorials to generate the keystore but I am getting confused at few points:
Will I need any info regarding the server's certificate for generating this keystore?
Is there any way through which I can replicate the browser like functionality in the application? (If the certificate is not from a trusted CA, add it to the list if the user confirms that.)
How will the server trust my keystore?
I might be mixing some of the concepts because I read a lot of articles regarding all this. The articles/questions that I have already referred are:
Bob Lee's blog
Blog on CodeProject
Using OkHTTP
StackOverflow answer
Extract cert from server and add to keystore
i need to implement security measure for my android app which currently runs with http
I was reading on the ssl and found that we need root and intermediate certificates,
if i am not purchasing the certificate from outside how can i get the root and intermediate certificates ..
thanks
Do you mean you will be using a self signed or self issued certificate on the public facing server? (Neither of which I would recommend)
If you really want to try and do that then:
a self signed certificate sign's itself (it is its own CA)
a self issued certificate on windows for example use the mmc certificates tool, you can download the public part of any certificates in the trust chain (but then you'd need to get them on to a device for them to be useful and something owners of the devices would not like since I would bet you do not have proper key management in place).
A potentially better way would be to use a properly issued certificate for your production site which would allow you to validate the hostname and trust chain correctly.
But for your local dev builds have it ignore these two checks (I would also have it put up a Toast if it was running in this mode so you don't issue this by mistake).
I'm using HTTPS in my Android app to communicate with my own API.
When I packet sniff, I don't see any information which is good.
However, when I use software like Fiddler2 to install a trusted certificate on my Android, I can see all my HTTPS calls in the clear which is dangerous.
The problem is so close to this guy but in Android not iPhone:
hiding iOS HTTPS calls from fiddler
I am using loopj library to make my https calls: Android Asynchronous Http Client
http://loopj.com/android-async-http/
How can I deal with such a vulnerability ?? ( I know how to deal with it conceptually but I need example code )
When the user chooses to install Fiddler2's certificate as a trusted root certificate, he is then choosing to compromise his own security. I'm not sure there's much you can do about it, since your application's HTTPS connexion will go through Android's certificate validation system, which will consider the connexion as valid, since the certificated is trusted.
The solution I would go for is embedding your SSL certificate in your application, and tell your application it is the only trusted certificate. It's secure and free, as you can attach a self-signed certificate you created yourself, since you control the verification mechanism. See this blog article for code example.
We have a web service that should only be called by a specific Android app. What solutions are there for this problem?
The requirement is to not use authentication at all.
If it's only your client and your server, you can (and should) use SSL without purchasing anything. You control the server and the client, so each should only trust one certificate, the one belonging to the other and you don't need CAs for this purpose.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
You'll normally store that certificate/private-key in a keystore of sometype (a KeyStore if you're using Android) and that keystore will be encrypted. That encryption is based on a password, so you'll either need to (1) store that password in your client somewhere, or (2) ask the user for the password when they start your client app. What you need to do depends on your usecase. If (2) is acceptable, then you've protected your credential against reverse engineering since it will be encrypted and the password will not be stored anywhere (but the user will need to type it in everytime). If you do (1), then someone will be able to reverse engineer your client, get the password, get the keystore, decrypt the private key and certificate, and create another client that will be able to connect to the server.
There is nothing you can do to prevent this; you can make reverse engineering your code harder (by obfuscation, etc) but you cannot make it impossible. You need to determine what the risk you are trying to mitigate with these approaches is and how much work is worth doing to mitigate it.
I guess this will work with proper authentification in place. First post I just stumpled upon was this one:
Securing communication from android to a web service
Hope it helps =)
If you're absolutely certain this web service will only need to be accessed by authorized applications/devices, go with client-side SSL certificates and restrict access at the server to only clients with authorized certs. This has the bonus feature of forcing SSL at all times so you don't like auth secrets over an open channel. Here's a quick guide for Apache, but you could use nginx too:
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
I want to perform extra validation for SSL connections I make in an android app.
Basically I need to be able to:
See if the certificate of the remote host I am connected to has Extended Validation (EV) status
Find out the root certificate authority for the certificate of the remote end. E.g. I want to know if it is a VeriSign certificate or not.
To elaborate a bit more, I am writing a client that needs a high level of security and our organization is using EV certificates from VeriSign on all servers. I want to prevent any compromised certificate authority, or anyone that can fool a certificate authority to forge a certificate for our domain be able to hijack the application.
Is this doable and if so, how? Is there a way to get more information about the certificate of the remote end from a URLConnection object or a HTTPClient object and so on?
First: you can't possibly 'prevent any compromised certificate authority' from issuing a certificate for your domain. If it is compromised, they can issue whatever they want. What you can do is create a trust store with a limited number of trusted CA certificates, say, VeriSign only. That way, even if an related CA is compromised and issues a cert for your domain, it wouldn't matter since you don't trust it in the first place. That would also take care of second bullet. To have additional checks you need to implement and install your own X509TrustManager. Check the JSSE reference guide for details.