I have a third party web application and now my manager wants to add smart card authentication to some of the pages (not the whole application) and return certificate information. What I'm thinking is to add buttons to those pages, and in the onclick event, I will do the client certificate authentication (where a certificate selection window will appear followed by the "PIN" window) and return certificate object for further processing.
I initially thought about a web service to do the client certificate authentication and return certificate information, which would be great because we might consider using that web service in other web applications (on different platforms). However, I couldn't find any code example that did this. Then I found the IIS solution.
I have now created a separate folder with a page that requires a client certificate. On the button click event, I redirect to that page. Then on that page, I retrieve the certificate information using the X509Certificate class. I don't think this helps me in what I'm trying to do, or at least I don't know how it helps.
So my question is (sorry for the long background description)
How can I redirect back from that page with the certification result?
If possible, any reference on how to build up a web service that does the client certificate authentication in the same way that IIS does?
Thanks
Update
I looked around and still don't have a clue on how to achieve this. I'm not sure how to code at SSL/TLS handshake stage for the web service. I don't know how to return the certification back to the page I invoke this function either. So what I'm trying to do now is to redirect from a protected page that requires client authentication. It seems the web server caches the authentication result. Here is my third question, I hope someone can answer.
How can I clean out the authentication result at the end of the page session so that each time the page is visited, it request client authentication (where a certificate selection window will appear followed by the "PIN" window)?
if your app is hosted in IIS then simply add (in web.config) a section that says client certificate is required for those pages. THe browser will then ask the user for a cert.
Windows has a caching feature which, by default, allows applications to access the private key for a limited time after the initial PIN prompt, or until the application is closed completely.
To disable, set this registry key. (Or use a GPO)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography]
"PrivKeyCacheMaxItems"=dword:00000000
"PrivKeyCachePurgeIntervalSeconds"=dword:00000000
Related
I'm working with an SSL application and I would like to read data from two client certificates.
When a user comes to my site he chooses a certificate and enters a pin, which get cached and used by subsequent requests until Chrome (et al) gets restarted.
Any ideas on how to prompt the user for a certificate for a second time on the same site?
Regards.
A solution that has satisfied my need was to bind the app on two https ports in IIS config. Works on IIS Express also.
More info: I am making two ajax requests on routes that are matched by a single <location> tag web.config. This location requires a certificate, which means user gets prompted when accessing them. Since these two ajax calls go to different ports, user gets prompted on the second ajax call too.
Knowing how to clear the cache would have been nicer for other use cases, because restarting Chrome is not something I would ask my users to do.
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.
How do I redirect url based on register client in c# .net or asp.net 4.0. For example if client registers as "client1" and our website is www.mycompany.com for every page client proceeds should get www.client1.mycompany.com.
More detailed example:
For example another client created is Client2. The pages i have created in general is like
"www.mycompany.com/product.aspx"
"www.mycompany.com/categories.aspx" should be shown as
"www.client2.mycompany.com/product.aspx" and
"www.client2.mycompany.com/categories.aspx" respectively
I have searched on web and found for static pages or using Gloabal.asax during startup of application but haven't found any thing after user logged in.
I have done something similar before in a few sites and there are a couple methods you could use. Assuming that you have a url setup so that all subdomains ( *.url.com) will send any user to your server and you have IIS setup to handle them all (i.e. no host header required, just IP) in the same site you can use one of the following methods:
After login simply send the user to that url. Since .Net won’t care the url the server knows how to render it, then it should be that simple. This assumes all your navigation uses relative paths and you must enable cookie sharing for that domain. This is required if the cookie for login was give on 1.url.com and you send them to 2.url.com You can share cookies in the same domain, requires a little work, but can be done.
Create a generic login page that does a web service request back to the server to see if the user can login. If he or she can have it send back to the browser a command, along with the correct url, that tell the clients browser to post directly to that sites login page (send username, password). This will login them into their site and assign the cookies correctly all from one simple login page. You could even make an external login page that only exists for this purpose. In the end all the generic page did was see if they could login and the sent their credentials to the correct page that did the login. I recommend this be done in a post with ssl for security reasons.
I hope that makes since.
There's a project called UrlRewritingNet which I use - it's pretty old but the source is available so you could recompile it for 4.0.
Link is at http://urlrewriting.net/149/en/home.html
I'm creating a Windows Forms application that uses an embedded WebBrowser control to view an intranet web page. The page is provided via https, using a self-signed certificate. I want the certificate to be valid in the context of my application, but don't want to mess with the client's machine itself (by permanently installing a trusted certificate).
Is there any way to programmatically trust a certificate for the lifetime of an application, rather than for the system as a whole?
You can certainly do that. But you may need to do it in two steps. Make a https request first and get the Server certificate and create a truststore on the fly and import the certificate into the truststore. This would be a onetime activity. You may cache this truststore to the filesystem so that you need not do this everytime. Make another https request and use this truststore for validating the subsequent https requests that you will make.
We have a client application running on each users computer that has a link to the associated web application.
A recent requirement is that if the user is logged in on the client application that they should be able to click the link and be automatically logged in on the web application.
Our web application is encrypted using SSL. Our client application is in Silverlight.
Is there a way to achieve this securely?
Our first naive thought was simply to embed the username and password in the url for the site, but obviously this is not secure because it is visible in the history and via the back button.
Attempt two involved simply converting the password segment into Base64 as to obscure it from view and trust in the SSL to encrypt it.
I'm still not happy. Ideally we would want to use some sort of time based token that expires within minutes of being used.
Where do we start?
If this becomes overly complicated (special hardware) or requires the user to do anything other than click the link-button then the feature will be dropped.
Perhaps you could make an authenticated web service call from the client application to the web application to obtain a token when the user clicks on the link, and then append the token to the querystring? Then the user is logged into the web application using the token, which is then immediately invalidated (valid for one-time use only).