I have a WCF service to receive sensitive data ( like SSN,Name,address,Driver License), To make sure information is securely transmitted and not accessible for anyone to view/change, I need to install SSL server certificate on clients server.
I am looking for recommendations to choose correct certificate for service. there are couple of certs available online
1. Standard cert
2. Extended validation certificate.
3. SSL Plus
4. Extended validation plus
The level of validation (i.e. domain, organization, extended, etc.) of an SSL certificate has only meaning to an end user; a simple domain validation certificate will let you setup a secure communication between you clients and your server.
The higher validation levels only give to a human more confidence about the site he / she is visiting, because a higher certificate level means that the organization has passed through more checks than with a simpler certificate.
If you're concerned about data communication security (and if you need it between two programs, without direct user intervention), you should instead turn your attention to encryption protocols and key lengths.
According to Qualys SSL Labs Best Practices, you should use 2048-bit RSA or 256-bit ECDSA private keys (I suggest you to read the whole guide).
As in all processes that involve encryption, higher levels of encryption means higher security, but lower performance, so choose wisely.
After you have chosen and installed the certificate, be sure to check your server with their SSL Server Test, to be sure that your whole encryption chain is secure enough and correctly configured.
Related
Sorry I'm not a cyber security expert but I'm looking for some insight! I would like to encrypt a standard TCP socket communication and thought about using SSL. Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
Since it's pretty easy to hack, it probably doesn't worth the effort to implment ... Right? Or what encryption mechanism would you recommend?
Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Not true. If a device is unable to reach internet, it would be unable to check certificate revocation (CRL/OCSP) . The client would still be able to validate the other's party certificate and its validity.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
You don't really need to sign each other's certificate, the parties just need to trust them.
As already commented, you can use a self-signed CA or a self-signed certificate and then there's a question how do you protect the generated and CA private keys (isn't that always the case?). IMHO - even without any internet access using the qualified certificates (signed by a trusted CA) is a good /best option.
pretty easy to hack.. Or what encryption mechanism would you recommend?
No, not really "easy to hack" provided you keep the private keys private.
I'd say SSL is the best option for ensuring confidentiality and integrity of the transport channels.
According to my understanding, when we are trying to connect to a website/url, even if one of the certificates in the SSL certificate chain of the website is present in the trust store then connection is established successfully. But, I want to establish a connection only if the domain level certificate is present in the trust store. And I am not allowed create a new trust store instead need to use the default trust store. How can this be implemented in Java? TIA.
Unfortunately for you, that's not how PKIs were designed to work. The search for any trusted root certificate in the chain is a design feature of PKIs that ensures we don't have to install a certificate per domain on clients - bloating local trust stores with millions of certificates and complicating revocation and renewal of certificates.
What you're looking for is referred to certificate pinning where the client validates that the certificate presented by the server has a specific thumbprint it knows and trusts before continuing any further communication with the server on the other end. It is essentially the client authenticating the server.
Depending on your particular implementation, the validation logic can be done in the application instead of at the TLS/SSL protocol layer, meaning you can do as much (CN, Key Usage Attributes, SAN) or as little (just thumbprint)validation as you want , but typically certificate thumbprints are used since they are *guaranteed to be unique. A interception proxy or other man-in-the-middle for instance can create a certificate with valid CN entry for your domain (valid domain validation), but they cannot spoof the thumbprint.
A certificate is a unique token issued to a particular individual. It is a form of identification, similar to a government-issued photo ID which most people carry.
Certificates were designed for one purpose - to convey an identity which can be verified as authentic. It does this via a chain of trust. If a client or server trusts the issuer of a certificate, then it will automatically trust the certificate.
Put in similar terms, this is similar to the TSA specifying guidelines for which forms of identification it will accept before it will let you into the security checkpoint. As long as you possess one of those valid forms of ID, the TSA will let you through. This is how the PKI is designed, and it has to be designed that way to function efficiently. So, there is no way to do this explicitly in the PKI framework.
What you're instead asking for is a separate level of identify verification beyond what PKI provides. A possible solution could be certificate pinning, but I'm not sure this gets you anywhere. If the private key is compromised, which is probably more likely than compromising a trusted CA, then you haven't gained any additional level of security.
Instead, best practice is to implement multi-factor authentication. Using the certificate itself as a second factor really doesn't make a whole lot of sense, because it isn't truly a two-factor identity. Instead, it would make more sense to use the PKI as-is, and establish a second authentication mechanism via TOTP or some other independent token generation.
I have a secure API for mobile clients. I would like to perform certificate pinning and I achieved it. The problem is if run the command openssl s_client -connect xxx.xxxxxxxxx.com:443 then I can see my certificate. I believe whoever have the URL, they can also see the certificate and they connect to my APIs.
How I can prevent access to my certificate, so that only my mobile can access but not public?
Anyone who connects to an SSL / TLS server can view the server's certificate because is public. This is normal behavior.
But that does not mean it can connect to your API. Normally an authentication mechanism is added where the one that connects has to present credentials, for example user/password.
With SSL/TLS is also possible to require a client certificate to stablish the secure channel. This is called two ways authentication. But it is not usually used from mobile devices because of the difficulty of distributing the electronic certificates
I suggest adding authentication to your api if you have not already done so
Public key cryptography works by having one part (the certificate) freely available publicly. The corresponding private key is needed to decrypt and it should be kept secret.
Therefore there is no problem with openssl having access to the certificate - that's exactly how it should work! A web browser will also be able to grab the certificate for a website it had not been too.
Pinning adds a further layer of security that this but limiting the certificates that a website can use to those certificates that are "pinned" to the site. As discussed without the private key, someone can decrypt the traffic. However there are certain, reasonably sophisticated attacks that involve intercepting traffic and replacing the certificate with another using their own certificate/private key combination so they can read the traffic. Pinning prevents this by explicitly stating which certificate(s) should be allowed in this site.
Pinning does not stop the need for the key to be public, nor does it limit connections from your mobile app only - there are other solutions for that but pinning is not it. It merely is used to address one type of attack against the server.
Pinning is an advanced topic and it is easy to accidentally cut off access to your site by pinning a certificate and then not updating the pins when renewing, or otherwise changing, the certificate. Due to that risk, you should ensure you have a much greater understanding of how all this works before implementing pinning. At the moment you seem to have a misunderstanding of the basics so would advise against advanced topics like pinning.
I'd like to run some encrypted connections between some of my own servers. One can use Curl (or some other mechanism) to connect using HTTPS without SSL certificate verification. I'm using PHP, but the language probably isn't significant for this question.
I'm assuming using HTTPS without a SSL certificate is atleast more secure than doing the exact same connection over plain HTTP, since atleast it's encrypted and an evildoer would have to make a much larger effort to intercept en decrypt the information.
As far as I know an SSL certificate only says "this trusted third party says the server you connect to is owned by the guys that claim to own it". If I connect using my own domainname or IP address, I know I'm the owner. What additional value does an SSL certificate provide if I'm the owner of both ends of a connection?
Not verifying the identity of the server you connect to leaves the connection open to potential MITM attacks. SSL/TLS can be used without certificates (with anonymous cipher suites), but they're insecure (and disabled by default); as the TLS RFC says: "Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated."
In addition, the HTTPS specification itself expects there to be an X.509 certificate.
Checking the identity of the remote party is a necessary element for securing your system. It's not very useful to exchange data secretly with a remote party who may not be who they claim they are (even if the secrecy is guaranteed).
This being said, you don't have to go via a commercial CA. You can either use self-signed certificates, which you would have to import individually into each client as trusted certificate, or create your own institutional CA. There are tools to do this, ranging from OpenSSL's CA.pl (see man-page), TinyCA or OpenCA amongst others. Some operating systems also provide their own small CA capabilities.
If I connect using my own domainname or IP address, I know I'm the
owner. What additional value does an SSL certificate provide if I'm
the owner of both ends of a connection?
The certificate assures you that you're indeed connecting to your machine and that the traffic hasn't been intercepted. That's why you need to check that it's a certificate that you recognise.
SSL certificates are more for the piece of mind of your customers or those using your site. In either case, the data is being transmitted over the same connections - it's just a matter of whether or not a third party is certifying you as being safe.
At my last job, we did all of our internal data transfers at my last job via https/ftps but did not have an SSL certificate until very recently. Since the data transfers were internal, it made no difference.
I'm developing a product that needs to act as a server over a local network for other client applications to connect to, under the following constraints:
The data exchanged is very valuable, and we have no guarantee over the security of the users' network or the machine acting as a server. Therefore any SSL certificate could potentially fall into "the wrong hands".
To minimise disruption to the user experience, any non-electronic means of identifying the server to the client should be limited to information that can be written on a post-it (i.e. IP address, passcode rather than exchanging key files).
Given these, our current SSL strategy is:
Do not install any SSL certificates into any trusted stores or sign any certificates against a CA certificate - this could give a potential attacker a front-door key to all the client machines
SSL certificates will therefore be self-signed. This offers no man in the middle protection, because we have no way of verifying the server. It does however offer eavesdropping protection to those users who have insecure networks but secure servers.
Implement a "passcode" system over the top using Rijndael symmetric encryption, so even if the certificate is compromised there is some eaves-dropping protection (I know, many leaky buckets - but better than nothing). This passcode can be regularly regenerated with minimal interruption to the user experience of the clients.
Within these constraints, is there a more secure strategy for the client and server to communicate?
In the end we developed a system where we could generate a new SSL certificate in memory for each channel we were going to support. This cannot provide protection against Man in the Middle but does at least protect against eavesdropping (unless the third party has access to the memory of the server at time of transmission, in which case all security is moot anyway!).