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.
Related
Let's say that I have an app that transmits some sensitive info to my server. I want to reduce the risk of a man-in-the-middle attack on my users, so I pin the keys used by my server in the Network Security Configuration file.
But, let's say a user of my app does not trust the CA that issued our certificate, and has removed it from the list of trusted CAs, or maybe an OS update removes the CA because it has been found to be behaving badly.
Ideally, in such a case I would like my app to refuse to connect to the server. I only want it to make the connection if the certificate presented by the server is signed with a key in the pinset AND comes from a CA that is trusted by the OS/user. Does pinning a key in the network security config file accomplish this? Or, are pinned keys trusted no matter what?
The HPKP instructs the browser to store the signature for your server certificate for the period of time you specify. Using HPKP does not replace the standard certificate validation.
In your scenario the pinned PK in the browser will be valid for the server certificate your server is presenting, but the actual certificate validation will fail since the CA is not trusted.
I need a secured connection between the client(Android application) and server. I referred official document developer.android.com/training/articles/security-ssl.html. And also found here globalsign.com/en/ssl-information-center/… that there are three types of ssl certificate:
Extended Validation (EV SSL) Certificates
Organization Validated (OV
SSL) Certificates
Domain Validated (DV SSL) Certificates
Which of the above supported in android app?(not in the browser.I am using retrofit to call web services), And Which one should I use?
As stated by Steffen Ullrich, any of the listed SSL certificates will work for your purposes. The primary difference between those options that you have listed is the extent to which the certificate authority will go to in order to verify your identity.
The scrutiny given to any certificate request can range from very little (no verification beyond domain name ownership) to the requester needing to provide the CA with proof of a physical location.
For your purposes, encrypting traffic from an android application to an API, any of the listed cert types would work and I would go with the cheapest option.
I would recommend: https://letsencrypt.org/docs/ to get what you need.
Additionally, just to add some more context to your question and your specific Android tag. It actually has little to do with Android and more to do with the server you'll be communicating to. Getting an SSL cert installed on your server means that you'll be able to encrypt traffic from any source to that server and the only thing you'll need to do from an android perspective is to ensure you hit port 443 (https://)
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).
Our Android application is interfacing with a server than employs a certificate chain, with certificates issued by Verisign. We were able to establish SSL sessions with this endpoint so far. This Verisign certificate is due to expire next month.
Questions:
1. Should Server site get a new certificate reissued from Verisign and everything would just work?
2. Can the original certificate expiration date be just extended rather than issue a new one?
What can be done to ensure a smooth transition?
You need to be issued a new certificate, but it needn't be issued by Verisign. Any trusted authority can sign the certificate.
The key store containing trusted issuers is here:
/system/etc/security/cacerts.bks
You cannot extend a certificate, but you shouldn't need to. As long as the server certificate is issued by a CA you trust (does not to be VeriSign), things should continue to work. You might want to replace the cert sooner rather than later though, because people might have clocks that are off by a few days.
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.