I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.
Related
I am developing an app with a server part programmed in Go and a client programmed in C#, the connection between the two is made using TCP socket communication, and to ensure the connection I am using TLS.
My question is whether there would be any security problem in my case when using self-signed certificates for TLS communication.
I understand that for a web server that uses https it is necessary to use certificates signed by a certificate authority (CA) but in my case, when connecting my own client application I don't see why I should use one of these.
If anyone knows anything about it, it would be a great help.
Certificates are used for authenticating the end points, and usually the cert is signed by a certificate authority which your client (such as a web browser) already trusts. Using a self-signed cert in that scenario can lead to problems, as the browser won't trust it, and so will pop a warning box. However, the real issue is that for the typical user, a warning from your server is as good as indistinguishable from an attacker using another self-signed certificate. They'll click-away and KABOOM!
If this is a closed environment, and you control both the server and client, then the self-signed certificate is irrelevant. In fact, you don't even need one at all, and may be better off with one of the alternatives, like TLS-PSK, or TLS-SRP.
Say I have a flutter app and an intranet server. The flutter client will try to talk to the server in TLS. I understood that we can generate a self signed certificate in server and I can have flutter client app load the certificate to talk to the server. I am thinking that if I store that certificate in asset, would that be secure ?
Seems that if someone got the certificate from asset, they can then talk to the server. Is that true ? If that is true that it seems that self certified certificate is not very secure.
Certificates are public, you're storing a copy of your self-signed certificate locally for your TLS client to trust it, as it'll only trust the system CAs by default. So no, nothing will be compromised if you store your certificate client-side.
What you shouldn't store client-side are private keys, they typically start with
-----BEGIN PRIVATE KEY-----.
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
I am implementing a push notification system for one of my apps, so I am following this tutorial and generating a SSL certificate for that.
This app of mine involves also, some exchange of data between the app and the server and I would like it to be SSL protected and I was wondering of getting a SSL certificate from verisign or other company like that.
My question is: is this SSL certificate created for push a regular SSL certificate, so in that can use it also to establish a https connection to the server (and save a couple hundred dollars to order a third party certificate)? I don't know much about SSL certificates, but I hope it can be used for that...
This will be amazing!
Since each certificate is tied to a specific domain, I'm not sure how this would work. There is a concept of wildcard certificates, but I still think they have to be for the same domain.
In your case, it sounds like you will have the Apple push certificate, which validates the connection between your server and Apple's push notification server. The other certificate would be to validate/secure the connection between your iOS app and your server. Both of these are assigned a different domain (gateway.sandbox.push.apple.com vs. yourserver.com).
One option you do have depending on how your iOS app is structured is to use a self-signed certificate between your iOS app and your server. I'm guessing the end-user will not be seeing the certificate anyway. This might be a way to save you money before deciding on a third party certificate.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.