I understand that self signed ssl is risky incase of dns spoofing since the attacker may generate a self signed ssl himself and place it in his ip address and it will trigger a warning in the client browser.But what makes the EV SSL different from self signed ssl in case of dns spoofing?I am going to make traffic to that self signed ssl site only from my android client app, do i have make those checks myself (those checks which browser does upon getting ssl certificate)?
Generally speaking there are three types of certificates:
Self signed certificates:
These are certificates that are often generated by an internal certificate authority (CA) where the root certificate is injected in all clients. This way when visiting an internal web application over TLS, no certificate warnings are displayed to the end user.
These are certificates that are signed by public or internet facing certificate authorities (CA). The root certificates of these CA's come with the web browser.
EV signed certificates:
An EV certificate is the same as described in the section signed certificates however, by obtaining such certificate the issuer is required to retrieve a lot more information regarding the company requesting this certificate.
Extra checks are in place before the EV certificate is handed out.
Does EV SSL certificate makes any difference while used instead of self signed SSL in case of API for android app?
Yes, it does make a difference and self signed certificates should not be used in production environments.
The difference is that with a self signed certificate, users are presented with a warning. In case of a man in the middle attack, the certificate is not valid and a user will also be presented with a warning.
Users that are taught to always accept these warnings are prone to man in the middle attacks.
When using a valid certificate, users are not displayed with certificate warnings. When a man in the middle attack takes place, the users will see a warning which should indicate something is wrong.
Nowadays there is no valid reason to use self signed certificates. Free certificates can be obtained quite easily. The use of an EV certificate would be overkill in my opinion.
If you are particularly paranoid about someone spoofing dns and a certificate (self-signed, EV or otherwise), then you can statically trust the self-signed certificate by e.g. checking the fingerprint or subjectKeyId (SKI). When you initiate the connection, check the presented certificate against the known-good fingerprint/hash before proceeding.
This does have the downside that revoking a certificate requires an update to your app, something PKI is designed to avoid to a large extent.
Note that the EV attribute is not a technical difference, but a policy one. It is a promise from the CA that they've verified the identity of the company they issued the certificate to instead of just the domain name. You can only trust an EV certificate more than a regular certificate of you trust the CA who is making that statement. YMMV
For the purposes of securing an API for an Android app a self-signed certificate is fine. If you pin multiple certificates (or even your own CA), and use only one, you can even revoke them without an update to your app.
This is one of very few cases where self-signed, DV or EV makes no difference. Do make sure that you use at least DV on all websites associated with your app, and the API's associated with those websites, as otherwise users would be presented with a warning.