I'd like to use client certificates to verify the identity of administrative callers to my web service. Then I can issue certificates only to the people I want to call my web service and be pretty sure noone else can call it. This is in a very controlled scenario where only one or two people will get the client certificate, so distribution isn't a hard problem.
This article provides a good example of how to call a web service using a client certificate.
But how can I check details of the client certificate from within my web service? This old article talks about configuring IIS to do it, but I'd like to do it programmatically within my app. I think?
thanks for any suggestions!
The incoming Request has a ClientCertificates collection that you can interrogate -- you can check the various fields in the cert or check the actual raw byte data (perhaps against a datastore or other source) if you want to completely validate it.
Note, if you issue the certs from your own private CA, you will need to install the CA's cert on your webserver into a store that is visible to all users, otherwise IIS won't request those certs from the user (due to the nature of how the server/client interaction works.)
Related
I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
I have looked at about 10-15 different pages about the SSlStream class and about certificates and I haven't found one that completely explains everything to me. So I have a bunch of questions.
I am currently working on some SslStream code and I have a question about certificates. From my research it appears that the server requires a certificate if we are using TSL12. And it appears optional that the client needs a certificate.
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
2) Also looking at the Microsoft SslStream help page:
https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx
How does the code know if those are the expected certificates?
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
Thanks.
You can find most answers to your questions here
These are the different certificates. Client certificate used to check client identity. Server certificate used to encrypt key materials and to authenticate itself.
What means expected? You mean whether the client certificate is correct? You can write your own login to check client and certificate. By default expiration date is checked, where it's revoked or not etc. Read there to clarify.
It will create certificate and to use private key you will need to provide password to get it from storage
The base usage is to put it into the store. But you can also get it from .pfx file. You can read there about geting the key from file
1) Now if we design a system that the client needs a certificate do we use the same certificate for the client and the server? Or do they both use different ones?
The best practice is "one certificate per purpose". Think of a server authentication certificate as the "Warner Bros. Studios" sign hanging on the building as you pull up to the guard shack, and a client authentication certificate as an employee ID badge. They both inform the other party what's going on, but it feels a little out of place to then walk down the street to Universal and show your big Warner Bros. sign as identification.
2) Also looking at the Microsoft SslStream help page: https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx How does the code know if those are the expected certificates?
The server authentication certificate you provide is correct, because you provided it.
If you give only one client auth cert, that's correct, because you provided it.
If you give multiple client auth certs then it will use an acceptable CAs list provided by the server TLS handshake to reduce the list, then it takes the first one that was acceptable.
3) In the Property page on a project under Signing you can Create a Test Certificate. When you click that button it asks for a Password. If a password is used how would that affect the SslStream code? The code on the Microsoft help page above doesn't deal with that at all?
Certificates don't have passwords, but PFX/PKCS#12 files do. You need that password to load the file into an X509Certificate2 instance (e.g. new X509Certificate2("servercert.pfx", "1Potato2Potato3Potato4")). Since SslStream won't do the loading for you, it doesn't talk about passwords.
4) Once I have a certificate for the server and the client can I just place them in a directory or do I need to put them in the store?
They should work fine when loaded from a PFX (you need the private key, so it can't be just a .cer). If the certificates can be one-time loaded into cert stores you can avoid the problem of loading or hard-coding PFX passwords... but that just depends on your deployment needs.
It's been a week already and I'm still not fully comfortable with implementing ASP.NET Membership Provider with WCF. I'm wondering:
We already have a website which is running under HTTPS protocol. We are working on a new application which will have a WCF service and is going to replace our old application (with HTTPS). Now my question is, since we already have a secured website, do I have to get another certificate just for the WCF service?
If yes, then do I have to get certificates for clients as well? (As I was looking on the web, most of the answers I found were "yes".)
If no, can I use the existing certificate to authenticate my service?
To answer your 2nd question, you only need client certificates if you want your WCF service to support mutual (2-way) SSL authentication, in which both the server and client sides are authenticated by their respective certificates.
Refer to this question for further information on mutual ssl and wcf.
how to implement 2-way SSL certificate for WCF
You have to have 1 SSL Certificate per domain unless you purchase a wildcard certificate. So, if your current SSL Certificate is for subdomain.mydomain.com and you want to host the WCF service at anothersubdomain.mydomain.com (or even www.anotherdomain.com), then you'll need another certificate. If this is something that would happen fairly frequently, then I'd suggest you purchase a *.mydomain.com SSL certificate.
Another option would be to host the WCF service under the current subdomain with a URL like subdomain.mydomain.com\myservice\service.svc.
I can't answer your second question but I doubt you are using client side certificates.
Here's a link to a Beginner's guide on SSL Certificates.
I'm planning on deploying a WCF service to multiple devices to receive notifications of certain events. All of the events will originate from a client machine that can provide a certificate to the service to authenticate.
I'm less concerned about the client authenticating each service, but I'm having difficulty choosing the proper WCF security settings to provide this setup. It appears that message-level security requires a client certificate and a service certificate.
But the devices hosting the service will not be able to be maintained in a way that allows us to update the service certificate periodically when it expires. So here are my questions:
Is there a way to set up a WCF service for client certificate authentication without a service certificate on the server?
Is there a simpler approach for verifying the identity of the caller that I'm missing?
I apologize for the brevity of this answer, but it is better to think of it as a Server certificate, rather than a Service certificate. Multiple services could use the same certificate, and you can work around the expiration by not checking for expiration client side. In terms of is there any easier way, WCF supports a variety of authentication and authorization models, here's some useful links.
http://msdn.microsoft.com/en-us/library/ee748498.aspx
http://msdn.microsoft.com/en-us/library/ms733131(v=vs.110).aspx
I asked a question here a while back on how to hide my http request calls and make them more secure in my application. I did not want people to use fiddler 2 to see the call and set up an auto responder. Everyone told me to go SSL and calls will be hidden and information kept safe.
I bought and installed an SSL Certificate and got everything set up. I booted up fiddler 2 and ran a test application that connect to an https web service as well as connected to an https php script.
Fiddler 2 was able to not only detect both requests, but decrypt them as well! I was able to see all information going back and fourth, which brings me to my question.
What is the point of having SSL if it made zero difference to security. With or without SSL I can see all information going back and fourth and STILL set up an auto responder.
Is there something in .NET I am missing to better hide my calls going over SSL?
EDIT
I am adding a new part to this question due to some of the responses I have received. What if an app connects to a web service to login. The app sends the web service a username and a password. The web service then sends data back to the app saying good login data or bad. Even if going over SSL the person using fiddler 2 could just set up an auto responder and the application is then "cracked". I understand how it could be useful to see the data in debugging, but my question is what exactly should one do to make sure the SSL is connecting to the one it was requesting. Basically saying there cannot be a middle man.
This is covered here: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp
Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Essentially, you manually trust whatever certificate Fiddler provides, the same will be true if you manually accept certificate from random person that does not match domain name.
EDIT:
There are ways to prevent Fiddler/man-in-the-middle attack - i.e. in custom application, using SSL, one can require particular certificates to be used for communication. In case of browsers, they have UI to notify user of certificate mismatch, but eventually allow such communication.
As a publicly available sample for explicit certificates, you can try to use Azure services (i.e. with PowerShell tools for Azure) and sniff traffic with Fiddler. It fails due to explicit cert requirement.
You could set up your web-service to require a Client-side certification for SSL authentication, as well as the server side. This way Fiddler wouldn't be able to connect to your service. Only your application, which has the required certificate would be able to connect.
Of course, then you have the problem of how to protect the certificate within the app, but you've got that problem now with your username & password, anyway. Someone who really wants to crack your app could have a go with Reflector, or even do a memory search for the private key associated with the client-side cert.
There's no real way to make this 100% bullet proof. It's the same problem the movie industry has with securing DVD content. If you've got software capable of decrypting the DVD and playing back the content, then someone can do a memory dump while that software is in action and find the decryption key.
The point of SSL/TLS in general is so that the occasional eavesdropper with Wireshark isn't able to see your payloads. Fiddler/Burp means that you interacted with the system. Yes, it is a very simple interaction, but it does require (one) of the systems to be compromised.
If you want to enhance the security by rendering these MITM programs useless at such a basic level, you would require client certificate authentication (2-way SSL) and pin both the server and client certificates (e.g. require that only the particular certificate is valid for the comms). You would also encrypt the payloads transferred on the wire with the public keys of each party, and ensure that the private keys only reside on the systems they belong to. This way even if one party (Bob) is compromised the attacker can only see what is sent to Bob, and not what Bob sent to Alice.
You would then take the encrypted payloads and sign the data with a verifiable certificate to ensure the data has not been tampered with (there is a lot of debate on whether to encrypt first or sign first, btw).
On top of that, you can hash the signature using several passes of something like sha2 to ensure the signature is 'as-sent' (although this is largely an obscure step).
This would get you about as far in the security way as achievable reasonably when you do not control (one) of the communicating systems.
As others mentioned, if an attacker controls the system, they control the RAM and can modify all method calls in memory.