I just wanted to provide an update on this thread. Martin provided me several debug versions to help work through and troubleshoot this issue. Thanks again Martin for your help!!! Based on our troubleshooting, we did end up proving that for some unknown reason, the specific setup we had with our Azure network caused the getaddrinfo method to not function properly. I was able to work with Microsoft and provided a proof-of-concept to show the error that they were able to reproduce on their end, but at this time there is no ETA on a resolution.

I did just submit a feature request to add an optional override flag to help in situation like this.
Add a new setting to force SNI for WebDAV

I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Thanks Martin for the response!

Sorry, the "VNET integration" is an option for Azure App Services that routes all outbound traffic through a virtual network in Azure. I also am working with Microsoft on a support ticket, but it seems we have narrowed it down to the following. It seems that the ne_iaddr_parse method in ne_socket.c is for some reason NOT returning NULL when it should be.

Yes, if we Ping the URL it resolves and works fine. In addition, I was able to upload a file to the server using CURL commands for WebDAV. So it seems that the name resolution is working fine when using CURL or other commands, but is only failing when going through WinSCP for some reason.

I do not know what "VNET integration" is.
Anyway, it looks like the hostname resolution fails in that environment.
What does ping mywebdav.site.com say? Or can you connect any other way to mywebdav.site.com? E.g. using Invoke-WebRequest in PowerShell?

We are trying to use WinSCP to connect to a WebDAV endpoint from our application. In testing it works fine locally, but when we deploy it to our staging environment we are getting a "sslv3 alert handshake failure" error. The environment we are running it on is within Azure, and it is worth noting that it works in other Azure environments, but only seems to be giving us this error in our environments that have VNET integration enabled.

We have enabled logging, and in comparing a working session to a broken session, the one difference we see is the line that says "ssl: SNI disabled by default" on the broken version. We were looking through the source code, and it looks like this message will appear if WinSCP thinks that the host being passed in is an IP address - however we are not passing an IP, we are only passing a hostname.

I was curious if anyone had ever run into a similar issue, where SNI is being incorrectly disabled, and if there are any suggestions on how to work around it.

We have seen the same error regardless if we test with the .NET library, via PowerShell (by loading the WinSCP.DLL), or by calling the WinSCP.com - such as with the following example:


I have attached the session log for reference as well. Again, it seems that the NE_SESSFLAG_TLS_SNI flag is not getting set for some reason, which is causing the hostname to not be passed, resulting in the SSL handshake. But am not sure why this is happening, or how to work around it.

Thanks!