My company's product is Android and iOS mobile app which connects to our own backend. All interactions of the mobile app are with backend developed by our own company.
In such a situation, can the backend use a self signed certificate (instead of getting a certificate from CA) and pin this self-signed certificate on mobile app to make it more secure.
Please let me know if this strategy makes sense (or we still have to get SSL cert from a CA)
This is an old issue, but I think it bears following up on. SSL certs are dirt cheap if purchased from the right companies and not from the "big 3". Comodo has wildcard certs (any subdomain) for USD 60-70/year. They are secure (256 SHA) and install right off. Well worth the money, IMHO.
Related
I am developing a mobile app with certificate pinning. I will have a box in the DMZ that will proxy my requests. Should this server have a cert from a trusted CA or can I use the one I generated from my own CA?
What would be the benefits of using a trusted CA from a mobile client?
Also, I will hit several different servers afterward that will be using my own CA generated cert. Should I pin those as well? I am assuming yes, that pinning both will be best even within the network. But is the necessary?
Thanks!
If you use your own CA you gave to manage the revocation process yourself, which is hard.
If you use a custom CA, it means you will have to either:
Provision all the mobile devices that will use your App with your custom CA. If you don't control the mobile devices, this will be impossible to do and pushing a CA to a device's trust store is a liability anyway.
Disable the system's default certificate validation so that the custom CA is accepted by your App, and then re-validate the server's chain and do pinning. It is close to impossible to get this right so you will most likely end up with an insecure HTTPS connection.
Do buy a certificate from a trusted CA.
For the connections between the proxy and the internal servers, you could implement SSL pinning but it is less of a priority as the attack surface is reduced, compared to the mobile clients.
I'm building my first web app and I have two questions about security.
I'll send and receive very sensitive data with POST request to my
api which will be hosted on Azure or AWS. Can I send and receive
data in plaintext over SSL, is it secure? I can access my
azure web site over https, is it secure enough or should I buy another
SSL sertificate?
I've searched a little bit and there are different types of SSL
certificates, I read some certificates provide green padlock or green address bar but I don't need these kinds of things since my web app only
will be available to my mobile app and there will be no content to browse. Only one page with download links to my mobile app in case someone finds this site. So all certificates are secure on same level for my situation?
P.S. I won't add custom domain name, if that's relevant.
Answering your questions one at a time;
Modern implementations of SSL are generally considered to be pretty
rock-solid; its used by banks, healthcare institutions, and major
internet companies. Sending data in plaintext, over SSL, is
safe enough for those applications, and trying to replace SSL with
your own encryption scheme is almost certainly more trouble than its worth.
You should probably get your own SSL certificate; I don't know what restrictions Azure has on https access, if any, and its always bad practice to rely on a key you cannot control.
SSL relies on networks of trust; browsers (and other internet applications) validate the certificates sites send them against a
set of trusted authorities. If the certificate has been approved
(signed with the authority's private key), the browser accepts the
certificate as genuine and uses it to negotiate an SSL connection
with the site without further complaint. This is what that green
padlock/address bar means; that a site has provided a valid
certificate signed by an authority the browser trusts. This doesn't
mean that a signed certificate is inherently more secure than an
unsigned certificate, however. Both use the same cryptographic
algorithms, and (can) have the same length keys, and the SSL
connections each can set up are equally secure. The difference
between the two is that you can't verify the "authenticity" of an
unsigned/self-signed certificate; an attacker could intercept the
connection and replace an unsigned certificate with their own
certificate, and the browser would have no way of telling if it got
the right certificate or not. You can overcome this problem in your
application, however, with a technique called "certificate
pinning".
Essentially, you package the public key for your certificate with
your application, and your application only accepts the certificate
associated with that key when setting up a connection.
Ultimately, it depends on your attacker model. Are you protecting this data from criminals and casual wiretappers? Or are you trying to hide it from government surveillance and intelligence agencies? For the former, an SSL certificate signed and issued by a reputable authority is more than sufficient. For the latter, you have to consider where your certificate is coming from, and who can access the root CA that issued it; it might be better to generate your own, and devise some further scheme on top of SSL.
I recently used node.js to create a HTTPS server. The certificate was created free from this website.
http://www.selfsignedcertificate.com/
The chrome browser always prompts with a message that the HTTPS website is not secure when using this self-signed certificate. I did some research on the net and it seems that proper certificates cost money. Is it possible to generate a certificate free of charge and accepted by browsers as secure?
No
Certificates are generally only trusted when they are signed by a highly-trusted Certificate Authority. This is what makes SSL Certificates work. If everyone could sign their own certificates, anyone could claim to be any server they wanted.
To get a (trusted) Certification Authority to sign your certificate, you will generally need to pay.
Good news for you. Go to this website https://letsencrypt.org/. It is in limited mode and offer free certificate.
https://letsencrypt.org/about/
Let’s Encrypt is a free, automated, and open certificate authority
(CA), run for the public’s benefit. Let’s Encrypt is a service
provided by the Internet Security Research Group (ISRG).
We have a backend server that services a multi-platform app that will be launched on iOS, Windows 8, Windows Phone 8 and Android. We'd like to use in production as few certificates as possible (preferably just one) to attain the following purposes:
secure communication (HTTPS) with the client application
authentication to the Windows Phone Push Notifications Service
authentication to the Apple Push Notifications Service
Besides taking care that the certificate is issued by a common trusted root authority, are there any other impediments that could prevent a single certificate from being used simultaneously for all these? Is it a viable possibility or is it instead necessary to resort to one certificate for each of the above purposes?
Gabriel I guess there is a problem. Main one is that HTTPS certificate private key cannot be coded by a secret this kind of certificate contain *.crt and *.key file which are not secured. When You want authenticate yourself or server in some Service for example Windows phone push like you have listed there is need to create hash for your private key with secret aka pin or password. What make You use at least two different certificates.
Second thing is that purpose of using certificates is to validate the issuer and to authenticate user/service provider. HTTPS ssl certificate issued by a trusted CA show to the user Hey this is trusted website You should not be afraid passing sensitive data through the service, and the certificates which are used to authenticate are just saying Hey its me I am authorized to use this application Purpose of those certificates and different so certificates them self should be different. Using the same cert for actions like You have listed cause necessaries vulnerabilities and is highly NOT RECOMMENDED
I don't have any experience on using a digital cert.
Recently I wrote an application in J2ME and Qt for the Nokia S40 and S60 /Symbian ^3/Anna/Belle series phones.
My question is mainly on S40 J2ME phones.
My app need to read /write from memory cards and thus needs a digital cert signing.
I plan to let users download my apps from my site and my questions are:
If I bought a cert, does it mean that I use the same cert to sign any number of J2ME apps? Or one cert one app?
After signing an app with a cert, will it run after the cert expired? Suppose the cert is valid at the time signing the code. I read some articles about timestamp for PDF documents and Microsoft code signing, and not sure whether it is needed for J2ME apps.
I assume many S40 users won't connect to internet. But when a user tries to install the MIDlet, is it necessary to connect through network to the cert issuer's site to verify the cert?
You can use the purchased certificate to sign any number of applications until it expires
Your midlet will still work and install but you will not be able to sign new ones with an expired certificate. See also this post
certificate validation does not require network access. The root certificate of the issuer is already on the device. Be aware that you should use a certificate issuer whose root certificate is on your target devices.