Hi Michael,
The threading issue makes me a little uncomfortable. Since this module
is going to be processing multiple requests at the same time, adding the
delegate, running the request, and removing the delegate can cause a
race condition between threads. Plus, removing the delegate by setting
it to null assumes that there was no other delegate setup elsewhere in
the application to handle certificate validation. You could add locking
mechanisms around the code in the CAS module, but you would have no way
of enforcing that locking protocol with third-party code. I think given
that the ServicePointManager is the only way to handle the validation,
you really will want to decide whether or not to allow bad certificates
for the entire lifecycle of the application.
I'm also a little apprehensive to add this to the module because it
could change or break the behavior of third-party code. Plus there may
also be security concerns with regard to accepting any SSL certificate
without doing any checks at all (expired, wrong domain name, etc.). I'm
not sure if this is the right approach to the problem. Is there a
reason that you aren't trusting the CA certificate instead or treating
the self-signed cert as a trusted CA cert?
As an alternative, you could consider adding the code to
Application_OnStart or Init (not sure which) in global.asax or in a
separate HttpModule.
I think if we do decide to ship the feature as a part of the CAS client,
we should distribute it as a separate HttpModule and explain to users
the benefits vs. security implications of using it.
Here is some example code-it would only wire up the delegate if the
application is compiled in DEBUG mode.
void Application_OnStart() {
InitializeCertificateValidator();
}
[Conditional("DEBUG")]
void InitializeCertificateValidator() {
ServicePointManager.ServerCertificateValidationCallback =
delegate(Object obj, X509Certificate certificate, X509Chain chain,
SslPolicyErrors errors)
{
return true;
};
}
Anyone have any comments/insight?
Scott Holodak Aspire | A Plan for Princeton
Princeton University Office of Development
From: Michael Hans [mailto:foliofnm...@gmail.com]
Sent: Sunday, February 28, 2010 4:02 PM
To: cas-dev@lists.jasig.org
Subject: Re: [cas-dev] Quirky Dev Patch for Invalid SSL Exceptions in
.NET
Hey Scott,
I'm all for it being re-factored to meet the project standards but
wanted to provide some context on why I wrapped those calls vs single
initializing it. An odd use-case i've seen is :If the app itself has
some custom ssl validating logic it uses in the callback it will remove
yours once the delegate is set. I've wrapped (in which I agree is not
pretty) to avoid anything down the process chain from knowing the cas
module was involved. This is a remote use-case I admit and since it's
strictly for development purposes I have no objections to moving it into
the Initialize method.
Thanks
Michael
On Sun, Feb 28, 2010 at 2:01 PM, Scott M. Holodak
<sholo...@princeton.edu> wrote:
Hi Michael,
I'm looking at your patch and had a few questions/comments. I'd like to
re-work your code a little bit so that it gets around the thread safety
issue.
I think CasAuthentication.Initialize() would be the place to add the
certificate validation delegate (Initialize() is thread-safe). Also,
since any changes to web.config will cause the application to recycle
(and CasAuthentication.Initialize() to pick up the changes), I don't
think it would require the removal capability (resetting the delegate to
null). Also, you wouldn't have to add and remove the functionality
around each of the outbound web requests (i.e., in ticket validators,
proxy retriever).
Any questions/comments/objections?
-Scott
-----Original Message-----
From: Michael Hans [mailto:foliofnm...@gmail.com]
Sent: Friday, February 26, 2010 4:00 PM
To: cas-dev@lists.jasig.org
Subject: Re:[cas-dev] Quirky Dev Patch for Invalid SSL Exceptions in
.NET
Your right, I didn't consider the fact that an issue could be tabled and
scheduled for future development or implementation. Jira ticket created
http://www.ja-sig.org/issues/browse/NETC-10
Thanks
Michael
--
You are currently subscribed to cas-dev@lists.jasig.org as:
sholo...@princeton.edu To unsubscribe, change settings or access
archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org as:
foliofnm...@gmail.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org as:
sholo...@princeton.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
