ServicePointManager.SecurityProtocol incorrect when called over COM?

R P 6 Reputation points
2022-08-24T16:29:37.487+00:00

The default value for ServicePointManager.SecurityProtocol, in a .NET 4.7.2 app, is supposed to be "SystemDefault", which is supposed to include tls 1.2 as far as I understand it.

If I make a simple NET 4.7.2 console app and look at the SecurityProtocol value it is "SystemDefault" as expected.

However, we have code in a NET 4.7.2 DLL to call Exchange Services which is COMVisible and called from another app using COM. And when this call over COM is done the value of SecurityProtocol defaults to "Ssl3, Tls" (which causes the code to fail).

Why does the value of ServicePointManager.SecurityProtocol mysteriously change to " Ssl3, Tls" when the code is called via COM?

This has been tested with the simplest DLL just to output the value of SecurityProtocol and called from a couple of different places over COM (including PowerShell) with the same result. So it really does seem to be the act of using COM that somehow "degrades" the default security.

In addition to "why", the next question will be: Can this be fixed in some way that doesn't involve programmatically adding Tls12 to the SecurityProtocol in the COM control, which is apparently a Bad Idea?

.NET CLI
.NET CLI
A cross-platform toolchain for developing, building, running, and publishing .NET applications.
323 questions
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jose Zero 576 Reputation points
    2022-08-25T00:06:22.14+00:00

    Have in mind SSL and TLS is tied to Operating System where you app is running, also even as far OS docs tells you TLS is enabled by default you have to check if it is really enabled.
    From my experience at Win Server 2012, docs say TLS 1.0, 1.1 and 1.2 are enabled by default, but I have to to set SecurityProtocol for my needs.
    Can not tell much about "COM", my experience comes from WebForms.
    Hope this helps

  2. Ben Graham 0 Reputation points
    2023-06-02T05:59:11.7766667+00:00

    We were recently bitten by this. It's not even consistent behaviour, you will get the expected behaviour on some systems and not others. The workaround is to configure the registry to override .net framework behaviour to choose the strong crypto and TLS 1.2. https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server

    From what I can see, the AppDomain under COM is not correctly configured and it does not know the Framework version as a result. This degenerate behaviour is a symptom.

    0 comments