.NET framework 4.5 supports TLS 1.2, but doesn't default to it. This means that a WCF web service client fails to connect to an endpoint that requires TLS 1.2 (and it should require 1.2 - earlier versions are NOT secure) if nothing is done to get the framework to use TLS 1.2.
I have found answers to related questions (e.g. WCF Client in .NET 4.5.1: How to enable TLS 1.2 when WebRequest is used?) that provide a workable solution, but my question is specifically:
Is possible to specify TLS 1.2 in the WCF binding configuration?
Just to preempt anticipated attacks on my motivation for asking for a way to do this with the binding configuration rather than the use of the static property: Using a global (static and not thread-local) ServicePointManager.SecurityProtocol property is an illogical programming model. In the real world, you may very well be in the situation that your application needs to consume multiple web services, with some requiring TLS 1.2 but others not supporting it. If said application is multi-threaded, such as a web server, there is a race condition present. Two threads, where one attempts to connect to a service requiring TLS 1.2 and the other attempts to connect to a service that doesn't support it, may get in one anothers way so that both change the security protocol before either creates a channel - leading to one of the two failing.
Granted, it is unlikely to cause a large number of errors, but depending on how errors are dealt with (e.g. whether or not automatic retries are in place, or even possible), this is a potentially serious issue. And in any case, why create a race condition if there are simple ways to avoid it? If there is a way for me to specify in the binding configuration which security protocol should be used, and .NET then applies it only to endpoints so configured, the race condition would go away.