TLS1.2, Excel and .NET

[Govert van Drimmelen]

I forward this message from an Excel-DNA user who was investigating some http connection problems when running .NET code in Excel.

-----------------------------------

Dear Govert,

I'm not sure where to post this as it's not an issue with Excel-DNA per-se although I think many others will be interested in the topic.

The website whose xml-api I am using has recently switched to tls1.2 only* 

Due to this, my Excel-DNA (1.1.1) addin got a SSL/TLS secure channel exception.
(I'm using Microsoft Excel for Microsoft 365 MSO (Version 2112 Build 16.0.14729.20254) 64-bit)
Upgrading Excel-DNA to 1.5.1 had the effect of making the connection fail silently instead of raising an exception(!).

I was stumped for a while, because when I ran my code in f# interactive I didn't have a problem connecting.

(Yes, it's an f# addin, but turns out that this time f# wasn't the problem).

Then I checked the runtime being used, 5.0.11 for fsi and 4.8.4420.0 in the addin under Excel.

So I compiled a stand alone 4.8.4420.0 test, expecting it to fail, but it worked.... 

After some digging online I was led to the solution which worked:

 "Enabling TLS1.2 for dotnet" by adding the following two registry keys and rebooting.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

The whole problem/solution can be reproduced with Excel alone by:
- entering the formula =WEBSERVICE("url of tls2 only website")
- Before changing registry this gives #NULL
- After changing registry the formula gives the expected response.

This solution leaves a big question unanswered. Why is tls1.2 treated differently under Excel?
The addin reports that the same 4.8.4420.0 framework version is being used as in my stand-alone test.

(from System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription)

Yet without changing the registry values Excel will fail to connect but a stand-alone will work.

If you have any insight into this I'd love to know.

Also thanks for Excel-DNA and I think your videos are great.

Best regards,
Simon.


*A nice way to check this is with the (linux?) command:

 openssl s_client -connect bullionvault.com:443 -tls1_2

If you try -tls1_1 or -tls1_3 the connection is dropped.

[Bart Duijndam]

Hi Simon, Govert,

Recently I ran into a similar problem, that was solved by adding the following line to AutoOpen() :

  ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

See for more info: https://stackoverflow.com/questions/2859790/the-request-was-aborted-could-not-create-ssl-tls-secure-channel

I hope this may be of help.

Cheers,

Bart

[Simon Allfrey]

Many thanks Bart,

I can confirm that including the the equivalent f# code: 

System.Net.ServicePointManager.SecurityProtocol <- System.Net.ServicePointManager.SecurityProtocol ||| SecurityProtocolType.Tls12

In the AddIn fixes the problem as well, which is great for deployment!

Best wishes,

Simon

[Simon Allfrey]

Furthermore reading the documentation:

https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager.securityprotocol

it's quite clear that this is what you are expected to do rather than relying on any defaults the os or other context (in this case Excel) may provide.

[Bart Duijndam]

Hi Simon, good to hear that this solves your 'problem' without having to 'hack' the registry or using XML in the app.config file.

Cheers, Bart

--
You received this message because you are subscribed to a topic in the Google Groups "Excel-DNA" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/exceldna/qWZMXjDXkW8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/c1389cad-9641-4597-bfe4-5dbce68a2224n%40googlegroups.com.

[C. Augusto Proiete]

You guys might want to be less explicit about TLS 1.2 and let the OS automatically upgrade to the latest TLS available, say when TLS 1.3 is available.

Enabling TLS 1.2 without changing code in .NET

https://stackoverflow.com/questions/65228467/enabling-tls-1-2-without-changing-code-in-net

Cheers,

~Augusto

https://github.com/augustoproiete

You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/CAC%2BpVYbu0BFjaHOrmzKfzPUcF8yy9Mt%2BKZticEEf4SXk0k1zzA%40mail.gmail.com.

[Bart Duijndam]

Hi Augusto,

I checked your suggestion on stackoverflow and indeed the following code works okay. Please note that I develop for .NET 4.7.2.

            var securityProtocol = (int)System.Net.ServicePointManager.SecurityProtocol;
            // 0 = SystemDefault in .NET 4.7+
            if (securityProtocol != 0)
            {
                System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
            }
/*            
            // the next line is essential to prevent file-open errors.
            ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;
*/

Stepping through this code (applied in AutoOpen()), I get securityProtocol = 240. Therefore the following line is executed :

           System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

But this way I force the use of Tls12, whereas in the solution I used earlier, I just add Tls12 to the allowed security options.

Not sure what is 'preferred' in this case. . .

Kind regards,

Bart