What's the rationale for ServicePointManager.ServerCertificateValidationCallback being designed that way? [closed]

Question

ServicePointManager.ServerCertificateValidationCallback is a global static property that can be overwritten by any bit of code in your application simply by doing:

ServicePointManager.ServerCertificateValidationCallback
    = (sender, cert, chain, sslPolicyErrors) => true;

Why did they decide to implement it that way? Surely it should be a property on the WebRequest object, and you should have a very good reason for why you are ignoring the certificate.

Answer 1

Other code being able to set this property is not a security issue, since setting the property requires the SecurityPermissionFlag.Infrastructure permission, which you don't need to grant to code you don't trust.

On the other hand I agree that it's bad design, since it's global mutable state and that should be avoided. In particular it makes it unnecessarily hard to use different validation policies in different parts of the program. A shared config file, as you suggest, would be even worse IMO.

The correct choice would be an instance property for the callback, just like what the plain SslStream class uses. I'm not familiar enough with that part of the framework to say if this property exists, and thus ServicePointManager.ServerCertificateValidationCallback only serves as as a default, or if this global variable is the only way to influence certificate validation.