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
Related
I have followed the Microsoft Documentation (https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslstream?view=netframework-4.7.2) and able to create a
server that allows Https Connection.
Currently , The implementation does only Authentication from the Server end but I would like to
issue an another certificate from the Client that server can authenticate to establish the connection.
Most of the Documents only cover examples with client Authentication set to false. I am looking for sample example in which Server can receive and Authenticate the client certificate as well .
Any suggestions would be much helpful.
Thanks a lot in advance !!
I would like to use the TLS-SRP protocol to secure the communication between a mobile app client and a WebAPI REST server. My primary reason is to avoid using self-signed certificate stored on the device or hardcoded for security reason (breach, decompiling...). Setting up the salt between the server and the client is not an issue. However I don't know how to customise the HttpClient on the client-side and the WebAPI server to follow the protocol.
Has anyone done that before? Could you point me to any documentation?
Cheers,
I am required to create a two way mutual handshake between a desktop client and WCF Service. I am using a Let's Encrypt Server Certificate on my Server but open to use Self Signed Certificate as well.
I wish to generate a Client Certificate and install it on the client's machine after successful authentication via OTP. The idea is to authenticate/authorize the desktop app for further communication with the server.
After few of my research I found that OpenSSL.Net enable to create certificates.
I would like to create an asp.net web forms application which uses ssl client certificates. The way I understand it (which may be wrong), is that during the ssl handshake, the server sends the client a list of trusted certificate authorities. The client then uses this list to see which CA's it also trusts and then the web browser asks the user which client certificate it would like to use (if there is more than 1 for a matching CA).
Is there a way to add code to the ASP.NET web application so only 1 specific CA gets sent down as being trusted? I assume the server will have many of the popular CA's as being trusted and sends them all down; but I just want to send down a specific one to the client.
The negotiation of client certificate happens before ASP.Net gets involved in the request. The configuration is on the HTTP.sys listener via Certificate Trust Lists.
However, this behavior is ignored by IIS 5, 6, and 7, and has been disabled by default on Windows 8 / 2012 and later.
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