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".
Related
I have a REST API which uses JWT bearer authentication over HTTPS. SSL certificate is installed on the web server hosting my REST API. Do I need to provide client certificates to different applications(users) who want to consume my API, to have a handshake between their server and my server using the client certificate which i provide them.
I tried calling my HTTPS REST API which I developed in C# from a python script running locally from my machine but I had to specify the verify flag to False or ssl.CERT_NONE for the call to succeed
import requests
requests.get('some https url', verify=False)
I know we can also use self signed certificates. I am worried about Man in the Middle attacks if they call my endpoint with verify=False and If someone tries to use my API in his app which is in production over https do I need to give him the client certificate for handshake or his app would be able to call my https api endpoint without me specifically providing a client certificate.
I tried to take some leads from this question but it doesn't explain how different users whose apps are trying to call my endpoint over https, will be able to perform a handshake with my rest api
Any guidance would be highly appreciated.
Quick answer: keep your private key file safe and you wont have any problems.
The long answer has to do with explaining asymmetrical encryption and how its implemented in a TLS handshake. When a client opens a HTTPS connection with your server a series of requests are sent back and forth:
Client sends HELLO
Server sends HELLO back including the servers SSL certificate
Client verifies the certificate with the certificate authority
The client sends back a random string of bytes encrypted with the servers public key
The server decrypts the string using the private key
After the final step a session is created between the client and server. In order for a man-in-the-middle attack to be successful the "man in the middle" needs to have your private key and proxy every action just described back to your server, otherwise one of the steps will fail and the client will get that "SERVER UNVERIFIED" error in their browser warning them that the connection is not secure.
This is a pretty brief explanation of the process, you can do some more reading here
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.
From my .net client code, is there a way to obtain details about an SSL certificate being used by a WCF service? Assuming I can already connect successfully over SSL to the service.
I am hoping to report the expiration date of the server certificate on a dashboard. If the certificate has been updated / renewed since the last time the client communicated with the service, I'm trying to detect that as well.
Let's also assume the server cert is a real public cert from godaddy etc. i.e. the cert would not have been explicitly imported into the client store already.
Any thoughts? I was thinking I might find somewhere in System.ServiceModel.ClientBase that I could find this after opening a connection but haven't found anything yet.
Thanks!
Easiest way would probably be to just implement a certificate validation callback on the client so that you can have a chance to look at the SSL certificate provided by the server before it is trusted by the client:
http://msdn.microsoft.com/en-us/library/aa702579(v=vs.110).aspx
I'm using a Winforms client to connect to a WCF service hosted in IIS. The Winforms application will be available to customers to download and install on their computers. The customers have to login to the application using their username/passwords. I want a secure HTTPS enabled communication between the client application and the WCF. What is the best practice to provide such a functionality? Should I use client certificates or just a server certificate? Any input is much appreciated.
Thanks.
You have to have a server certificate.
If you want stronger authentication you can use client certificates. There is an administration of certificates overhead and potentially other costs to that though: Using certificates from a provider, generating them yourself, maintaining list of revocations and so on.
As you already authenticate the user with password, client certificate authentication is not needed. To ensure the communication is secured use a self-signed server certificate. In case if the clients needs to verify that they are connecting to the correct server then you need to get a signed certificate from a third party CA like verisign which could cost you atleast 100$.
Have implemented SSL with self-signed certificate On Apache Tomcat 7.0.47 using Java keytool.exe.It's working fine in Browser.
Issues are:
1) while invoking the API's in java/dot net client am getting exception as "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
Solutions i got through online are:
1) Need to ignore invalid certificates then what's the use of SSL implementation.
2) Need to import cert into client truststore.
Could anyone suggest me how to solve this problem,is anyother ways to implement SSL and invoke those API's in client application. don't want to ignore the Cert
It's working fine in java client using InstallerCert.java class but need to invoke HTTPs API's in dot net client,any help would be really appreciated
Thanks in Advance
You need to establish trust relationship between client and server, in order to call server APIs. For java you can follow these steps to achieve your goal -
Generate certificate for server (You can do this by using installCert.java)
Once this certificate is generated usually it will be keystore file and/or .cert file
You copy this file(s) into your JAVA_HOME/lib directory
Then restart your server and this should be done
More info can be found from these sources -
security-ssl-certificate-error-use-your-trusted-certificate and http://miteff.com/install-cert
Hope this helps. There are other ways also, to generate certificate but this way is easiest as per my understanding. :-)