Posts 1 - 10 of 14
First | Prev. | 1 2 | Next | Last
|
|
|
|
Henjo van Rees
Posts: 46
Joined: 2018-12-10
|
I have an Excel Add-in, which does HTTP REST calls and transforms the output to ranges in the current workbook.
On the webserver we reconfigured to only allow TLS 1.2 and suddenly the HTTP Requests do not work anymore with this WebException: The underlying connection was closed: An unexpected error occurred on a send.
This error is generated when the .NET framework does not support the TLS 1.2 protocol and cannot fallback to lower (unsecure) protocols.
We compile our Excel Add-in with .NET 4.8 and target .NET 4.8, which according to Microsoft ensures that TLS 1.2 is supported without any code or registry changes:
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls
But it isn't. With .NET 4.8 in our plugin TLS 1.2 is not supported.
When checking ServicePointManager.SecurityProtocol
the values are Ssl3 and Tls, which are strong indicators that .NET 4.5 or lower is used for running the code.
Question:
Is it possible that the Addin Express is compiled with (or targets) .NET 4.0?
I checked with dotPeek and dotPeek reports that AddinExpress.XL.2005.dll
is compiled with (or runs) .NET 4.0.
And (I am now assuming) that this may very well cause the TLS problems.
PS I do not want to set ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
in my code since Microsofts explicitly says not to tie your code to a protocol.
I also do not want to give clients instructions to set registry keys since we security should be standard, not opt-in. |
|
|
Posted 16 Mar, 2021 10:20:15
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
|
|
Posted 17 Mar, 2021 02:49:34
|
|
Top
|
|
|
Henjo van Rees
Posts: 46
Joined: 2018-12-10
|
I read your other response. Using SecurityProtocolType.SystemDefault is not an option because what you said, at the highest TLS 1.0 is offered.
What I just don't understand is that, when I compile with and target .NET 4.8, TLS 1.2 should be enabled by default:
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls
"TLS 1.2 support: Supported, and enabled by default."
But it just isn't.
Your suggestion to set ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 works, but goes against what microsoft recommends.
Using SecurityProtocolType.SystemDefault does NOT work, which is the actual strange part, since using Win10 + .NET 4.8 should not require code or registry changes.
But when running the Excel plugin it does require one of these changes.
I just don't understand what the problem is and why what I experience conflicts with everything that microsoft recommends.
Hence my question: Is Add-in Express perhaps compiled with (or targets) a lower .NET version (like 4.0 or 4.5) which may be the cause? After all, the total Excel Add-in that I built is my DLL (.NET 4.8) and your DLLs (.NET 4.?) |
|
|
Posted 17 Mar, 2021 04:33:32
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Henjo,
On that page there's this text:
When run from Excel, your add-in uses TLS 1.0. A while back I found that a VSTO add-in demonstrates the same behavior and googled out this page: https://github.com/dotnet/docs/issues/4675 on gthub/dotnet/docs; use Ctrl+F to find "Excel" on it.
That is, the actual .NET Framework used seems to be irrelevant.
Also, from what I know, NET 4.8 may mean a lot in a standalone application; it *may* work differently in an add-in because this isn't an application. In particular, .NET is hosted in the Office application while it looks like it governs and controls the complete process in a standalone application.
That said, I don't know what is the root cause of this. So, I can only suggest that you specify the TLS explicitly.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 17 Mar, 2021 05:22:09
|
|
Top
|
|
|
Henjo van Rees
Posts: 46
Joined: 2018-12-10
|
Ok, clear that you also don't know exactly why this is the case.
To me it feels really wrong that security in this case is opt-in instead of default.
Can it be a VSTO bug or limitation? Since Excel is hosting our application it seems like an Excel/VSTO bug.
Do you have any ideas on where to dig further or who to ask questions? |
|
|
Posted 17 Mar, 2021 06:25:30
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
Hello Henjo,
I can't reproduce the issue any longer. In an add-in showing a WebBrowser Control on a pane, I right-click the page displayed, choose Properties and check the section Connection: it states TLS 1.2 for me.
I'm using Windows 10 Version 2004 (OS Build 19041.867) and Office 365 Version 2102 (Build 13801.20266) Current channel. I assume something has changed.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 17 Mar, 2021 08:05:30
|
|
Top
|
|
|
Henjo van Rees
Posts: 46
Joined: 2018-12-10
|
I can still reproduce the issue, but I do not use a WebBrowser Control pane, but an HttpWebRequest directly.
And I do not use Office 365, but Office 2016.
Can you check what happens when you do an HttpWebRequest in Office 2016? |
|
|
Posted 17 Mar, 2021 09:08:38
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
|
|
Posted 18 Mar, 2021 10:06:08
|
|
Top
|
|
|
Henjo van Rees
Posts: 46
Joined: 2018-12-10
|
I don't have these registry keys either. They seems registry keys for the server-side though.
It seems indeed to be something strange in Windows or Office, since .NET 4.8 should enable TLS 1.2 by default.
I expect that your earlier remark may be right, but I have no idea to verify this. I cannot find any sources on this:
"it *may* work differently in an add-in because this isn't an application. In particular, .NET is hosted in the Office application while it looks like it governs and controls the complete process in a standalone application." |
|
|
Posted 18 Mar, 2021 10:29:10
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18829
Joined: 2006-05-11
|
|
|
Posted 22 Mar, 2021 03:02:40
|
|
Top
|
|
|
Posts 1 - 10 of 14
First | Prev. | 1 2 | Next | Last
|
Forums
Topics
Search
Help
Login
Register