I've read a lot that self-signed certificates should never be used in production because of the lack of security but I wonder if it's still a security risk if I'm the only one who're supposed to connect to the server? Is it for some reason easier to crack a self-signed certificate? I'm creating both the server and client application and the only way for someone else to connect is to create their own client. That means that every time I install the client I also have the possibility to add the certificate to the trusted root certificates.
Or is it safer to continue to use my own encryption implementation using RSA/AES on the message level? The reason I want to use SSL instead is that it's much easier to work with, especially when I want to stream media since I don't have to send it in chunks.
I've read a lot that self-signed certificates should never be used in production because of the lack of security ....
Self-signed certificates by itself are not bad and can also used in production if done properly.
A certificates is safe to use if the peer is able to verify it properly. The usual validation is done based on some trusted root CA contained in the browser or operating system. But that a self-signed certificate can not be validated this way does not mean that it cannot be validated at all because:
You can explicitly add it as trusted to the certificate store of the browser/OS.
You can make an exception on first use after you've verified that the certificate you get in the browser is actually the one which you know (by comparing the fingerprint, not just the subject).
If you have your own application you could ship the application so that it (only) trusts this certificate.
Of course explicitly importing the certificate as trusted or making in exception in the browser does not scale well, because it has do be done for each user. And that's the main point of CA-signed certificates: that the certificate gets implicitly trusted because it is signed by someone trusted instead of that each user has to validate and trust the certificate manually. And this is also the only reason you want to use a CA-signed certificate in production. As long as the certificate is properly validated it does not matter if it was self-signed or not.
Or is it safer to continue to use my own encryption implementation using RSA/AES on the message level?
Never run your own crypto unless you really understand what you are doing.
In this case SSL provides everything you need but you have to know how to use it properly.
Related
I am working on a legacy architecture that has a server that has an existing certificate for communication. Multiple existing services in the legacy architecutre use this for communication. I am working on creating a communication channel on a much newer system that is built for scale that will communicate with our old framework. This will be used to perform a phased migration where we rely on the old architecture for a period of time, while still running the old system.
Due to some internal constraints, we can't simply add the existing certificate to the new architecture. Furthermore, changing the certificate to the new one will require changing every single service that communicates with the server to have retry logic & both certificates. Furthermore, this has the potential to instantly break the old system entirely (as all the services rely on the server to perform - one of the limitations of the old architecture).
So the ideal solution is that the service simply accepts two different certificates for a period of time while we perform the migration. The new services communicate with their certificate and the old services communicate with theirs. Then we can deprecate & decommission the old services
The only way I see to set a certificate is either in config or how we currently do it:
host.Credentials.ServiceCertificate.SetCertificate(System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
System.Security.Cryptography.X509Certificates.StoreName.My,
System.Security.Cryptography.X509Certificates.X509FindType.FindByThumbprint,
thumbprint);
Calling this again would overwrite the certificate set on the host. So is there any way that I can add an additional certificate that the server can distinguish between and use the appropriate certificate for communication with the client when it receives a connection?
Thanks for your time
As Ding Peng mentioned in the comments:
This solution is not feasible, if use certificate verification, the server can only bind one certificate, as you said, if you add two certificates, one of the certificates will be overwritten.
This is correct, but I was misunderstanding how certificate encryption worked and it was unnecessary to add an additional certificate.
Simply by adding logic to whitelist the client certificate subject names of the new architecture - it was able to authenticate.
I had assumed that if the server certificate did not share the subject name of the client cert, that there would be an issue with authentication & encryption. However, this is not the case and simply whitelisting the new subject name was enough to perform the auth.
We have a client that has their own PKI infrastructure and assigns private certs to use as SSL client authentication for application access to their rest APIs.
I need to be able to use a client cert with SslStream and not have it choke that it is not trusted. Users will not be educated enough to know how to add CA certs to their local trusted cert store. Plus, most would not have the access to do so either.
The client application is being written in .Net 4.6.1
What do I need to do to get SslStream not to throw an exception with an locally untrusted client certificate?
Have you looked at the constructor that accepts a certificate validation callback method? https://msdn.microsoft.com/en-us/library/ms145057(v=vs.110).aspx Seems like that's what you are asking to do.
Recently, We developed an application that we want it's users to pay for a monthly subscription in order to use it. So the first thing that came to our minds how to implement a secure way for our application to check for the User validity and those ideas came up
Using WebClient to enter to our website and Login using the user
provided credentials : However, this might be vulnerable to MITM
attack.
Using the first approach but using SSL certificate (to make sure
that we are connecting to our server and not the attackers') :
However, Fiddler can easily do a MITM attack and decrypt the SSL
communication, which will result in the same vulnerability as the
first approach.
Due to the internet's lack of documentation of what we need, we had to ask here for someone to explain how could we make sure that:
Our application only connects to our server and not any fake hosted
server (by the attacker).
The communication is secure. Not altered or edited some how in order to
grand unfair access to our application. (by sending a fake response
to the app or editing the original response before the application receives it).
Note: we totally understand that the attacker may just deobfuscate the application and do whatever he want to it. So we are planning to get a goodobfuscatorin order to at least make it harder for the attacker to do so.
You can use SSL Certificate Pinning.
Set the ServerCertificateValidationCallback to only accept your certificate's public key, or one of its signers. (this means you can never change certificates)
This will completely prevent SSL MITM (which works by using a different certificate and making the computer trust it).
Of course, it doesn't prevent attackers from cracking open your app and bypassing the check altogether, especially if you store local state.
I need an encrypted communication between C# and PHP to send HttpWebRequest's and download files from the server. Is that possible without buying a certificate for https? I think a certificate should'nt be needed in my case, isn't it? What do you recommend to use?
If you control both ends, you can generate your own certificate and manually check that the server is using the expected one. It's in the case where the client wants to verify that the server is using the correct certificate that you need the functionality provided by a certificate authority.
Normally, the certificate is loaded into the web server and the encryption/decryption is invisible to any code running on the server. I would be very surprised if you could do it with just "php stuff".
I'm writing a client/server application that requires the server needs to be able to authenticate the client and also requires all comms to be encrypted.
The mechanism to provide this needs to be self contained within the server and client application and also to be fully automated (no human interaction required). SSL seems to be the best way to do this and is also something I am familiar with using.
For each client that needs the client software deploying to it, I planned to create (on the fly) an MSI installer with the application, the clients certificate (signed by the server) and private key and the servers public certificate (so the clients can authenticate the server - the server certificate could be self signed).
I can generate the key for the client and make a CSR, but don't seem to be able to find a way of actually signing the CSR and generating a certificate for the client thou. I have looked into the Win32 Crypto API, but haven't managed to find any examples of how to actually sign a CSR and get a client certificate.
I know how to do all of this from the command line with the openssl tool, but am not sure of how to do it from within an application.
Please note that making system calls out to the openssl tool and passing in the parameters I know to work is not an option as it's a huge security risk to rely on the openssl tool not being compromised in any way. Doing it this way wouldn't for fill the self contained requirement.
I am going about this the right way, or is there a better way to achieve the same thing - basically authentication of the clients connecting to the server and a way of the connecting client to authenticate the server they connect to, all encrypted.
I cannot make any assumptions about the server (or clients) having a static IP or hostname (DNS can be broken anyways), nor can I make any assumptions about any existing PKI infrastructure.
I am writing this primarily in C#.Net, but would consider writing a C++ extension to this if it gives me this functionality.
Finally this is my first post here, so if I've missed out something obvious or have been short on any details, please ask and I'll fill in the gaps :)
Thanks,
James
In C# you can use PKIBlackbox package of our SecureBlackbox product which provides all the functionality you are looking for in .NET. Maybe BouncyCastle library also includes this functionality.
You need to rethink at least part of this. What you are doing is radically insecure. The client's private key needs to be generated at the client. Otherwise it isn't private, so it cannot possibly satisfy any of the tenets of PKI,. including the purpose for which you are issuing it. You lose uniqueness and you also lose non-repudiability. These are both fatal flaws.