I have a website with a number of RESTful web services that are used by an Android app. I want to let all requests go through HTTPS. Hence, I need an SSL certificate for my website.
Q: Do I need to buy an SSL certificate or can I use a self-signed certificate in this case? (I don't want to waste money on something I don't need.)
I can think of these approaches:
Buy an SSL certificate with Extended Validation (green address
bar). Probably not necessary.
Buy an SSL certificate without Extended Validation. This should suffice, no?
Self-sign an SSL certificate. Not sure what this implies?
If your biggest concern is not spending money http://www.startssl.com/ provides free basic SSL certificates for a year so that may be worth looking into. I do not know off-hand which CAs are trusted by default in Android so it may turn out to be effectively the same as a self-signed certificate from the app's perspective.
Using a self-signed certificate would require finding a way to make sure the Android app expected that self-signed certificate and trusted not only your initial certificate but any replacement certificates in the future. I suspect this is more trouble than it is worth although I do not know much about Android development or the app in question so I may be overestimating the difficulty involved.
An EV certificate does provide a stronger guarantee to the client that the service is actually your service and owned by you but it does incur additional costs. Choosing an EV versus DV certificate becomes more of a risk/reward judgement call. Annecdotally, I typically only see EV certificates on financial sites and others where you would typically expect to find a high bar for security.
Related
we have developed Ionic app, in that SSL pinning using advancedHttpPlugin but still, the security team was able to use a third party tool Burp Suite to install a CA in the mobile and track the application, they provided below message for fixing the issue.
Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption. This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Certificate pinning is the process of associating the backend server with a particular X.509 certificate or public key instead of accepting any certificate signed by a trusted certificate authority. After storing ("pinning") the server certificate or public key, the mobile app will subsequently connect to the known server only. Withdrawing trust from external certificate authorities reduces the attack surface (after all, there are many cases of certificate authorities that have been compromised or tricked into issuing certificates to impostors). a) In order to make your communication safer, explicitly compare the SSL certificate used for the connection with an expected client-side certificate.
On Ionic, is there any other method we need to include to also restrict Burp CA?
Please help me to fix this, Thanks In advance.
I am trying to learn about making secure mobile applications. I am curious to know, do we need Certificate pinning if our network calls from mobile to server use https ?
Yes, you should save it as a raw file in the folder of your app and use it to call the server for the requests.
Pay attention, if you have a self signed certificate you should force it as made by trusted authority.
I am curious to know, do we need Certificate pinning if our network calls from mobile to server use https ?
https guarantees that the data in transit between your mobile app and API server is encrypted and cannot be spied on by third parties, thus partially preventing it against Man in the Middle attacks.
So I say partially because an attacker can induce users to install a custom ssl certificate in order for them to use a free wifi. This is usually done with fake wifi captive portals where you have to sign in in order to have free wifi, like the ones you found in airports, trains, etc. If an attacker succeeds in tricking the user then all the traffic is routed through the attackers computer and despite being https it can be decrypted once the mobile app is using the attackers custom certificate, but the attacker will always use the original certificate when communicating with the API server, thus neither the API, server, mobile app or the user are aware that the communication is being intercepted and maybe even tampered with.
So using certificate pinning will prevent any type of a Man in Middle Attack to occur, even the ones where the user of the mobile app is the attacker that intentionally decrypts is own traffic in order to reverse engineer the mobile app communication with the API server in order to gain enough knowledge to mount an attack against it.
Now is time for the bad news... Certificate pinning can be bypassed when the attacker as access or controls the mobile device. This article walks you through on how certificate pinning can be used and bypassed by using a framework like xPosed, that will intercept the calls to validate the certificate, thus bypassing the validation process.
So should I use certificate pinning? Yes you should, because is one more layer of defence and requires more effort for an attacker to reverse engineer your mobile app, that he may deem not be worthy the effort, but if he deems worthy the effort then you may want to search in google for a Mobile App Attestation solution to protect further the communication between the mobile app and the API server.
But keep in mind that while certificate pinning may be easy to implement in your mobile app it may be an operational nightmare to maintain. Be sure to read the section PINNING IS A NIGHTMARE in the link I referenced previously about bypassing certificate pinning.
Edit
You can read the article Steal that API Key with a Man in the Middle Attack to see a practical example on how a secret can be extracted from a https request sent from a mobile app to the backend API, by performing a MitM attack.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
Afterwards you can also take a look to the article Securing HTTPS with Certificate Pinning on Android to understand how you can implement certificate pinning to prevent a MitM attack.
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
I hope that both articles have made more clear why certificate pinning is recommended to be used to secure https connections from prying eyes.
EDIT 2
If you want to implement certificate pinning but are afraid of making any mistake while creating the network_security_config.xml configuration file then just use this free Mobile Certificate Pinning Generator to create it for you:
and it will give you a network_security_config.xml configuration file ready to be copy pasted:
In a recent discussion with colleague we analysed the implications of letting the default Android's system validation of CA signed TLS certificates from a known CAs like Verising, Comodo, etc. The discussion centered on the issue that the OS might be compromised (maybe rooted with malware or hacked) and the entire CA certificates library modified to validate certificates not signed by actual CAs.
A possible proposed solution to this was implementing Certificate validation in the app itself, having a list (which would in theory be much narrower considering that the app developer knows which certificates he'll be using) of Root CA Certificates in the app and let the app do the verification. This would allow for real validation without depending on the systems CA certificates.
I'm still a bit worried of wrongfully implementing this, how smart is it to let de app do the validation?
If the system is compromised an application running with same or less privileges than the compromised system can not save the day. Essentially you would not only need to implement TLS validation by your own but also the full TLS stack because the encryption libraries might be changed on the system and provide a backdoor to the attacker to get to the plain text. Additionally you would need to make sure that your application is not hijacked and the plain text information are stolen outside the encryption process, i.e. before encryption and after decryption. But, if the attacker has fully compromised the system you cannot stop this.
It is probably way more likely that you introduce new bugs while implementing the fairly complex TLS stack by your own and thus make your application not only insecure on compromised systems but also on others.
Developing a simple android application that will cast a URL (webpage) on bigger display.
For publishing "the receiver app must be served over SSL (HTTPS)". For that I have generated self-signed SSL Certificate and plan to use the same.
URL for publish
However, On trying to access the page from browser, it gives following warning:
The site's security certificate is not trusted! You attempted to reach
basilapps.com, but the server presented a certificate issued by an
entity that is not trusted by your computer's operating system. This
may mean that the server has generated its own security credentials,
which Chrome cannot rely on for identity information, or an attacker
may be trying to intercept your communications.
So my query is:
(A) Will self-signed certificate will work fine during publishing?
(B) If not, then do I need to purchase SSL certificate from trusted authority?
(C) Are there freely available trusted certificates services available?
Thanks
Self-signed certs do not work and yes, you need to get/use a trusted one form a known authority. If you can use App Engine, that works since it already has that. For development, either use http or use App Engine or even Google Drive (the last two support https).
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.